From spromano@unina.it Wed Sep 1 04:00:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F2C3A695B for ; Wed, 1 Sep 2010 04:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.119 X-Spam-Level: X-Spam-Status: No, score=-98.119 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaVLxgclipG8 for ; Wed, 1 Sep 2010 04:00:19 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id 182313A6942 for ; Wed, 1 Sep 2010 04:00:18 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id o81B0e3l008070 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Sep 2010 13:00:41 +0200 Message-ID: <4C7E3254.6000702@unina.it> Date: Wed, 01 Sep 2010 13:00:36 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Peter Musgrave References: <4C7C0457.9070008@unina.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: DISPATCH Subject: Re: [dispatch] [RAI] Reminder: DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 11:00:21 -0000 Hi Peter, thanks for your comment. The DisCO approach is definitely relevant to the proposed DCON work, especially in the case where the focus overlay network is built and managed with a p2p approach. I think that, in case the IETF were to charter the DCON proposal, the mentioned draft should be taken into account since the beginning. Cheers, Simon Il 31/08/2010 12.43, Peter Musgrave ha scritto: > Hi Simon, > > This is indeed an interesting topic. > > How does what you are proposing relate to the approach in DisCo > (https://datatracker.ietf.org/doc/draft-knauf-p2psip-disco/) ? > > (I see significant overlap - and I like the use of RELOAD in DisCO, > since it is a rich NAT/security aware mechanism for building > distributed conferencing) > > Regards, > > Peter Musgrave > > On Mon, Aug 30, 2010 at 3:19 PM, Simon Pietro Romano wrote: > >> Dear chairs and all, >> >> please find attached a proposal submission related to a topic that I called >> DCON and which stands for Distributed Conferencing. I hope that with XCON >> which is close to successfully concluding its work, the time is now ripe for >> focusing on how to improve its scalability through distribution of >> components/responsibilities. I am sending a drafty draft of DCON's potential >> charter, just to give you some initial material to debate. I'm looking >> forward to receiving your feedback. >> >> Cheers, >> >> Simon >> >> Il 13/08/2010 18.37, Mary Barnes ha scritto: >> >> Hi all, >> Just a reminder that the first deadline for IETF-79 for the DISPATCH WG >> topics is two weeks from Monday. >> Regards, >> Mary. >> >> On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes >> wrote: >> >>> Hi folks, >>> The following summarizes the deadlines for topics for DISPATCH for >>> IETF-79: >>> * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of >>> plans to submit a proposal. [Two weeks prior to BoF proposal deadline] >>> >>> * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week prior >>> to BoF proposal deadline] >>> >>> * Sept. 20, 2010. Topics that are to be the focus of IETF-79 >>> are announced. >>> [One week before deadline to request WG slots] >>> >>> * Oct. 18th, 2010. -00 draft deadline. >>> >>> * Oct. 25th, 2010. Draft deadline. >>> >>> These deadlines have been published on the DISPATCH WG wiki page: >>> http://trac.tools.ietf.org/wg/dispatch/trac/wiki >>> Note that these dates are closer to the end of the meeting than those for >>> IETF-78 because there is just over 3 months between the end of IETF-78 and >>> beginning of IETF-79 (versus the 4 months we had between this meeting and >>> Anaheim). >>> >>> Note that registration and WG/Bof scheduling for IETF-79 starts on August >>> 9th: >>> http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 >>> DISPATCH sets the first deadline such that it's still possible to request >>> a BoF for topics that may be wider in scope and require broader community >>> review. The deadlines for BoFs are set by the leadership so that there is >>> time to consider BoFs in the scheduling. Also, as Gonzalo noted in a >>> separate email, WGs need to have a draft charter at the time they request a >>> WG slot. Further information on the motivation for the DISPATCH planning >>> model is provided in the wiki. >>> Regards, >>> Mary >>> DISPATCH WG co-chair >>> >> >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai >> >> >> -- >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Science Department >> Phone: +39 081 7683823 -- Fax: +39 081 7684219 >> e-mail: spromano@unina.it >> http://www.comics.unina.it/simonpietro.romano >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From stephen.botzko@gmail.com Wed Sep 1 04:07:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B6C3A6958 for ; Wed, 1 Sep 2010 04:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nsL1hg6zJ0Q for ; Wed, 1 Sep 2010 04:07:50 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 40D6B3A6956 for ; Wed, 1 Sep 2010 04:07:42 -0700 (PDT) Received: by qyk1 with SMTP id 1so480417qyk.10 for ; Wed, 01 Sep 2010 04:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3n2oj9NzJFqnl0MkpCVnDDzWAfR6wXxRNIcNz6kbLms=; b=DZ8vC6sanyucjznnN76J+wTE8SwRLZtbcYwqQWt5xYNH83+ZVKFG6OIQlzIExOynlT h0HMBWJoHReAeRCaYcWdl6LY/CnRYNRxlfTbZ3ybWI2DhSzlpGZfRBRN0pZF/sGiB6Zp fsIF4XBtl2wNURJ/JWAY1hwJwtkRcl96+P7rI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AUDS5ncX4SsTsEw+MnuDszhvuoZOD603CzcWa4X8H8rhnzM+vtgD6Y/Lw27TB2s0TR ifcR5lTti8J08PLdWxkB+bYPE8Lq8mPiAub33CrXi21kNlupO1cgIlWX5Ho4XOzeYWip Iam8Sc9zc46SZP7bO4NHfJNA9XogZ/P7DOAf8= MIME-Version: 1.0 Received: by 10.229.251.209 with SMTP id mt17mr5286106qcb.221.1283339290622; Wed, 01 Sep 2010 04:08:10 -0700 (PDT) Received: by 10.229.31.138 with HTTP; Wed, 1 Sep 2010 04:08:10 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850150D9BD@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB70@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850150D9BD@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Sep 2010 07:08:10 -0400 Message-ID: From: stephen botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=0016362851b68b3e00048f30b67c Cc: DISPATCH list Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 11:07:52 -0000 --0016362851b68b3e00048f30b67c Content-Type: text/plain; charset=ISO-8859-1 Hi Christer The proposed charter is to enable full interoperation of future SIP based telepresence systems w/o such equipment, by replacing the current proprietary extensions with a standard. "Full" interoperation includes enabling the full immersive telepresence experience with multiple streams (preserving visual scale, gaze awareness, etc), since existing systems already can fall back to single-screen SIP. Regards, Stephen Botzko On Wed, Sep 1, 2010 at 2:56 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > A question for clarification. > > The proposed charter says that there exists telepresence systems based on > different standards (SIP, H.xxx etc), and that today expensive > interworking equipment is required in order for these systems to interop. > > But, how can you prevent such interworking? If whatever we specify is > supposed to be backward compatible with standards compliant systems, you > cannot assume that every system will support e.g. SIP. > > Regards, > > Christer > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) > > Sent: 27. elokuuta 2010 2:31 > > To: Cullen Jennings (fluffy) > > Cc: DISPATCH list > > Subject: Re: [dispatch] Telepresence Charter Version 3 > > > > WRT my previous note suggesting the change to Cullen's > > sentence, people should be clear that everything not in the > > charter is out of scope. > > So please think about anything that you think we need to > > cover which is not now explicitly called out in the charter. > > > > thanks > > > > -----Original Message----- > > From: Cullen Jennings (fluffy) > > Sent: Thursday, August 26, 2010 8:54 AM > > To: Allyn Romanow (allyn) > > Cc: DISPATCH list; Mary Barnes > > Subject: Re: Telepresence Charter Version 3 > > > > > > I think this charter has some pretty serious issues with being way to > > wide open on what the scope is. The fact we are actually discussing if > > we need to add in "Also not in scope is signaling to tell the > > originator to which IP addresses the media streams should be sent" > > should be a huge hint that we have the scope much too broad. > > As I said a > > week ago .... > > > > Begin forwarded message: > > > > > From: Cullen Jennings > > > Date: August 18, 2010 11:16:22 AM MDT > > > > > Main point: > > > When I read this charter and ask myself what is out of > > scope, it seems > > that anything that is "the information about media streams from one > > endpoint to another endpoint or conference bridge including" > > would be in > > scope. I realize a few more things are taken our of scope > > later but the > > resulting space includes just about everything that MMUSIC does, and > > much of what SIP does. Because of the "anything and > > everything" approach > > I don't think this is a charter that will result in work that > > gets done > > quickly. From the point of view of being broad enough to do the need > > work, I think it's fine but from the point of view of being narrow > > enough to limit the work to something that is possible to complete, it > > seems pretty bad. I suspect that IESG would likely look at this as a > > "blank cheque" charter and ask for some changes to it. My suggestion > > would be just to change the "including (but not limited to):" in 3rd > > paragraph to be > > > > > > This working group is chartered to specify the following information > > about media streams from one endpoint to another endpoint: > > > > > > > Note I am not arguing that there any given piece of work you > > should not > > do - I'm just encouraging you to say what problems you are > > going to do. > > > > I would encourage you to specify what this working group is > > going to do, > > like you have in the bullet points, and stop leaving it open to do > > anything including the stuff in bullet points. We should do > > our best to > > avoid charters that are so unspecific that they overlap with existing > > WGs in ways that leave huge questions about which WG a new > > piece of work > > should go to. > > > > Cullen > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0016362851b68b3e00048f30b67c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christer

The proposed charter is to enable full interoperation of= future SIP based telepresence systems w/o such equipment, by replacing the= current proprietary extensions with a standard.

"Full" in= teroperation includes enabling the full immersive telepresence experience w= ith multiple streams (preserving visual scale, gaze awareness, etc), since = existing systems already can fall back to single-screen SIP.=A0

Regards,
Stephen Botzko




On Wed, Sep 1, 2010 at 2:56 AM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson= .com> wrote:

Hi,

A question for clarification.

The proposed charter says that there exists telepresence systems based on d= ifferent standards (SIP, H.xxx etc), and that today expensive
interworking equipment is required in order for these systems to interop.
But, how can you prevent such interworking? If whatever we specify is suppo= sed to be backward compatible with standards compliant systems, you cannot = assume that every system will support e.g. SIP.

Regards,

Christer


> -----Original Message-----
> From: dispatch-bounces@ie= tf.org
> [mailto:dispatch-bounces@= ietf.org] On Behalf Of Allyn Romanow (allyn)
> Sent: 27. elokuuta 2010 2:31
> To: Cullen Jennings (fluffy)
> Cc: DISPATCH list
> Subject: Re: [dispatch] Telepresence Charter Version 3
>
> WRT my previous note suggestin= g the change to Cullen's
> sentence, people should be clear that everything not in the
> charter is out of scope.
> So please think about anything that you think we need to
> cover which is not now explicitly called out in the charter.
>
> thanks
>
> -----Original Message-----
> From: Cullen Jennings (fluffy)
> Sent: Thursday, August 26, 2010 8:54 AM
> To: Allyn Romanow (allyn)
> Cc: DISPATCH list; Mary Barnes
> Subject: Re: Telepresence Charter Version 3
>
>
> I think this charter has some pretty serious issues with being way to<= br> > wide open on what the scope is. The fact we are actually discussing if=
> we need to add =A0in "Also not in scope is signaling to tell the<= br> > originator to which IP addresses the media streams should be sent"= ;
> should be a huge hint that we have the scope much too broad.
> As I said a
> week ago ....
>
> Begin forwarded message:
>
> > From: Cullen Jennings <flu= ffy@cisco.com>
> > Date: August 18, 2010 11:16:22 AM MDT
>
> > Main point:
> > When I read this charter and ask myself what is out of
> scope, it seems
> that anything that is "the information about media streams from o= ne
> endpoint to another endpoint or conference bridge including"
> would be in
> scope. I realize a few more things are taken our of scope
> later but the
> resulting space includes just about everything that MMUSIC does, and > much of what SIP does. Because of the "anything and
> everything" approach
> I don't think this is a charter that will result in work that
> gets done
> quickly. From the point of view of being broad enough to do the need > work, I think it's fine but from the point of view of being narrow=
> enough to limit the work to something that is possible to complete, it=
> seems pretty bad. I suspect that IESG would likely look at this as a > "blank cheque" charter and ask for some changes to it. My su= ggestion
> would be just to change the "including (but not limited to):"= ; in 3rd
> paragraph to be
> >
> > This working group is chartered to specify the following informat= ion
> about media streams from one endpoint to another endpoint:
> >
>
> Note I am not arguing that there any given piece of work you
> should not
> do - I'm just encouraging you to say what problems you are
> going to do.
>
> I would encourage you to specify what this working group is
> going to do,
> like you have in the bullet points, and stop leaving it open to do
> anything including the stuff in bullet points. We should do
> our best to
> avoid charters that are so unspecific that they overlap with existing<= br> > WGs in ways that leave huge questions about which WG a new
> piece of work
> should go to.
>
> Cullen <with my DISPATCH co-chair hat on>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0016362851b68b3e00048f30b67c-- From davidbryan@gmail.com Wed Sep 1 05:43:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB7E3A6A3E for ; Wed, 1 Sep 2010 05:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.76 X-Spam-Level: X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJreygENvTNt for ; Wed, 1 Sep 2010 05:43:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3FE2C3A6B36 for ; Wed, 1 Sep 2010 05:43:19 -0700 (PDT) Received: by wyi11 with SMTP id 11so9802341wyi.31 for ; Wed, 01 Sep 2010 05:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=PvgSBcmhVR6R7TgGYeAtP4XkiPUs9JXnG3vfQVNu+E8=; b=OMJGoKdJ0doaY3wi3cQGIDM+xZQmcLwdNt09u41wsE3N814utYy4ye87NzasX8iMXV I7N6NR/vkLVCyK8YYxPQ6qh7obtClIru8Q/9jQFL1Yy9/TlG6lR1krKWibzZIL3/3CJ9 4MCDhWuOEXr6R/Zj3p5ijolpp1R7rTsGH+sks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IsnYoErMGq/SDtnMHfKpaE4uBTbPUj08V/xqCGgfB00FoWXWidwuy7WNnfbOtZ5o31 cisD/mtJ5Zx3e9KsAV3rXIpHHPx4sS4ynT7WmnriNDc6jDUlc1XPj4fV1Pa0qQFZH62k sVd5aOagIi9/44Wo3uTr70cR6YppfwYwjrgPA= MIME-Version: 1.0 Received: by 10.216.9.3 with SMTP id 3mr7833212wes.66.1283345029097; Wed, 01 Sep 2010 05:43:49 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.216.175.16 with HTTP; Wed, 1 Sep 2010 05:43:48 -0700 (PDT) In-Reply-To: <361654.31400.qm@web24003.mail.ird.yahoo.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> <361654.31400.qm@web24003.mail.ird.yahoo.com> Date: Wed, 1 Sep 2010 08:43:48 -0400 X-Google-Sender-Auth: VUgbYNYIN6owCGp2R95YZfbc5Og Message-ID: From: "David A. Bryan" To: Gerard Fernando Content-Type: text/plain; charset=ISO-8859-1 Cc: Gerard.M.X.Fernando@zte.com.cn, "dispatch@ietf.org" Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 12:43:46 -0000 I think there are two issues here, Does this work need to be done, and where to do it? I think work to define a standard for HTTP streaming certainly needs to be done. HTTP streaming is becoming more prevalent, and there are non-compatible standards floating around out there today. As an example, just today Apple will be broadcasting their September media event using their own HTTP streaming proposal, and it turns only Apple hardware users can watch it: http://www.macrumors.com/2010/09/01/can-you-watch-apples-keynote-stream-requirements-and-workarounds/ The second question is where to do this work. Yes, other standards organizations have looked at this, but it's not like there haven't been a good number of proposals brought to the IETF as well. As Gonzalo pointed out, draft-wu-http-streaming-optimizations-ps-00 is out there, and draft-pantos-http-livestreaming-04, documenting the Apple mechanism I discussed above has been brought to the IETF as well. In addition, to me this seems much more the sort of work that belongs at the IETF than somewhere like W3C. Even ignoring the issue that HTTP itself is defined in the IETF, there are aspects of coordinating a standard on HTTP streaming that require consideration of transport issues (fairness, delay, etc.), issues involving real-time considerations and interoperability with other streaming techniques (which could touch work on RTP, work in the new PPSP WG, etc.) The membership of the IETF, to me, appears to be the group with the right skill set, and more importantly, the IETF is responsible for the other protocols that this inevitably seems to require coordination with, I'd like to see us work in this area, and would be interested in participating. David On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando wrote: > Hello, > > I also agree with you that it's not the content of the ID that one should > discuss at this point, instead it is more the direction or policy of IETF > with regard to this important subject. Being new to the DISPATCH WG > discussions I'm not sure whether this has been discussed in the last few > months. > > Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very active > in spec. development, and there seems to be a large degree of coordination > between those SDO's. Has there been any coordination between them and IETF? > After all... it is HTTP 1.1 that forms the basis for those efforts! > > It is important to understand the policy of IETF with regard to such > efforts. I hope that IETF does have a role to play with this activity, and > would at the minimum set some guidelines. > > Thanks > > Gerard > ---------- > > Gerard Fernando > ZTE Corporation > > ________________________________ > From: Gonzalo Camarillo > To: "dispatch@ietf.org" > Sent: Tue, 31 August, 2010 0:34:07 > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D > Action:draft-wu-http-streaming-optimization-ps-00.txt) > > Hi, > > we have not seen any comments on this topic (HTTP streaming). However, > many people were on vacation in August. Please, send your comments to > this list. > > Thanks, > > Gonzalo > > On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: >> Hi, >> >> yes, to be clear, the idea is not to only discuss this draft. The idea >> is to discuss what can be done in the HTTP streaming area at the IETF (I >> have changes the subject of this email). >> >> As Ali pointed out below, this is an important area that is advancing >> fast. So, we would like to get your input sooner rather than later. >> >> Thanks, >> >> Gonzalo >> >> >> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >>> (Responding to Gonzalo's email) >>> >>> I read this draft, but I won't comment on the draft here. Rather, I would >>> like to understand the goal(s) of this draft. >>> >>> HTTP streaming, as noted by the draft, has been around for some time now >>> and there are already multiple products available. Many groups besides IETF >>> have shown interest in this topic and worked towards producing their own >>> specs in the past year. Just last week, MPEG also joined the club and has >>> started evaluating the received proposals. >>> >>> Sure, we can discuss some of the design issues here at IETF. But, do we >>> want to achieve more than that? If yes, we should be aware of the time >>> pressure. >>> >>> -acbegen >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From tme@americafree.tv Wed Sep 1 06:04:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219993A6A4C for ; Wed, 1 Sep 2010 06:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYktpJDAYlki for ; Wed, 1 Sep 2010 06:04:24 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C54DA3A67F1 for ; Wed, 1 Sep 2010 06:04:23 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 7A2028AEC415; Wed, 1 Sep 2010 09:04:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Wed, 1 Sep 2010 09:04:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> <361654.31400.qm@web24003.mail.ird.yahoo.com> To: "David A. Bryan" X-Mailer: Apple Mail (2.1081) Cc: Gerard.M.X.Fernando@zte.com.cn, "dispatch@ietf.org" Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 13:04:27 -0000 On Sep 1, 2010, at 8:43 AM, David A. Bryan wrote: > I think there are two issues here, Does this work need to be done, and > where to do it? >=20 > I think work to define a standard for HTTP streaming certainly needs > to be done. HTTP streaming is becoming more prevalent, and there are > non-compatible standards floating around out there today. As an > example, just today Apple will be broadcasting their September media > event using their own HTTP streaming proposal, and it turns only Apple > hardware users can watch it: >=20 > = http://www.macrumors.com/2010/09/01/can-you-watch-apples-keynote-stream-re= quirements-and-workarounds/ >=20 > The second question is where to do this work. Yes, other standards > organizations have looked at this, but it's not like there haven't > been a good number of proposals brought to the IETF as well. As > Gonzalo pointed out, draft-wu-http-streaming-optimizations-ps-00 is > out there, and draft-pantos-http-livestreaming-04, documenting the > Apple mechanism I discussed above has been brought to the IETF as > well. >=20 > In addition, to me this seems much more the sort of work that belongs > at the IETF than somewhere like W3C. Even ignoring the issue that HTTP > itself is defined in the IETF, there are aspects of coordinating a > standard on HTTP streaming that require consideration of transport > issues (fairness, delay, etc.), issues involving real-time > considerations and interoperability with other streaming techniques > (which could touch work on RTP, work in the new PPSP WG, etc.) The > membership of the IETF, to me, appears to be the group with the right > skill set, and more importantly, the IETF is responsible for the other > protocols that this inevitably seems to require coordination with, >=20 > I'd like to see us work in this area, and would be interested in = participating. >=20 +1 David put it very well. Regards Marshall > David >=20 > On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando = wrote: >> Hello, >>=20 >> I also agree with you that it's not the content of the ID that one = should >> discuss at this point, instead it is more the direction or policy of = IETF >> with regard to this important subject. Being new to the DISPATCH WG >> discussions I'm not sure whether this has been discussed in the last = few >> months. >>=20 >> Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very = active >> in spec. development, and there seems to be a large degree of = coordination >> between those SDO's. Has there been any coordination between them and = IETF? >> After all... it is HTTP 1.1 that forms the basis for those efforts! >>=20 >> It is important to understand the policy of IETF with regard to such >> efforts. I hope that IETF does have a role to play with this = activity, and >> would at the minimum set some guidelines. >>=20 >> Thanks >>=20 >> Gerard >> ---------- >>=20 >> Gerard Fernando >> ZTE Corporation >>=20 >> ________________________________ >> From: Gonzalo Camarillo >> To: "dispatch@ietf.org" >> Sent: Tue, 31 August, 2010 0:34:07 >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D >> Action:draft-wu-http-streaming-optimization-ps-00.txt) >>=20 >> Hi, >>=20 >> we have not seen any comments on this topic (HTTP streaming). = However, >> many people were on vacation in August. Please, send your comments to >> this list. >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 >> On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: >>> Hi, >>>=20 >>> yes, to be clear, the idea is not to only discuss this draft. The = idea >>> is to discuss what can be done in the HTTP streaming area at the = IETF (I >>> have changes the subject of this email). >>>=20 >>> As Ali pointed out below, this is an important area that is = advancing >>> fast. So, we would like to get your input sooner rather than later. >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >>>> (Responding to Gonzalo's email) >>>>=20 >>>> I read this draft, but I won't comment on the draft here. Rather, I = would >>>> like to understand the goal(s) of this draft. >>>>=20 >>>> HTTP streaming, as noted by the draft, has been around for some = time now >>>> and there are already multiple products available. Many groups = besides IETF >>>> have shown interest in this topic and worked towards producing = their own >>>> specs in the past year. Just last week, MPEG also joined the club = and has >>>> started evaluating the received proposals. >>>>=20 >>>> Sure, we can discuss some of the design issues here at IETF. But, = do we >>>> want to achieve more than that? If yes, we should be aware of the = time >>>> pressure. >>>>=20 >>>> -acbegen >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From Even.roni@huawei.com Wed Sep 1 08:26:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8263A68A7 for ; Wed, 1 Sep 2010 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.535 X-Spam-Level: X-Spam-Status: No, score=-100.535 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYFP+mD+XLAb for ; Wed, 1 Sep 2010 08:26:25 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 40C413A69A6 for ; Wed, 1 Sep 2010 08:26:25 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L82001ZVQWK37@szxga05-in.huawei.com> for dispatch@ietf.org; Wed, 01 Sep 2010 23:26:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8200671QWJYU@szxga05-in.huawei.com> for dispatch@ietf.org; Wed, 01 Sep 2010 23:26:44 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-36-248.red.bezeqint.net [79.183.36.248]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8200E4HQVYKY@szxml02-in.huawei.com>; Wed, 01 Sep 2010 23:26:43 +0800 (CST) Date: Wed, 01 Sep 2010 18:25:37 +0300 From: Roni Even In-reply-to: To: "'David A. Bryan'" , 'Gerard Fernando' Message-id: <02bb01cb49e9$fb47b7a0$f1d726e0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActJ03WXj/1p8VS0ROmCNIY1/KWhpAAFW3Jg References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> <361654.31400.qm@web24003.mail.ird.yahoo.com> Cc: Gerard.M.X.Fernando@zte.com.cn, dispatch@ietf.org Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 15:26:27 -0000 Hi, I think David brought some good points. The issue of using HTTP for live streaming in draft-pantos-http-livestreaming-04 was discussed in the AVT mailing list and there was interest but this is not AVT charter. Yet I think that the IETF should look at it not only on how to carry the media but also in the wide aspect of addressing the transport issues as David mentioned and also at how to work in environments that may use a combination of RTP multicast and HTTP unicast. I would like us to work in this area and will participate in this work Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of David A. Bryan > Sent: Wednesday, September 01, 2010 3:44 PM > To: Gerard Fernando > Cc: Gerard.M.X.Fernando@zte.com.cn; dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu- > http-streaming-optimization-ps-00.txt) > > I think there are two issues here, Does this work need to be done, and > where to do it? > > I think work to define a standard for HTTP streaming certainly needs > to be done. HTTP streaming is becoming more prevalent, and there are > non-compatible standards floating around out there today. As an > example, just today Apple will be broadcasting their September media > event using their own HTTP streaming proposal, and it turns only Apple > hardware users can watch it: > > http://www.macrumors.com/2010/09/01/can-you-watch-apples-keynote- > stream-requirements-and-workarounds/ > > The second question is where to do this work. Yes, other standards > organizations have looked at this, but it's not like there haven't > been a good number of proposals brought to the IETF as well. As > Gonzalo pointed out, draft-wu-http-streaming-optimizations-ps-00 is > out there, and draft-pantos-http-livestreaming-04, documenting the > Apple mechanism I discussed above has been brought to the IETF as > well. > > In addition, to me this seems much more the sort of work that belongs > at the IETF than somewhere like W3C. Even ignoring the issue that HTTP > itself is defined in the IETF, there are aspects of coordinating a > standard on HTTP streaming that require consideration of transport > issues (fairness, delay, etc.), issues involving real-time > considerations and interoperability with other streaming techniques > (which could touch work on RTP, work in the new PPSP WG, etc.) The > membership of the IETF, to me, appears to be the group with the right > skill set, and more importantly, the IETF is responsible for the other > protocols that this inevitably seems to require coordination with, > > I'd like to see us work in this area, and would be interested in > participating. > > David > > On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando > wrote: > > Hello, > > > > I also agree with you that it's not the content of the ID that one > should > > discuss at this point, instead it is more the direction or policy of > IETF > > with regard to this important subject. Being new to the DISPATCH WG > > discussions I'm not sure whether this has been discussed in the last > few > > months. > > > > Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very > active > > in spec. development, and there seems to be a large degree of > coordination > > between those SDO's. Has there been any coordination between them and > IETF? > > After all... it is HTTP 1.1 that forms the basis for those efforts! > > > > It is important to understand the policy of IETF with regard to such > > efforts. I hope that IETF does have a role to play with this > activity, and > > would at the minimum set some guidelines. > > > > Thanks > > > > Gerard > > ---------- > > > > Gerard Fernando > > ZTE Corporation > > > > ________________________________ > > From: Gonzalo Camarillo > > To: "dispatch@ietf.org" > > Sent: Tue, 31 August, 2010 0:34:07 > > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D > > Action:draft-wu-http-streaming-optimization-ps-00.txt) > > > > Hi, > > > > we have not seen any comments on this topic (HTTP streaming). > However, > > many people were on vacation in August. Please, send your comments to > > this list. > > > > Thanks, > > > > Gonzalo > > > > On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: > >> Hi, > >> > >> yes, to be clear, the idea is not to only discuss this draft. The > idea > >> is to discuss what can be done in the HTTP streaming area at the > IETF (I > >> have changes the subject of this email). > >> > >> As Ali pointed out below, this is an important area that is > advancing > >> fast. So, we would like to get your input sooner rather than later. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> > >> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: > >>> (Responding to Gonzalo's email) > >>> > >>> I read this draft, but I won't comment on the draft here. Rather, I > would > >>> like to understand the goal(s) of this draft. > >>> > >>> HTTP streaming, as noted by the draft, has been around for some > time now > >>> and there are already multiple products available. Many groups > besides IETF > >>> have shown interest in this topic and worked towards producing > their own > >>> specs in the past year. Just last week, MPEG also joined the club > and has > >>> started evaluating the received proposals. > >>> > >>> Sure, we can discuss some of the design issues here at IETF. But, > do we > >>> want to achieve more than that? If yes, we should be aware of the > time > >>> pressure. > >>> > >>> -acbegen > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> > >> > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Wed Sep 1 09:00:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529CF3A69AF for ; Wed, 1 Sep 2010 09:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3RTcO+GcFFx for ; Wed, 1 Sep 2010 09:00:43 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 03F073A69A6 for ; Wed, 1 Sep 2010 09:00:42 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1360741 for dispatch@ietf.org; Wed, 1 Sep 2010 18:01:12 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 88F151EB82AB for ; Wed, 1 Sep 2010 18:01:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 1 Sep 2010 18:01:12 +0200 From: "Elwell, John" To: IETF DISPATCH list Date: Wed, 1 Sep 2010 18:01:10 +0200 Thread-Topic: I-D Action:draft-wing-dispatch-v6-migration-00.txt Thread-Index: ActGJKw2oMcgdRvBTiyMvEENCOQw8gDyRwAg Message-ID: References: <20100827201502.036A93A687E@core3.amsl.com> In-Reply-To: <20100827201502.036A93A687E@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] I-D Action:draft-wing-dispatch-v6-migration-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 16:00:44 -0000 Thanks to the authors for writing this draft, which was triggered by the Ba= r BoF in Maastricht, which was in turn triggered by drafts discussed in MMU= SIC such as ICE-microlite (of which I am a co-author) and ALTC. Whilst doubting the need for connectivity checks (whether they be STUN-base= d, RTP-based, RTCP-based or whatever) in certain closed networks, in my opi= nion, where connectivity checks are needed, the existing STUN-based connect= ivity checks will suffice. To introduce a second method (whether RTP-based,= RTCP-based or STUN-based-without-SHA1) will not help interoperability, and= will likely introduce as many problems as it solves. John > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 27 August 2010 21:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-wing-dispatch-v6-migration-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Migrating SIP to IPv6 Media Without=20 > Connectivity Checks > Author(s) : D. Wing, A. Yourtchenko > Filename : draft-wing-dispatch-v6-migration-00.txt > Pages : 8 > Date : 2010-08-27 >=20 > During the migration from IPv4 to IPv6, it is anticipated that an > IPv6 path might be broken for a variety of reasons, causing endpoints > to not receive RTP data. Connectivity checks would detect and avoid > the user noticing such a problem, but there is industry reluctance to > implement connectivity checks. >=20 > This document describes a mechanism allowing dual-stack SIP endpoints > to attempt communications over IPv6 and fall back to IPv4 if the IPv6 > path is not working. The mechanism does not require connectivity > checks. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wing-dispatch-v6-mig ration-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From rsf@ns.live555.com Wed Sep 1 14:34:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117CA3A684B for ; Wed, 1 Sep 2010 14:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJshUyzJTmw0 for ; Wed, 1 Sep 2010 14:34:20 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by core3.amsl.com (Postfix) with ESMTP id E0CB53A6841 for ; Wed, 1 Sep 2010 14:34:19 -0700 (PDT) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id o81LYwpE036794 for ; Wed, 1 Sep 2010 14:34:58 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.14.4/8.14.4/Submit) id o81LYvfo036793; Wed, 1 Sep 2010 14:34:57 -0700 (PDT) (envelope-from rsf) Mime-Version: 1.0 Message-Id: Date: Wed, 1 Sep 2010 14:34:46 -0700 To: dispatch@ietf.org From: Ross Finlayson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 21:34:25 -0000 I agree that "HTTP streaming" should be standardized, and that the IETF appears to be the right place for this to be standardized. Now, to be a little more provocative, here's an email that I sent to the "avt" and "mmusic" mailing lists back in June 2009, when the "pantos-http-live-streaming" draft was (briefly) discussed there. I didn't get any responses to this back then, but there's definitely an "elephant in the room" here that can't be ignored. >Date: Thu, 25 Jun 2009 03:56:51 -0700 >To: avt@ietf.org, mmusic@ietf.org >From: Ross Finlayson >Subject: Re: [AVT] I-D Action:draft-pantos-http-live-streaming-01.txt > >I am pleased that Apple submitted this document as an Internet >Draft. While I feel that much of the subsequent criticism has been >excessively harsh (or in some cases, misguided), I do agree with the >criticism that the document's title could be more descriptive. The >current title - "HTTP Live Streaming" - suggests that it is a broad, >architectural overview document, which this really isn't. A more >meaningful title for this document might be something like > "Using URI Playlist Files to Simulate Live Streaming" > >Nonetheless, if this approach is seen as being useful, then I would >like to see the IETF adopting and standardizing it (or something >similar), because both media streaming and transport protocols >(including HTTP/TCP - the transport protocol most commonly specified >within URIs) are clearly within the IETF's arena. > >However, this document focuses attention on a much bigger issue - a >proverbial "elephant in the room" - that at some point the IETF in >general, and the MMUSIC and AVT working groups in particular, are >going to have to address: > >Thanks to the ever increasing abundance of cheap mass storage, we >are now in a world where media consumption is increasingly 'on >demand' - e.g, via DVRs or online services like YouTube - rather >than live. It seems inevitable that on-demand media playback will >dominate, with live media being relegated to relatively minor niches >where timeliness remains essential. > >Given this, we have to ask ourselves whether there is going to >continue to be a practical role for specialized protocols for live >media, or whether we will see more and more of the live media niches >being satisfied by hacks (like the one described by this draft) that >can make use of the increasingly dominant infrastructure that will >already be in place for on-demand media? Telephony currently >remains a refuge for live media protocols, but how much beyond this >in the future? (There are even companies out there now that are >providing videoconferencing over HTTP, within users' web browsers!) > >I believe that, at the very least, the IETF should try to be more >pragmatic about this (even if it means sometimes tarnishing >architectural purity). To give just one specific example, I'm >disappointed that the IETF did not adopt and standardize Apple's >earlier mechanism (developed several years ago) for tunneling >RTSP/RTP over HTTP. But given the points that I note above, I think >we're going to have to think hard about the future of RTSP in >general... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From zongning@huawei.com Wed Sep 1 18:07:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9959B3A6876 for ; Wed, 1 Sep 2010 18:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.553 X-Spam-Level: X-Spam-Status: No, score=-99.553 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1cC+crPqjFc for ; Wed, 1 Sep 2010 18:07:37 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6F5203A684D for ; Wed, 1 Sep 2010 18:07:37 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L830022PHT98Z@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 09:07:57 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L83005JGHT95D@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 09:07:57 +0800 (CST) Received: from z63316 ([10.138.84.91]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8300G4ZHT8TZ@szxml06-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 09:07:56 +0800 (CST) Date: Thu, 02 Sep 2010 09:07:56 +0800 From: Ning Zong In-reply-to: To: 'Ross Finlayson' , dispatch@ietf.org Message-id: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActKHYoAPDRs4cU4SbKaYD1ClbYpFwAGPvDg Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 01:07:39 -0000 Hi, Ross, Thank you for your interests in HTTP streaming work. I agree with the point about the title and scope of Pantos I-D, which actually focus on a playlist file format and the corresponding usage in live streaming. In my opinion, we could investigate more about the underlying transport mechanisms for supporting such live streaming, e.g. HTTP/TCP, which involves more WGs and energy in IETF. Please look at Qin's I-D "draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I think that both Pantos I-D and Qin's I-D are good proposals in HTTP streaming area, which shows that there is potentially a lot of interest and more valuable input in this area if we focus these efforts in a closed group. My two cents, BR, Ning Zong -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ross Finlayson Sent: Thursday, September 02, 2010 5:35 AM To: dispatch@ietf.org Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) I agree that "HTTP streaming" should be standardized, and that the IETF appears to be the right place for this to be standardized. Now, to be a little more provocative, here's an email that I sent to the "avt" and "mmusic" mailing lists back in June 2009, when the "pantos-http-live-streaming" draft was (briefly) discussed there. I didn't get any responses to this back then, but there's definitely an "elephant in the room" here that can't be ignored. >Date: Thu, 25 Jun 2009 03:56:51 -0700 >To: avt@ietf.org, mmusic@ietf.org >From: Ross Finlayson >Subject: Re: [AVT] I-D Action:draft-pantos-http-live-streaming-01.txt > >I am pleased that Apple submitted this document as an Internet >Draft. While I feel that much of the subsequent criticism has been >excessively harsh (or in some cases, misguided), I do agree with the >criticism that the document's title could be more descriptive. The >current title - "HTTP Live Streaming" - suggests that it is a broad, >architectural overview document, which this really isn't. A more >meaningful title for this document might be something like > "Using URI Playlist Files to Simulate Live Streaming" > >Nonetheless, if this approach is seen as being useful, then I would >like to see the IETF adopting and standardizing it (or something >similar), because both media streaming and transport protocols >(including HTTP/TCP - the transport protocol most commonly specified >within URIs) are clearly within the IETF's arena. > >However, this document focuses attention on a much bigger issue - a >proverbial "elephant in the room" - that at some point the IETF in >general, and the MMUSIC and AVT working groups in particular, are >going to have to address: > >Thanks to the ever increasing abundance of cheap mass storage, we >are now in a world where media consumption is increasingly 'on >demand' - e.g, via DVRs or online services like YouTube - rather >than live. It seems inevitable that on-demand media playback will >dominate, with live media being relegated to relatively minor niches >where timeliness remains essential. > >Given this, we have to ask ourselves whether there is going to >continue to be a practical role for specialized protocols for live >media, or whether we will see more and more of the live media niches >being satisfied by hacks (like the one described by this draft) that >can make use of the increasingly dominant infrastructure that will >already be in place for on-demand media? Telephony currently >remains a refuge for live media protocols, but how much beyond this >in the future? (There are even companies out there now that are >providing videoconferencing over HTTP, within users' web browsers!) > >I believe that, at the very least, the IETF should try to be more >pragmatic about this (even if it means sometimes tarnishing >architectural purity). To give just one specific example, I'm >disappointed that the IETF did not adopt and standardize Apple's >earlier mechanism (developed several years ago) for tunneling >RTSP/RTP over HTTP. But given the points that I note above, I think >we're going to have to think hard about the future of RTSP in >general... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From abegen@cisco.com Thu Sep 2 01:42:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BB13A6950 for ; Thu, 2 Sep 2010 01:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilP1NrkgLCHi for ; Thu, 2 Sep 2010 01:42:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A39C63A68EB for ; Thu, 2 Sep 2010 01:42:13 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOsAf0yrRN+J/2dsb2JhbACgfHGhJpwYgm2CTASEQYhW X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="scan'208";a="582274555" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2010 08:42:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o828ghFX009742; Thu, 2 Sep 2010 08:42:43 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Sep 2010 01:42:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Sep 2010 01:42:32 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> In-Reply-To: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) Thread-Index: ActKHYoAPDRs4cU4SbKaYD1ClbYpFwAGPvDgABC5muA= References: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> From: "Ali C. Begen (abegen)" To: "Ning Zong" , "Ross Finlayson" , X-OriginalArrivalTime: 02 Sep 2010 08:42:43.0929 (UTC) FILETIME=[CF94C490:01CB4A7A] Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 08:42:15 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Ning Zong > Sent: Thursday, September 02, 2010 4:08 AM > To: 'Ross Finlayson'; dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D = Action:draft-wu-http-streaming-optimization-ps-00.txt) >=20 > Hi, Ross, > Thank you for your interests in HTTP streaming work. > I agree with the point about the title and scope of Pantos I-D, which > actually focus on a playlist file format and the corresponding usage = in live > streaming. In my opinion, we could investigate more about the = underlying > transport mechanisms for supporting such live streaming, e.g. = HTTP/TCP, OK, that is not explicitly mentioned in the Wu draft but let's assume it = is a good idea for the time being. All the other SDOs I am aware of are = staying away from these issues since they don't wanna mandate/require = any changes in the transport to be able to run their specs in the = current deployments.=20 Personally, I would prefer a better transport scheme compared to HTTP = over TCP, if I was allowed to make such changes. Neither TCP nor HTTP is = crafted for this job. > which involves more WGs and energy in IETF. Please look at Qin's I-D > "draft-wu-http-streaming-optimizations-ps-00" for more discussion. = Also, I As I mentioned a month ago, this draft does not identify its goals = clearly. It is like a review of the current status, which is already old = by a few months :) > think that both Pantos I-D and Qin's I-D are good proposals in HTTP > streaming area, which shows that there is potentially a lot of = interest and > more valuable input in this area if we focus these efforts in a closed > group. A playlist format spec is just one component. And that is probably not = the interesting piece for the IETFers. -acbegen=20 From zongning@huawei.com Thu Sep 2 02:03:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49ABC3A68B3 for ; Thu, 2 Sep 2010 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.024 X-Spam-Level: X-Spam-Status: No, score=-100.024 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-SUiNazVxIH for ; Thu, 2 Sep 2010 02:03:17 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 56D5B3A6856 for ; Thu, 2 Sep 2010 02:03:17 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L840066O3TXKH@szxga02-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 17:03:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L84001K33TXEO@szxga02-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 17:03:33 +0800 (CST) Received: from z63316 ([10.138.84.91]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L84006LY3TWLM@szxml04-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 17:03:33 +0800 (CST) Date: Thu, 02 Sep 2010 17:03:32 +0800 From: Ning Zong In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , 'Ross Finlayson' , dispatch@ietf.org Message-id: <009101cb4a7d$b83e7720$5b548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActKHYoAPDRs4cU4SbKaYD1ClbYpFwAGPvDgABC5muAAANQjYA== Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 09:03:18 -0000 Hi, Ali Glad to see your comments. Please see inline. Regards Ning Zong -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Thursday, September 02, 2010 4:43 PM To: Ning Zong; Ross Finlayson; dispatch@ietf.org Subject: RE: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ning Zong > Sent: Thursday, September 02, 2010 4:08 AM > To: 'Ross Finlayson'; dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) > > Hi, Ross, > Thank you for your interests in HTTP streaming work. > I agree with the point about the title and scope of Pantos I-D, which > actually focus on a playlist file format and the corresponding usage in live > streaming. In my opinion, we could investigate more about the underlying > transport mechanisms for supporting such live streaming, e.g. HTTP/TCP, OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other SDOs I am aware of are staying away from these issues since they don't wanna mandate/require any changes in the transport to be able to run their specs in the current deployments. Personally, I would prefer a better transport scheme compared to HTTP over TCP, if I was allowed to make such changes. Neither TCP nor HTTP is crafted for this job. [Ning Zong]: You are right. But I am suspect that changing HTTP or TCP or their combination is easy job here. There has been a way between these 2 layers (like Web-socket) which is worthy of consideration for optimization transportation of HTTP streaming. > which involves more WGs and energy in IETF. Please look at Qin's I-D > "draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I As I mentioned a month ago, this draft does not identify its goals clearly. It is like a review of the current status, which is already old by a few months :) [Ning Zong]: Thank you for mentioning this. We will update the I-D. > think that both Pantos I-D and Qin's I-D are good proposals in HTTP > streaming area, which shows that there is potentially a lot of interest and > more valuable input in this area if we focus these efforts in a closed > group. A playlist format spec is just one component. And that is probably not the interesting piece for the IETFers. [Ning Zong]: Agree. -acbegen From sunseawq@huawei.com Thu Sep 2 02:07:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6353A6950 for ; Thu, 2 Sep 2010 02:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdY-5a9fnVyI for ; Thu, 2 Sep 2010 02:07:46 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AE36F3A68EB for ; Thu, 2 Sep 2010 02:07:45 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L84000BW41HW7@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 17:08:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L84004K841GWA@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 17:08:05 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L840073J41GUP@szxml06-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 17:08:04 +0800 (CST) Date: Thu, 02 Sep 2010 17:08:01 +0800 From: Qin Wu To: "David A. Bryan" , Gerard Fernando Message-id: <056801cb4a7e$58680d60$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> <361654.31400.qm@web24003.mail.ird.yahoo.com> Cc: Gerard.M.X.Fernando@zte.com.cn, dispatch@ietf.org Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 09:07:48 -0000 > In addition, to me this seems much more the sort of work that belongs > at the IETF than somewhere like W3C. [Qin]: Yes, Comparing their difference, I think W3C more looks at client implentation and API standardization while IETF focus on protocol aspect specification. They may be complementary to each other with coordination effort. > Even ignoring the issue that HTTP > itself is defined in the IETF, there are aspects of coordinating a > standard on HTTP streaming that require consideration of transport > issues (fairness, delay, etc.), issues involving real-time > considerations and interoperability with other streaming techniques > (which could touch work on RTP, work in the new PPSP WG, etc.) [Qin]: Yes, Looking at data transport(i.e.,HTTP 1.1), HTTP with tranditional polling support seems not designed for real-time interactive media such as real time voice and video communications, . Therefore it is obvious the interactive media transport is not implemented in the browser itself. Given user expericence into consideration, delivering the same experience as the TV for all consumers or delivering the experience complementary to TV for all consumers is still a big challenges to HTTP Streaming. These chanllenges include delayed starts, poor video quality, and long buffering interruptions. A study conducted by StreamGuard.net examined more than 2,400 different Internet video streams. They concluded that: . 51% of stream viewers were frustrated with the experience. . 17% of streams have an immediate fatal error. . 25% take between 5 and 10 seconds to start playing, and stop to rebuffer before the video is finished. >The membership of the IETF, to me, appears to be the group with the right > skill set, and more importantly, the IETF is responsible for the other > protocols that this inevitably seems to require coordination with, > > I'd like to see us work in this area, and would be interested in participating. [Qin] +1. > David > > On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando wrote: >> Hello, >> >> I also agree with you that it's not the content of the ID that one should >> discuss at this point, instead it is more the direction or policy of IETF >> with regard to this important subject. Being new to the DISPATCH WG >> discussions I'm not sure whether this has been discussed in the last few >> months. >> >> Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very active >> in spec. development, and there seems to be a large degree of coordination >> between those SDO's. Has there been any coordination between them and IETF? >> After all... it is HTTP 1.1 that forms the basis for those efforts! >> >> It is important to understand the policy of IETF with regard to such >> efforts. I hope that IETF does have a role to play with this activity, and >> would at the minimum set some guidelines. >> >> Thanks >> >> Gerard >> ---------- >> >> Gerard Fernando >> ZTE Corporation >> >> ________________________________ >> From: Gonzalo Camarillo >> To: "dispatch@ietf.org" >> Sent: Tue, 31 August, 2010 0:34:07 >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D >> Action:draft-wu-http-streaming-optimization-ps-00.txt) >> >> Hi, >> >> we have not seen any comments on this topic (HTTP streaming). However, >> many people were on vacation in August. Please, send your comments to >> this list. >> >> Thanks, >> >> Gonzalo >> >> On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: >>> Hi, >>> >>> yes, to be clear, the idea is not to only discuss this draft. The idea >>> is to discuss what can be done in the HTTP streaming area at the IETF (I >>> have changes the subject of this email). >>> >>> As Ali pointed out below, this is an important area that is advancing >>> fast. So, we would like to get your input sooner rather than later. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >>>> (Responding to Gonzalo's email) >>>> >>>> I read this draft, but I won't comment on the draft here. Rather, I would >>>> like to understand the goal(s) of this draft. >>>> >>>> HTTP streaming, as noted by the draft, has been around for some time now >>>> and there are already multiple products available. Many groups besides IETF >>>> have shown interest in this topic and worked towards producing their own >>>> specs in the past year. Just last week, MPEG also joined the club and has >>>> started evaluating the received proposals. >>>> >>>> Sure, we can discuss some of the design issues here at IETF. But, do we >>>> want to achieve more than that? If yes, we should be aware of the time >>>> pressure. >>>> >>>> -acbegen >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From sunseawq@huawei.com Thu Sep 2 03:54:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED233A694D for ; Thu, 2 Sep 2010 03:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8Qx3iLJ3h3F for ; Thu, 2 Sep 2010 03:54:52 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 49D513A6934 for ; Thu, 2 Sep 2010 03:54:52 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8400LAC8ZZTF@szxga02-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 18:55:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L84004H18ZZP3@szxga02-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 18:55:11 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L84007X18ZZUP@szxml06-in.huawei.com> for dispatch@ietf.org; Thu, 02 Sep 2010 18:55:11 +0800 (CST) Date: Thu, 02 Sep 2010 18:55:10 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , Ning Zong , Ross Finlayson , dispatch@ietf.org Message-id: <05a101cb4a8d$5054f3e0$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 10:54:53 -0000 Hi, ----- Original Message ----- From: "Ali C. Begen (abegen)" To: "Ning Zong" ; "Ross Finlayson" ; Sent: Thursday, September 02, 2010 4:42 PM Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ning Zong >> Sent: Thursday, September 02, 2010 4:08 AM >> To: 'Ross Finlayson'; dispatch@ietf.org >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) >> >> Hi, Ross, >> Thank you for your interests in HTTP streaming work. >> I agree with the point about the title and scope of Pantos I-D, which >> actually focus on a playlist file format and the corresponding usage in live >> streaming. In my opinion, we could investigate more about the underlying >> transport mechanisms for supporting such live streaming, e.g. HTTP/TCP, > > OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other SDOs I am aware of are staying away from these issues since they don't wanna mandate/require any changes in the transport to be able to run their specs in the current deployments. [Qin]: You are right, take a look at section 8.2 of draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP is not optimal for real-time interactive media application. How to enable efficient and QoS quaranteed communication on the Web is a big chanllenge to HTTP streaming. That's why we need more effort to optimize this transport. > Personally, I would prefer a better transport scheme compared to HTTP over TCP, if I was allowed to make such changes. Neither TCP nor HTTP is crafted for this job. [Qin]: I second this proposal and think it is feasible. Hybi set a good example to do this, which use websocket to provide bi-directional, full-duplex communications channels over a single TCP socket. BTW, would you like share your detailed view on how to provide better transport? :-) >> which involves more WGs and energy in IETF. Please look at Qin's I-D >> "draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I > > As I mentioned a month ago, this draft does not identify its goals clearly. It is like a review of the current status, which is already old by a few months :) [Qin]: Thank for pointing this again, as I said, this I-D is still at the initial stage and waiting for update based on valuable input and feedback. >> think that both Pantos I-D and Qin's I-D are good proposals in HTTP >> streaming area, which shows that there is potentially a lot of interest and >> more valuable input in this area if we focus these efforts in a closed >> group. > > A playlist format spec is just one component. And that is probably not the interesting piece for the IETFers. [Qin]: I Agree that playlist format is only a component, actually there are lots of names for this component, e.g., index file, manifest, mpd. Also depending on playlist as index and existing HTTP 1.1 as transport to request fragment by fragment seems only enable user to watch stream close to live and can not bring efficient communication as RTP/RTSP due to tranditional polling mechanism. > -acbegen > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From abegen@cisco.com Thu Sep 2 04:14:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577AC3A6A7E for ; Thu, 2 Sep 2010 04:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDYBatEeS6-S for ; Thu, 2 Sep 2010 04:14:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1B8103A6934 for ; Thu, 2 Sep 2010 04:14:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJsjf0yrRN+K/2dsb2JhbACgfXGgRJwKgm2CTASEQYhW X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="scan'208";a="357560389" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2010 11:14:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o82BEiw4009846; Thu, 2 Sep 2010 11:14:44 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Sep 2010 04:14: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="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Sep 2010 04:14:54 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D074D15@xmb-sjc-215.amer.cisco.com> In-Reply-To: <05a101cb4a8d$5054f3e0$4f548a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) Thread-Index: ActKjVJdDtnUO1qhRGGfmycQPUrNRwAAcwCA References: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> <05a101cb4a8d$5054f3e0$4f548a0a@china.huawei.com> From: "Ali C. Begen (abegen)" To: "Qin Wu" , "Ning Zong" , "Ross Finlayson" , X-OriginalArrivalTime: 02 Sep 2010 11:14:44.0292 (UTC) FILETIME=[0BBDB840:01CB4A90] Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 11:14:16 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Thursday, September 02, 2010 1:55 PM > To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; = dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: = I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) >=20 > Hi, > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Ning Zong" ; "Ross Finlayson" = ; > Sent: Thursday, September 02, 2010 4:42 PM > Subject: Re: [dispatch] HTTP streaming WAS (Re: = I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf Of Ning Zong > >> Sent: Thursday, September 02, 2010 4:08 AM > >> To: 'Ross Finlayson'; dispatch@ietf.org > >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D = Action:draft-wu-http-streaming-optimization-ps-00.txt) > >> > >> Hi, Ross, > >> Thank you for your interests in HTTP streaming work. > >> I agree with the point about the title and scope of Pantos I-D, = which > >> actually focus on a playlist file format and the corresponding = usage in live > >> streaming. In my opinion, we could investigate more about the = underlying > >> transport mechanisms for supporting such live streaming, e.g. = HTTP/TCP, > > > > OK, that is not explicitly mentioned in the Wu draft but let's = assume it is a good idea for the time being. All the other SDOs I > am aware of are staying away from these issues since they don't wanna = mandate/require any changes in the transport to be > able to run their specs in the current deployments. >=20 > [Qin]: You are right, take a look at section 8.2 of = draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP = is > not optimal for real-time interactive media application. Right, I was just stating a fact that probably everybody agrees with. = But my concern is there is too much deployment in the field and the = currently developed approaches are all refraining from making or = requiring changes to the existing gear/stacks. The question is whether it makes sense for any practical deployment, = provider or owner to adopt the changes that IETF may produce. How much = improvement do we need to make the new approach win? For marginal = improvements, substantial hardware/software upgrade is not justified. > How to enable efficient and QoS quaranteed communication on the Web is = a big chanllenge to HTTP streaming. That's why > we need more effort to optimize this transport. >=20 > > Personally, I would prefer a better transport scheme compared to = HTTP over TCP, if I was allowed to make such changes. > Neither TCP nor HTTP is crafted for this job. >=20 > [Qin]: I second this proposal and think it is feasible. Hybi set a = good example to do this, which use websocket to provide bi- > directional, full-duplex communications channels over a single TCP = socket. That is for bidirectional traffic and streaming is not bidirectional. If = you are consider doing videotelephony over HTTP, that is a different = story and I would think we better separate it from streaming. > BTW, would you like share your detailed view on how to provide better = transport? :-) Maybe something better than TCP (like SCTP), better tailored for the = needs for streaming over http. This certainly would benefit from more = discussion. =20 > >> which involves more WGs and energy in IETF. Please look at Qin's = I-D > >> "draft-wu-http-streaming-optimizations-ps-00" for more discussion. = Also, I > > > > As I mentioned a month ago, this draft does not identify its goals = clearly. It is like a review of the current status, which is > already old by a few months :) >=20 > [Qin]: Thank for pointing this again, as I said, this I-D is still at = the initial stage and waiting for update based on valuable input > and feedback. >=20 > >> think that both Pantos I-D and Qin's I-D are good proposals in HTTP > >> streaming area, which shows that there is potentially a lot of = interest and > >> more valuable input in this area if we focus these efforts in a = closed > >> group. > > > > A playlist format spec is just one component. And that is probably = not the interesting piece for the IETFers. >=20 > [Qin]: I Agree that playlist format is only a component, actually = there are lots of names for this component, e.g., index file, > manifest, mpd. >=20 > Also depending on playlist as index and existing HTTP 1.1 as transport = to request fragment by fragment seems only enable > user to watch stream close > to live and can not bring efficient communication as RTP/RTSP due to = tranditional polling mechanism. Yes, it is inherently pull based, not push. -acbegen =20 > > -acbegen > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Thu Sep 2 06:35:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7653A68EA for ; Thu, 2 Sep 2010 06:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.355 X-Spam-Level: X-Spam-Status: No, score=-5.355 tagged_above=-999 required=5 tests=[AWL=1.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zMUwuJECMO4 for ; Thu, 2 Sep 2010 06:35:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 24DEE3A6994 for ; Thu, 2 Sep 2010 06:35:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-b0-4c7fa8365294 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DE.B6.10125.638AF7C4; Thu, 2 Sep 2010 15:35:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 2 Sep 2010 15:35:50 +0200 From: Christer Holmberg To: "Elwell, John" , IETF DISPATCH list Date: Thu, 2 Sep 2010 15:33:20 +0200 Thread-Topic: [dispatch] I-D Action:draft-wing-dispatch-v6-migration-00.txt Thread-Index: ActGJKw2oMcgdRvBTiyMvEENCOQw8gDyRwAgAC1oFCQ= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585015BCA43@ESESSCMS0356.eemea.ericsson.se> References: <20100827201502.036A93A687E@core3.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] I-D Action:draft-wing-dispatch-v6-migration-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:35:22 -0000 Hi, The draft does not (maybe on purpose) take SBCs into consideration. An SBC would have to establish pinholes for both IPv4 and IPv6, in order to= RTP packages using both versions to pass. In addition you have the issue (not unique to your draft) that there might = not be end-to-end media connectivity in the first place before the call has= been answered etc. Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of El= well, John [john.elwell@siemens-enterprise.com] Sent: Wednesday, September 01, 2010 7:01 PM To: IETF DISPATCH list Subject: Re: [dispatch] I-D Action:draft-wing-dispatch-v6-migration-00.txt Thanks to the authors for writing this draft, which was triggered by the Ba= r BoF in Maastricht, which was in turn triggered by drafts discussed in MMU= SIC such as ICE-microlite (of which I am a co-author) and ALTC. Whilst doubting the need for connectivity checks (whether they be STUN-base= d, RTP-based, RTCP-based or whatever) in certain closed networks, in my opi= nion, where connectivity checks are needed, the existing STUN-based connect= ivity checks will suffice. To introduce a second method (whether RTP-based,= RTCP-based or STUN-based-without-SHA1) will not help interoperability, and= will likely introduce as many problems as it solves. John > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 27 August 2010 21:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-wing-dispatch-v6-migration-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : Migrating SIP to IPv6 Media Without > Connectivity Checks > Author(s) : D. Wing, A. Yourtchenko > Filename : draft-wing-dispatch-v6-migration-00.txt > Pages : 8 > Date : 2010-08-27 > > During the migration from IPv4 to IPv6, it is anticipated that an > IPv6 path might be broken for a variety of reasons, causing endpoints > to not receive RTP data. Connectivity checks would detect and avoid > the user noticing such a problem, but there is industry reluctance to > implement connectivity checks. > > This document describes a mechanism allowing dual-stack SIP endpoints > to attempt communications over IPv6 and fall back to IPv4 if the IPv6 > path is not working. The mechanism does not require connectivity > checks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wing-dispatch-v6-mig ration-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch= From 2mkristensen@gmail.com Thu Sep 2 08:39:39 2010 Return-Path: <2mkristensen@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BC53A6829 for ; Thu, 2 Sep 2010 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P2e6tFXcAR0 for ; Thu, 2 Sep 2010 08:39:37 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 850B93A6811 for ; Thu, 2 Sep 2010 08:39:37 -0700 (PDT) Received: by pvg7 with SMTP id 7so210262pvg.31 for ; Thu, 02 Sep 2010 08:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7TE77/+66S0a3q0BgZq/jpXEcEUuz1ZhNo7ipwXb2xI=; b=nrbyDeC723X/LQEhugJBVAd+BBr+7HFKCE/tGGrpsfQudxq8PFnjczQrR8wZmikmAe guPvTc0DO87j7shBBY1kv8CaIjzlYc1H8t5nWm6aO0c/YTWMjpn5c93C4SEGllS3zbBm aqmC89/9QV8OUNGhX8sQi+aU5JGl5parnWPyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HbGMhagE9YW/6xbYaPdo7jYlKPyQ834rl/0jKhavqmaYTiWJe3w0zjA9+a08uudBOM tAWKfGoVAxA+V++mUG3YaIAxovlkhTpRIKeYSeSDi3MWUJNcSfc6so0FCJyaggGvMJwE dg/3SilXUeI9le2YwkjpOhUZ9NdvZTJRJa70s= MIME-Version: 1.0 Received: by 10.114.39.9 with SMTP id m9mr140609wam.197.1283442006881; Thu, 02 Sep 2010 08:40:06 -0700 (PDT) Received: by 10.220.181.4 with HTTP; Thu, 2 Sep 2010 08:40:06 -0700 (PDT) In-Reply-To: <20100902144502.3AFAA3A6AA0@core3.amsl.com> References: <20100902144502.3AFAA3A6AA0@core3.amsl.com> Date: Thu, 2 Sep 2010 17:40:06 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tomkrist@cisco.com Subject: Re: [dispatch] I-D Action:draft-sandbakken-dispatch-bfcp-udp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:39:39 -0000 On 2 September 2010 16:45, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Revision of the Binary Floor C= ontrol Protocol (BFCP) for use over an unreliable transport > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Thompson, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-sandbakken-dispatch-bfcp-u= dp-00.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 27 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-09-02 > > This memo extends the Binary Floor Control Protocol (BFCP) for use > over an unreliable transport. =A0It details a set of revisions to the > protocol definition document and the specification of Session > Description Protocol (SDP) format for BFCP streams. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sandbakken-dispatch-bfcp-udp-00= .txt This is an updated version of draft-sandbakken-xcon-bfcp-udp-02 and due to XCON closing soon, we have changed name and reset the version count when submitting and associating the draft with Dispatch. An overview of the changes is listed in the draft: http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-00#appendix-A= .1 Notable changes: - Most of the discussion so far - in XCON and on the TSV area list - has dealt with the extension to use UDP as transport, therefore the motivation for this approach is expanded. - How congestion control is done is explained explicitly in the text. - DTLS usage is mandated. Still remaining work on details and adaption to B= FCP. - The Transaction ID syntax and semantics are not changed, used one of the reserved bits for the Transaction Identifier. Comments and feedback are most welcome. Cheers, -- Tom --=20 # TANDBERG, now part of Cisco ## http://www.tandberg.com ### http://folk.uio.no/tomkri/ From csp@csperkins.org Thu Sep 2 12:21:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20ABB3A688C for ; Thu, 2 Sep 2010 12:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La+ytY-wazZp for ; Thu, 2 Sep 2010 12:21:06 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id F00A83A6826 for ; Thu, 2 Sep 2010 12:21:05 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1OrFLr-0000LC-Xz; Thu, 02 Sep 2010 19:21:35 +0000 Message-Id: From: Colin Perkins To: David A. Bryan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 2 Sep 2010 20:21:34 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> <361654.31400.qm@web24003.mail.ird.yahoo.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 19:21:08 -0000 On 1 Sep 2010, at 13:43, David A. Bryan wrote: > I think there are two issues here, Does this work need to be done, > and where to do it? Right. It's clear that having a widely accepted standard in this area would be a good thing. I think it's also clear that the IETF has the expertise to do the work. What's not yet clear to me, though, is what contribution the IETF would make, and why any standard we develop will be accepted by the industry, especially given the ongoing work in other standards bodies. The drafts I've seen submitted (draft-wu-http- streaming-optimization-ps and draft-pantos-http-live-streaming) give a survey and problem statement, and a sketch of playlist-based streaming operation, but primarily describe existing systems, with little new contribution. If there were proposals that leveraged the IETF's strengths -- e.g., tweaking HTTP to improve streaming performance, or giving strong guidance on how to use HTTP in a network-friendly way -- then I'd support spinning-up work in the area, but I've yet to see anything compelling. Cheers, Colin > I think work to define a standard for HTTP streaming certainly needs > to be done. HTTP streaming is becoming more prevalent, and there are > non-compatible standards floating around out there today. As an > example, just today Apple will be broadcasting their September media > event using their own HTTP streaming proposal, and it turns only > Apple hardware users can watch it: > > http://www.macrumors.com/2010/09/01/can-you-watch-apples-keynote-stream-requirements-and-workarounds/ > > The second question is where to do this work. Yes, other standards > organizations have looked at this, but it's not like there haven't > been a good number of proposals brought to the IETF as well. As > Gonzalo pointed out, draft-wu-http-streaming-optimizations-ps-00 is > out there, and draft-pantos-http-livestreaming-04, documenting the > Apple mechanism I discussed above has been brought to the IETF as > well. > > In addition, to me this seems much more the sort of work that > belongs at the IETF than somewhere like W3C. Even ignoring the issue > that HTTP itself is defined in the IETF, there are aspects of > coordinating a standard on HTTP streaming that require consideration > of transport issues (fairness, delay, etc.), issues involving real- > time considerations and interoperability with other streaming > techniques (which could touch work on RTP, work in the new PPSP WG, > etc.) The membership of the IETF, to me, appears to be the group > with the right skill set, and more importantly, the IETF is > responsible for the other protocols that this inevitably seems to > require coordination with, > > I'd like to see us work in this area, and would be interested in > participating. > > David > > On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando > wrote: >> Hello, >> >> I also agree with you that it's not the content of the ID that one >> should discuss at this point, instead it is more the direction or >> policy of IETF with regard to this important subject. Being new to >> the DISPATCH WG discussions I'm not sure whether this has been >> discussed in the last few months. >> >> Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very >> active in spec. development, and there seems to be a large degree >> of coordination between those SDO's. Has there been any >> coordination between them and IETF? After all... it is HTTP 1.1 >> that forms the basis for those efforts! >> >> It is important to understand the policy of IETF with regard to >> such efforts. I hope that IETF does have a role to play with this >> activity, and would at the minimum set some guidelines. >> >> Thanks >> >> Gerard >> ---------- >> >> Gerard Fernando >> ZTE Corporation >> >> ________________________________ >> From: Gonzalo Camarillo >> To: "dispatch@ietf.org" >> Sent: Tue, 31 August, 2010 0:34:07 >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D >> Action:draft-wu-http-streaming-optimization-ps-00.txt) >> >> Hi, >> >> we have not seen any comments on this topic (HTTP streaming). >> However, many people were on vacation in August. Please, send your >> comments to this list. >> >> Thanks, >> >> Gonzalo >> >> On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: >>> Hi, >>> >>> yes, to be clear, the idea is not to only discuss this draft. The >>> idea is to discuss what can be done in the HTTP streaming area at >>> the IETF (I have changes the subject of this email). >>> >>> As Ali pointed out below, this is an important area that is >>> advancing fast. So, we would like to get your input sooner rather >>> than later. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >>>> (Responding to Gonzalo's email) >>>> >>>> I read this draft, but I won't comment on the draft here. Rather, >>>> I would like to understand the goal(s) of this draft. >>>> >>>> HTTP streaming, as noted by the draft, has been around for some >>>> time now and there are already multiple products available. Many >>>> groups besides IETF have shown interest in this topic and worked >>>> towards producing their own specs in the past year. Just last >>>> week, MPEG also joined the club and has started evaluating the >>>> received proposals. >>>> >>>> Sure, we can discuss some of the design issues here at IETF. But, >>>> do we want to achieve more than that? If yes, we should be aware >>>> of the time pressure. >>>> >>>> -acbegen -- Colin Perkins http://csperkins.org/ From henry.sinnreich@gmail.com Thu Sep 2 18:41:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3523A67A1 for ; Thu, 2 Sep 2010 18:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPgXdmuNL4vu for ; Thu, 2 Sep 2010 18:41:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A18343A6784 for ; Thu, 2 Sep 2010 18:41:34 -0700 (PDT) Received: by gyc15 with SMTP id 15so551476gyc.31 for ; Thu, 02 Sep 2010 18:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=+FlxgITpdBMxKHhuyGYMlyrSMvzYnQ/IUC6APJ92gQk=; b=Dnb+uBIQAvenavFjFLUQgowl2zwcym7wrR2fSLZuDE9TI+FMj00Q83GnWrgbLhNws6 Q/pad/FtkZ09XpW+W3Y60ITobq2NUzXsAJFRI4TTJw2pwW26GjeiIBwbBLSbJ6d71J5F OqnUNxdUk77J5O74I3V5ZWEYPYWkddXDEzI8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=CAQED9Ts5OJYi3BuSePrCTxTBEtyMQfM5cgqKiT8JjvmLj3CdonIDU3EzJKxETU3OJ dsbJqw77AgmQvcw/uPgjR/xWbWIPgp69EJLwpyc5EzkUf6NU3GrkSrgOE5xu2FF1o8cX h1a4YQJ/6CWzZVx9pH661FLuceaYgUtopWwj4= Received: by 10.151.49.9 with SMTP id b9mr123049ybk.177.1283478124188; Thu, 02 Sep 2010 18:42:04 -0700 (PDT) Received: from [192.168.0.34] (cpe-76-184-253-44.tx.res.rr.com [76.184.253.44]) by mx.google.com with ESMTPS id u24sm390929yba.9.2010.09.02.18.42.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Sep 2010 18:42:03 -0700 (PDT) User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 02 Sep 2010 20:42:00 -0500 From: Henry Sinnreich To: Colin Perkins , "David A. Bryan" Message-ID: Thread-Topic: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) Thread-Index: ActLCTNw76RSwyNkAkGnyn77B73Q0A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 01:41:39 -0000 I believe Colin says here the operational word, if I understand correctly: >tweaking HTTP to improve streaming performance, or >giving strong guidance on how to use HTTP in a network-friendly way ...and I would like to add, taking into consideration the requirements for network elements in Content Distribution Networks (CDN) to support streaming HTTP. Specifically, what are the standards requirements for CDN network elements for interoperability with existing streaming implementations? There is an excellent overview here from the perspective of the client and servers, but CDN, though mentioned, are not described or referenced as far as I could find. Does anyone know? http://developer.apple.com/iphone/library/documentation/networkinginternet/c onceptual/streamingmediaguide/HTTPStreamingArchitecture/HTTPStreamingArchite cture.html Thanks, Henry On 9/2/10 2:21 PM, "Colin Perkins" wrote: > On 1 Sep 2010, at 13:43, David A. Bryan wrote: >> I think there are two issues here, Does this work need to be done, >> and where to do it? > > Right. It's clear that having a widely accepted standard in this area > would be a good thing. I think it's also clear that the IETF has the > expertise to do the work. What's not yet clear to me, though, is what > contribution the IETF would make, and why any standard we develop will > be accepted by the industry, especially given the ongoing work in > other standards bodies. The drafts I've seen submitted (draft-wu-http- > streaming-optimization-ps and draft-pantos-http-live-streaming) give a > survey and problem statement, and a sketch of playlist-based streaming > operation, but primarily describe existing systems, with little new > contribution. If there were proposals that leveraged the IETF's > strengths -- e.g., tweaking HTTP to improve streaming performance, or > giving strong guidance on how to use HTTP in a network-friendly way -- > then I'd support spinning-up work in the area, but I've yet to see > anything compelling. > > Cheers, > Colin > > > > >> I think work to define a standard for HTTP streaming certainly needs >> to be done. HTTP streaming is becoming more prevalent, and there are >> non-compatible standards floating around out there today. As an >> example, just today Apple will be broadcasting their September media >> event using their own HTTP streaming proposal, and it turns only >> Apple hardware users can watch it: >> >> http://www.macrumors.com/2010/09/01/can-you-watch-apples-keynote-stream-requi >> rements-and-workarounds/ >> >> The second question is where to do this work. Yes, other standards >> organizations have looked at this, but it's not like there haven't >> been a good number of proposals brought to the IETF as well. As >> Gonzalo pointed out, draft-wu-http-streaming-optimizations-ps-00 is >> out there, and draft-pantos-http-livestreaming-04, documenting the >> Apple mechanism I discussed above has been brought to the IETF as >> well. >> >> In addition, to me this seems much more the sort of work that >> belongs at the IETF than somewhere like W3C. Even ignoring the issue >> that HTTP itself is defined in the IETF, there are aspects of >> coordinating a standard on HTTP streaming that require consideration >> of transport issues (fairness, delay, etc.), issues involving real- >> time considerations and interoperability with other streaming >> techniques (which could touch work on RTP, work in the new PPSP WG, >> etc.) The membership of the IETF, to me, appears to be the group >> with the right skill set, and more importantly, the IETF is >> responsible for the other protocols that this inevitably seems to >> require coordination with, >> >> I'd like to see us work in this area, and would be interested in >> participating. >> >> David >> >> On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando >> wrote: >>> Hello, >>> >>> I also agree with you that it's not the content of the ID that one >>> should discuss at this point, instead it is more the direction or >>> policy of IETF with regard to this important subject. Being new to >>> the DISPATCH WG discussions I'm not sure whether this has been >>> discussed in the last few months. >>> >>> Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very >>> active in spec. development, and there seems to be a large degree >>> of coordination between those SDO's. Has there been any >>> coordination between them and IETF? After all... it is HTTP 1.1 >>> that forms the basis for those efforts! >>> >>> It is important to understand the policy of IETF with regard to >>> such efforts. I hope that IETF does have a role to play with this >>> activity, and would at the minimum set some guidelines. >>> >>> Thanks >>> >>> Gerard >>> ---------- >>> >>> Gerard Fernando >>> ZTE Corporation >>> >>> ________________________________ >>> From: Gonzalo Camarillo >>> To: "dispatch@ietf.org" >>> Sent: Tue, 31 August, 2010 0:34:07 >>> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D >>> Action:draft-wu-http-streaming-optimization-ps-00.txt) >>> >>> Hi, >>> >>> we have not seen any comments on this topic (HTTP streaming). >>> However, many people were on vacation in August. Please, send your >>> comments to this list. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> yes, to be clear, the idea is not to only discuss this draft. The >>>> idea is to discuss what can be done in the HTTP streaming area at >>>> the IETF (I have changes the subject of this email). >>>> >>>> As Ali pointed out below, this is an important area that is >>>> advancing fast. So, we would like to get your input sooner rather >>>> than later. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >>>>> (Responding to Gonzalo's email) >>>>> >>>>> I read this draft, but I won't comment on the draft here. Rather, >>>>> I would like to understand the goal(s) of this draft. >>>>> >>>>> HTTP streaming, as noted by the draft, has been around for some >>>>> time now and there are already multiple products available. Many >>>>> groups besides IETF have shown interest in this topic and worked >>>>> towards producing their own specs in the past year. Just last >>>>> week, MPEG also joined the club and has started evaluating the >>>>> received proposals. >>>>> >>>>> Sure, we can discuss some of the design issues here at IETF. But, >>>>> do we want to achieve more than that? If yes, we should be aware >>>>> of the time pressure. >>>>> >>>>> -acbegen > From gonzalo.camarillo@ericsson.com Fri Sep 3 00:38:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691173A67FE for ; Fri, 3 Sep 2010 00:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.758 X-Spam-Level: X-Spam-Status: No, score=-103.758 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6ZeghoLKImJ for ; Fri, 3 Sep 2010 00:38:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 280383A67F6 for ; Fri, 3 Sep 2010 00:38:56 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-c3-4c80a62e9bc9 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.19.06895.E26A08C4; Fri, 3 Sep 2010 09:39:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Sep 2010 09:39:25 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Sep 2010 09:39:25 +0200 Message-ID: <4C80A62D.9010209@ericsson.com> Date: Fri, 03 Sep 2010 10:39:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2010 07:39:25.0833 (UTC) FILETIME=[22270F90:01CB4B3B] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Liaison statement from ETSI Human Factors X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 07:38:58 -0000 Folks, FYI: we have received the following LS from ETSI HF: https://datatracker.ietf.org/documents/LIAISON/file1085.doc As you can see, it relates to the registration of two SIP header fields and the use of MESSAGE requests. Per RFC 5727, the registration of the header fields will require an expert review. The use of the MESSAGE request will be discussed in the SIMPLE WG mailing list. We will return a response to this LS once we have gotten input from the SIMPLE community. Cheers, Gonzalo From sunseawq@huawei.com Fri Sep 3 01:24:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF2B3A681F for ; Fri, 3 Sep 2010 01:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YISTBVTgG5U for ; Fri, 3 Sep 2010 01:24:57 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1E1203A681A for ; Fri, 3 Sep 2010 01:24:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L85003DOWQ2RV@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 03 Sep 2010 16:25:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L85006EGWQ2MN@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 03 Sep 2010 16:25:14 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L85005MOWQ1G0@szxml04-in.huawei.com> for dispatch@ietf.org; Fri, 03 Sep 2010 16:25:14 +0800 (CST) Date: Fri, 03 Sep 2010 16:25:13 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , Ning Zong , Ross Finlayson , dispatch@ietf.org Message-id: <0a1801cb4b41$8826c230$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> <05a101cb4a8d$5054f3e0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D15@xmb-sjc-215.amer.cisco.com> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 08:24:59 -0000 ----- Original Message ----- From: "Ali C. Begen (abegen)" To: "Qin Wu" ; "Ning Zong" ; "Ross Finlayson" ; Sent: Thursday, September 02, 2010 7:14 PM Subject: RE: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Thursday, September 02, 2010 1:55 PM > To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > Hi, > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Ning Zong" ; "Ross Finlayson" ; > Sent: Thursday, September 02, 2010 4:42 PM > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ning Zong > >> Sent: Thursday, September 02, 2010 4:08 AM > >> To: 'Ross Finlayson'; dispatch@ietf.org > >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) > >> > >> Hi, Ross, > >> Thank you for your interests in HTTP streaming work. > >> I agree with the point about the title and scope of Pantos I-D, which > >> actually focus on a playlist file format and the corresponding usage in live > >> streaming. In my opinion, we could investigate more about the underlying > >> transport mechanisms for supporting such live streaming, e.g. HTTP/TCP, > > > > OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other SDOs I > am aware of are staying away from these issues since they don't wanna mandate/require any changes in the transport to be > able to run their specs in the current deployments. > > [Qin]: You are right, take a look at section 8.2 of draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP is > not optimal for real-time interactive media application. Right, I was just stating a fact that probably everybody agrees with. But my concern is there is too much deployment in the field and the currently developed approaches are all refraining from making or requiring changes to the existing gear/stacks. The question is whether it makes sense for any practical deployment, provider or owner to adopt the changes that IETF may produce. How much improvement do we need to make the new approach win? For marginal improvements, substantial hardware/software upgrade is not justified. [Qin]: This seems a big question. In my understanding, With zero change to the existing gear/stacks: 1.Encoding live video for streaming over the Internet is extremely complicated and demands extensive CPU power. Therefore the current implementation may encourage the content publisher to reduce image quality, shrink the frame size, or force the user to experience long start/seek times so that the client-based player has time to buffer content. While these improve the situation by reducing the volume of data sent or allowing the player to get ahead, the viewing experience is severely sacrificed. 2. The current implentation may depend on multiple bit rates encoding to deliver the same content with different quality to clients however the cost of Multiple Bit rate encoding is very expensive, especially when streaming live video. 3. With the current implentation, client polling for playlist is okay, client polling for real time data fragment by fragment is not efficient way. Given these above aspects, I am wondering whether the STB users or Mobile users are acceptable to the such playback experience when they watch program using browser, which may be far from TV viewing experience.Doesn't this worth improvement/optimization? For how much improvment do we need to make the new approach win, we may look at this academic paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.574&rep=rep1&type=pdf > How to enable efficient and QoS quaranteed communication on the Web is a big chanllenge to HTTP streaming. That's why > we need more effort to optimize this transport. > > > Personally, I would prefer a better transport scheme compared to HTTP over TCP, if I was allowed to make such changes. > Neither TCP nor HTTP is crafted for this job. > > [Qin]: I second this proposal and think it is feasible. Hybi set a good example to do this, which use websocket to provide bi- > directional, full-duplex communications channels over a single TCP socket. That is for bidirectional traffic and streaming is not bidirectional. If you are consider doing videotelephony over HTTP, that is a different story and I would think we better separate it from streaming. [Qin]: Agree. > BTW, would you like share your detailed view on how to provide better transport? :-) Maybe something better than TCP (like SCTP), better tailored for the needs for streaming over http. This certainly would benefit from more discussion. [Qin] Sounds like a good idea. So the serious issues we may need to look at are: How does HTTP Streaming support real time communication? How to enable migration of the real time application to Web? Any thoughts? > >> which involves more WGs and energy in IETF. Please look at Qin's I-D > >> "draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I > > > > As I mentioned a month ago, this draft does not identify its goals clearly. It is like a review of the current status, which is > already old by a few months :) > > [Qin]: Thank for pointing this again, as I said, this I-D is still at the initial stage and waiting for update based on valuable input > and feedback. > > >> think that both Pantos I-D and Qin's I-D are good proposals in HTTP > >> streaming area, which shows that there is potentially a lot of interest and > >> more valuable input in this area if we focus these efforts in a closed > >> group. > > > > A playlist format spec is just one component. And that is probably not the interesting piece for the IETFers. > > [Qin]: I Agree that playlist format is only a component, actually there are lots of names for this component, e.g., index file, > manifest, mpd. > > Also depending on playlist as index and existing HTTP 1.1 as transport to request fragment by fragment seems only enable > user to watch stream close > to live and can not bring efficient communication as RTP/RTSP due to tranditional polling mechanism. Yes, it is inherently pull based, not push. [Qin] Right. -acbegen > > -acbegen > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From svshesha@cisco.com Fri Sep 3 02:22:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F81C3A682D for ; Fri, 3 Sep 2010 02:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s13697GptebH for ; Fri, 3 Sep 2010 02:22:50 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9A0783A6819 for ; Fri, 3 Sep 2010 02:22:50 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI5bgExAaMHG/2dsb2JhbAChDHGhDJwYhTsEhD+IWA X-IronPort-AV: E=Sophos;i="4.56,312,1280707200"; d="scan'208";a="249312780" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 03 Sep 2010 09:23:19 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o839NA1k008566; Fri, 3 Sep 2010 09:23:18 GMT Received: from xmb-bgl-41d.cisco.com ([72.163.129.219]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Sep 2010 14:52:43 +0530 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 Date: Fri, 3 Sep 2010 14:52:42 +0530 Message-ID: <28FC823DF72A5F49B694914951A0A83201FFB6F6@XMB-BGL-41D.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] [dispatch] SIP Resource availabilityEvent package Thread-Index: ActJ1hBGEEczs/j0T/6JX9pC5rduLwBbprkwAAEyZkA= References: <20100830142058.6A0EA3A69B8@core3.amsl.com><5D9746F9-9D36-4482-8B61-94AED338EDE2@gmail.com> From: "Sheshadri Shalya (svshesha)" To: "Sheshadri Shalya (svshesha)" , "RahulSrivastava 71616" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 03 Sep 2010 09:22:43.0017 (UTC) FILETIME=[8FF64B90:01CB4B49] Cc: dispatch@ietf.org Subject: Re: [dispatch] [sip-overload] SIP Resource availabilityEvent package X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 09:22:52 -0000 Moving this discussion to dispatch alias.. -----Original Message----- From: Sheshadri Shalya (svshesha)=20 Sent: Friday, September 03, 2010 2:51 PM To: 'RahulSrivastava 71616'; Parthasarathi R (partr) Cc: sip-overload@ietf.org; mediactrl@ietf.org Subject: RE: [sip-overload] [dispatch] SIP Resource availabilityEvent package Rahul, Thanks for your comments/suggestions. See responses inline: Thanks, Shesh -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of RahulSrivastava 71616 Sent: Wednesday, September 01, 2010 6:32 PM To: Parthasarathi R (partr) Cc: sip-overload@ietf.org; mediactrl@ietf.org Subject: Re: [sip-overload] [dispatch] SIP Resource availabilityEvent package I have some queries/suggestions on this draft: 1. Can we have a figure for network topology where this device is being targetted and which=20 entity performs which function? This will make document very clear. In Section 6, we have indicated the use cases. We can add topology diagram to make those use cases clear. The topologies could be=20 1. SIP server -------- Resource monitor=20 2. SIP server -----Proxy ------Resource monitor =20 2. value=3D"cpu|memory|ds0|dsp|storage|([a-z][a-z0-9])*"/> This CPU is total system CPU or process CPU?=20 If its per process CPU and SIPServer is multi process (with single entry point) does it add the values=20 or how much it should be indicated.=20 This CPU is total system CPU. Based on the system architecture, additional sub-types could be added as required. =20 3. does this draft mandates resource monitor works on different CPUs?=20 If not some then does it need to substract its own CPU while applying overload alogorithm. This draft does not mandate the resource monitor on different CPUs. This again depends on the system architecture.=20 4. "ICMP message received during dialog creation from the Notifying entity" ----> Is it ICMP error? It is for ICMP error. We will update the text to be more specific. =20 Hence is this mandatory for SIP Servers to know ping status of SIPServers? I am not clear on the question here. In case if you are asking to know whether SIP server is alive or not, then, it is covered as part of SUB/NOT mechanism mentioned in the draft. 5. If SIPServer has more than one incoming pxys and each of the pxys subscribe for this events. This SUBSCRIPTION becomes heavy. Do we need to see those areas or this is ok? The intention here is to have single to few resource monitoring entity with multiple devices reporting to these resource monitors. In case, the resource monitoring entity is monitoring multiple devices, even in that case, as there is only one SUBSCRIPTION per device, it is not going to be heavy. Regards, Rahul ************************************************************************ ****************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! =20 ************************************************************************ ***************** ----- Original Message ----- From: "Parthasarathi R (partr)" Date: Wednesday, September 1, 2010 9:06 am Subject: Re: [sip-overload] [dispatch] SIP Resource availability Event package To: Michael Miller Cc: sip-ops@ietf.org, dispatch@ietf.org, sip-overload@ietf.org, mediactrl@ietf.org > Michael, >=20 > Thanks for the comment. In the draft, Almost-out-of-resource=20 > element for the particular resource has to be used whenever the=20 > resource is reaching the critical condition (threshold) and it is=20 > explained in sec 5.4.1. Almost-out-of-resource indication provides=20 > the alert to the administrator about overuse of the specific=20 > resource in a particular device. I'll add the text in the resource=20 > availability indication mechanism for providing more clarity. >=20 > Thanks > Partha >=20 > ________________________________ >=20 > From: Michael Miller [mailto:mlm.michael.miller@gmail.com] > Sent: Wed 9/1/2010 3:05 AM > To: Parthasarathi R (partr) > Cc: ; sip-ops@ietf.org; sip-overload@ietf.org;=20 > mediactrl@ietf.orgSubject: Re: [dispatch] SIP Resource=20 > availability Event package >=20 >=20 > This draft looks pretty good. Should there be language that saids=20 > management servers are alerted of critical conditions or is that=20 > outside of this draft? >=20 > Michael L. Miller > Sent from my Mobile Device >=20 > On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)"=20 > wrote: >=20 >=20 >=20 > =09 > Resource availability information from SIP devices improves the=20 > manageability of SIP devices by providing a framework for multiple=20 > applications like Resource utilization monitoring, overload=20 > handling in SIP based media servers.=20 >=20 > This draft was discussed in IETF-78 SoC WG and considered as=20 > outside the scope of SOC as it focus on SIP overload based on non- > critical resources like DS0, DSP. By looking at the mediactrl WG=20 > charter and working documents, I doubt that this draft will falls=20 > under current media-ctrl work. As this draft helps in SIP based=20 > devices manageability, I looked for SIP manageability related WG=20 > but Sip-ops mailing alias only exists and there is no WG=20 > associated with it. So, I'm putting this document in dispatch WG=20 > for further proceedings.=20 >=20 > Abstract is as follows: >=20 > "Collecting Resource availability information in Session=20 > Initiation Protocol (SIP) devices in real time helps in better=20 > manageability of resources in the SIP network. Resource=20 > availability monitoring in SIP devices helps administrator to take=20 > informed decision and corrective measures to tackle under or over=20 > resource utilization in the network. Resource availability=20 > information can also be used for SIP overload control in SIP based=20 > Media servers by passing resource demand vector between devices.=20 > This document defines resource availability XML document and the=20 > mechanisms that can be used to exchange the document between SIP=20 > entities." > =09 >=20 > The draft is available at http://datatracker.ietf.org/doc/draft- > partha-dispatch-resource-availability/=20 > availability/> . Could you please provide your valuable comments. >=20 > Thanks >=20 > Partha >=20 > =09 > =09 >=20 > ________________________________ >=20 > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Mon 8/30/2010 7:50 PM > To: Parthasarathi R (partr) > Cc: Sheshadri Shalya (svshesha) > Subject: New Version Notification for draft-partha-dispatch- > resource-availability-00=20 > =09 > =09 >=20 > =09 >=20 >=20 > A new version of I-D, draft-partha-dispatch-resource-availability- > 00.txt has been successfully submitted by Parthasarathi R and=20 > posted to the IETF repository. > =09 > Filename: draft-partha-dispatch-resource-availability > Revision: 00 > Title: Session Initiation Protocol (SIP) Resource=20 > availability Event package > Creation_date: 2010-08-30 > WG ID: Independent Submission > Number_of_pages: 17 > =09 > Abstract: > Collecting Resource availability information in Session Initiation > Protocol (SIP) devices in real time helps in better managebility of > resources in the SIP network. Resource availability monitoring in > SIP devices helps administrator to take informed decision and > corrective measures to tackle under or over resource utilization in > the network. Resource availability information can also be used for > SIP overload control in SIP based Media servers by passing resource > demand vector between devices. This document defines resource > availability XML document and the mechanisms that can be used to > exchange the document between SIP entities. > =20 > =20 > =09 > =09 > The IETF Secretariat. > =09 > =09 > =09 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =09 >=20 >=20 _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From sunseawq@huawei.com Fri Sep 3 02:58:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4D23A68FA for ; Fri, 3 Sep 2010 02:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDag1qvM-sRf for ; Fri, 3 Sep 2010 02:58:01 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3E7153A68E2 for ; Fri, 3 Sep 2010 02:54:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L86009RX0VS9K@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 03 Sep 2010 17:55:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L860065U0VR8Z@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 03 Sep 2010 17:55:03 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L86003Z10VQCL@szxml06-in.huawei.com> for dispatch@ietf.org; Fri, 03 Sep 2010 17:55:03 +0800 (CST) Date: Fri, 03 Sep 2010 17:55:02 +0800 From: Qin Wu To: Colin Perkins , "David A. Bryan" Message-id: <0c0801cb4b4e$144a7f70$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> <361654.31400.qm@web24003.mail.ird.yahoo.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 09:58:08 -0000 ----- Original Message ----- From: "Colin Perkins" To: "David A. Bryan" Cc: Sent: Friday, September 03, 2010 3:21 AM Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > On 1 Sep 2010, at 13:43, David A. Bryan wrote: >> I think there are two issues here, Does this work need to be done, >> and where to do it? > > Right. It's clear that having a widely accepted standard in this area > would be a good thing. I think it's also clear that the IETF has the > expertise to do the work. What's not yet clear to me, though, is what > contribution the IETF would make, and why any standard we develop will > be accepted by the industry, especially given the ongoing work in > other standards bodies. The drafts I've seen submitted (draft-wu-http- > streaming-optimization-ps and draft-pantos-http-live-streaming) give a > survey and problem statement, and a sketch of playlist-based streaming > operation, but primarily describe existing systems, with little new > contribution. If there were proposals that leveraged the IETF's > strengths -- e.g., tweaking HTTP to improve streaming performance, or > giving strong guidance on how to use HTTP in a network-friendly way -- > then I'd support spinning-up work in the area, but I've yet to see > anything compelling. [Qin]: Good point. One of my thoughts would be the current HTTP Streaming has not been effective in delivering high-quality video content across the Internet. The typical user experience is limited by delayed startups, poor quality, buffering delays.Does it worth providing better transport scheme to improve streaming performance, satisfy the video quality requirements (e.g., bandwidth, layered video codec, delay and loss requirements)? Does it make sense to head toward this direction. > Cheers, > Colin > > > > >> I think work to define a standard for HTTP streaming certainly needs >> to be done. HTTP streaming is becoming more prevalent, and there are >> non-compatible standards floating around out there today. As an >> example, just today Apple will be broadcasting their September media >> event using their own HTTP streaming proposal, and it turns only >> Apple hardware users can watch it: >> >> http://www.macrumors.com/2010/09/01/can-you-watch-apples-keynote-stream-requirements-and-workarounds/ >> >> The second question is where to do this work. Yes, other standards >> organizations have looked at this, but it's not like there haven't >> been a good number of proposals brought to the IETF as well. As >> Gonzalo pointed out, draft-wu-http-streaming-optimizations-ps-00 is >> out there, and draft-pantos-http-livestreaming-04, documenting the >> Apple mechanism I discussed above has been brought to the IETF as >> well. >> >> In addition, to me this seems much more the sort of work that >> belongs at the IETF than somewhere like W3C. Even ignoring the issue >> that HTTP itself is defined in the IETF, there are aspects of >> coordinating a standard on HTTP streaming that require consideration >> of transport issues (fairness, delay, etc.), issues involving real- >> time considerations and interoperability with other streaming >> techniques (which could touch work on RTP, work in the new PPSP WG, >> etc.) The membership of the IETF, to me, appears to be the group >> with the right skill set, and more importantly, the IETF is >> responsible for the other protocols that this inevitably seems to >> require coordination with, >> >> I'd like to see us work in this area, and would be interested in >> participating. >> >> David >> >> On Tue, Aug 31, 2010 at 10:15 PM, Gerard Fernando > > wrote: >>> Hello, >>> >>> I also agree with you that it's not the content of the ID that one >>> should discuss at this point, instead it is more the direction or >>> policy of IETF with regard to this important subject. Being new to >>> the DISPATCH WG discussions I'm not sure whether this has been >>> discussed in the last few months. >>> >>> Several other SDO's (MPEG, 3GPP and Open IPTV Forum) have been very >>> active in spec. development, and there seems to be a large degree >>> of coordination between those SDO's. Has there been any >>> coordination between them and IETF? After all... it is HTTP 1.1 >>> that forms the basis for those efforts! >>> >>> It is important to understand the policy of IETF with regard to >>> such efforts. I hope that IETF does have a role to play with this >>> activity, and would at the minimum set some guidelines. >>> >>> Thanks >>> >>> Gerard >>> ---------- >>> >>> Gerard Fernando >>> ZTE Corporation >>> >>> ________________________________ >>> From: Gonzalo Camarillo >>> To: "dispatch@ietf.org" >>> Sent: Tue, 31 August, 2010 0:34:07 >>> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D >>> Action:draft-wu-http-streaming-optimization-ps-00.txt) >>> >>> Hi, >>> >>> we have not seen any comments on this topic (HTTP streaming). >>> However, many people were on vacation in August. Please, send your >>> comments to this list. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> yes, to be clear, the idea is not to only discuss this draft. The >>>> idea is to discuss what can be done in the HTTP streaming area at >>>> the IETF (I have changes the subject of this email). >>>> >>>> As Ali pointed out below, this is an important area that is >>>> advancing fast. So, we would like to get your input sooner rather >>>> than later. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >>>>> (Responding to Gonzalo's email) >>>>> >>>>> I read this draft, but I won't comment on the draft here. Rather, >>>>> I would like to understand the goal(s) of this draft. >>>>> >>>>> HTTP streaming, as noted by the draft, has been around for some >>>>> time now and there are already multiple products available. Many >>>>> groups besides IETF have shown interest in this topic and worked >>>>> towards producing their own specs in the past year. Just last >>>>> week, MPEG also joined the club and has started evaluating the >>>>> received proposals. >>>>> >>>>> Sure, we can discuss some of the design issues here at IETF. But, >>>>> do we want to achieve more than that? If yes, we should be aware >>>>> of the time pressure. >>>>> >>>>> -acbegen > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Fri Sep 3 08:02:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC69F3A68D3 for ; Fri, 3 Sep 2010 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.707 X-Spam-Level: X-Spam-Status: No, score=-102.707 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSguO1AB4ZbB for ; Fri, 3 Sep 2010 08:02:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 005DE3A68EF for ; Fri, 3 Sep 2010 08:02:53 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o83F3JGG017455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 10:03:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C810E37.5040300@nostrum.com> Date: Fri, 03 Sep 2010 10:03:19 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C80A62D.9010209@ericsson.com> In-Reply-To: <4C80A62D.9010209@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH Subject: Re: [dispatch] Liaison statement from ETSI Human Factors X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 15:02:58 -0000 As input to whoever performs expert review on this document: I want to point out that the networks they're talking about are processing between 0.0019 and 0.0063 calls per second. I don't think it's safe to extrapolate how well the approach will scale to larger networks from these kinds of traffic volumes. In particular, the liaison statement claims that the normative statements in RFC 3428 can be safely ignored based on these trials: "Empirical evidence from all market deployments studied does not indicate any issues with overloaded SIP servers." I don't think one can reasonably discard the recommendations of RFC 3428 based on networks that process only 550 calls per day. /a On 9/3/10 2:39 AM, Gonzalo Camarillo wrote: > Folks, > > FYI: we have received the following LS from ETSI HF: > > https://datatracker.ietf.org/documents/LIAISON/file1085.doc > > As you can see, it relates to the registration of two SIP header fields > and the use of MESSAGE requests. Per RFC 5727, the registration of the > header fields will require an expert review. The use of the MESSAGE > request will be discussed in the SIMPLE WG mailing list. We will return > a response to this LS once we have gotten input from the SIMPLE community. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Fri Sep 3 08:42:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21813A68E5 for ; Fri, 3 Sep 2010 08:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4o3FEUdZXf6 for ; Fri, 3 Sep 2010 08:42:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 417273A6908 for ; Fri, 3 Sep 2010 08:42:26 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o83FgpAs020617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 10:42:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C811779.10401@nostrum.com> Date: Fri, 03 Sep 2010 10:42:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C80A62D.9010209@ericsson.com> <4C810E37.5040300@nostrum.com> In-Reply-To: <4C810E37.5040300@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH Subject: Re: [dispatch] Liaison statement from ETSI Human Factors X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 15:42:28 -0000 Sorry -- wrong list. I meant to post this to SIMPLE. I'll re-send it there /a On 9/3/10 10:03 AM, Adam Roach wrote: > As input to whoever performs expert review on this document: I want > to point out that the networks they're talking about are processing > between 0.0019 and 0.0063 calls per second. I don't think it's safe to > extrapolate how well the approach will scale to larger networks from > these kinds of traffic volumes. > > In particular, the liaison statement claims that the normative > statements in RFC 3428 can be safely ignored based on these trials: > "Empirical evidence from all market deployments studied does not > indicate any issues with overloaded SIP servers." > > I don't think one can reasonably discard the recommendations of RFC > 3428 based on networks that process only 550 calls per day. > > /a > > On 9/3/10 2:39 AM, Gonzalo Camarillo wrote: >> Folks, >> >> FYI: we have received the following LS from ETSI HF: >> >> https://datatracker.ietf.org/documents/LIAISON/file1085.doc >> >> As you can see, it relates to the registration of two SIP header fields >> and the use of MESSAGE requests. Per RFC 5727, the registration of the >> header fields will require an expert review. The use of the MESSAGE >> request will be discussed in the SIMPLE WG mailing list. We will return >> a response to this LS once we have gotten input from the SIMPLE >> community. >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From abegen@cisco.com Mon Sep 6 01:40:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B2E3A685A for ; Mon, 6 Sep 2010 01:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.272 X-Spam-Level: X-Spam-Status: No, score=-9.272 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzyPl5aiyf4Y for ; Mon, 6 Sep 2010 01:40:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D2B783A689F for ; Mon, 6 Sep 2010 01:40:19 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL5FhEyrR7Hu/2dsb2JhbAChE3GgXZsChT0EhEOIUw X-IronPort-AV: E=Sophos;i="4.56,324,1280707200"; d="scan'208";a="584176389" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 06 Sep 2010 08:40:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o868emCK017372; Mon, 6 Sep 2010 08:40:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 01:40:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Sep 2010 01:40:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D128B25@xmb-sjc-215.amer.cisco.com> In-Reply-To: <0a1801cb4b41$8826c230$4f548a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) Thread-Index: ActLQYtMBbGlZc9ZSS28BLuc/bWXeACXFqmg References: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> <05a101cb4a8d$5054f3e0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D15@xmb-sjc-215.amer.cisco.com> <0a1801cb4b41$8826c230$4f548a0a@china.huawei.com> From: "Ali C. Begen (abegen)" To: "Qin Wu" , "Ning Zong" , "Ross Finlayson" , X-OriginalArrivalTime: 06 Sep 2010 08:40:48.0486 (UTC) FILETIME=[346C9060:01CB4D9F] Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 08:40:21 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, September 03, 2010 11:25 AM > To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; = dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: = I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) >=20 > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Qin Wu" ; "Ning Zong" ; = "Ross Finlayson" ; > > Sent: Thursday, September 02, 2010 7:14 PM > Subject: RE: [dispatch] HTTP streaming WAS (Re: = I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Thursday, September 02, 2010 1:55 PM > > To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; = dispatch@ietf.org > > Subject: Re: [dispatch] HTTP streaming WAS (Re: = I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > > > Hi, > > ----- Original Message ----- > > From: "Ali C. Begen (abegen)" > > To: "Ning Zong" ; "Ross Finlayson" = ; > > Sent: Thursday, September 02, 2010 4:42 PM > > Subject: Re: [dispatch] HTTP streaming WAS (Re: = I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] On Behalf Of Ning Zong > > >> Sent: Thursday, September 02, 2010 4:08 AM > > >> To: 'Ross Finlayson'; dispatch@ietf.org > > >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D = Action:draft-wu-http-streaming-optimization-ps-00.txt) > > >> > > >> Hi, Ross, > > >> Thank you for your interests in HTTP streaming work. > > >> I agree with the point about the title and scope of Pantos I-D, = which > > >> actually focus on a playlist file format and the corresponding = usage in live > > >> streaming. In my opinion, we could investigate more about the = underlying > > >> transport mechanisms for supporting such live streaming, e.g. = HTTP/TCP, > > > > > > OK, that is not explicitly mentioned in the Wu draft but let's = assume it is a good idea for the time being. All the other > SDOs I > > am aware of are staying away from these issues since they don't = wanna mandate/require any changes in the transport to > be > > able to run their specs in the current deployments. > > > > [Qin]: You are right, take a look at section 8.2 of = draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP = is > > not optimal for real-time interactive media application. >=20 > Right, I was just stating a fact that probably everybody agrees with. = But my concern is there is too much deployment in the > field and the currently developed approaches are all refraining from = making or requiring changes to the existing gear/stacks. >=20 > The question is whether it makes sense for any practical deployment, = provider or owner to adopt the changes that IETF may > produce. How much improvement do we need to make the new approach win? = For marginal improvements, substantial > hardware/software upgrade is not justified. >=20 > [Qin]: This seems a big question. In my understanding, >=20 > With zero change to the existing gear/stacks: > 1.Encoding live video for streaming over the Internet is extremely = complicated and demands extensive CPU power. You mean encoding? > Therefore the current implementation may encourage the content = publisher to reduce image quality, shrink the frame size, > or force the user to experience long start/seek times so that the = client-based player has time to buffer content. While these > improve the situation by reducing the volume of data sent or allowing = the player to get ahead, the viewing experience is > severely sacrificed. I am not following what your proposal here is. Live encoding and = streaming may pose additional challenges but they will naturally exist = pretty much no matter what we have. =20 > 2. The current implentation may depend on multiple bit rates encoding = to deliver the same content with different quality to > clients however the cost of Multiple Bit rate encoding is very = expensive, especially when streaming live video. What is the alternative? SVC? On-the-fly transcoding? =20 > 3. With the current implentation, client polling for playlist is okay, = client polling for real time data fragment by fragment is > not efficient way. Right, however, it won't be fragment by fragment for the updated = manifests. There are certain so-called optimizations for this concern. = For actual fragment download, it does not matter (much) whether the = content is live or not as long as the caching system works reasonably = OK. =20 > Given these above aspects, I am wondering whether the STB users or = Mobile users are acceptable to the such playback > experience when they watch program using browser, which may be far = from TV viewing experience.Doesn't this worth > improvement/optimization? It could be. But, to start a work, we need better alternatives. =20 ... > Maybe something better than TCP (like SCTP), better tailored for the = needs for streaming over http. This certainly would > benefit from more discussion. >=20 > [Qin] Sounds like a good idea. So the serious issues we may need to = look at are: >=20 > How does HTTP Streaming support real time communication? How to enable = migration of the real time application to Web? >=20 > Any thoughts? I still think real-time communication is far different from streaming = and we should not try to combine them. =20 -acbegen From sunseawq@huawei.com Tue Sep 7 21:47:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A01D3A6B2D for ; Tue, 7 Sep 2010 21:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.057 X-Spam-Level: * X-Spam-Status: No, score=1.057 tagged_above=-999 required=5 tests=[AWL=-1.648, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5DugmXCiAQl for ; Tue, 7 Sep 2010 21:47:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C5CEB3A6B2C for ; Tue, 7 Sep 2010 21:47:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8E00BI5W07X2@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 08 Sep 2010 12:48:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8E009ARW07S3@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 08 Sep 2010 12:48:07 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8E00287W060B@szxml06-in.huawei.com> for dispatch@ietf.org; Wed, 08 Sep 2010 12:48:07 +0800 (CST) Date: Wed, 08 Sep 2010 12:48:06 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , Ning Zong , Ross Finlayson , dispatch@ietf.org Message-id: <01cc01cb4f11$078b7750$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=WINDOWS-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007601cb4a3b$473c9670$5b548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D07@xmb-sjc-215.amer.cisco.com> <05a101cb4a8d$5054f3e0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D074D15@xmb-sjc-215.amer.cisco.com> <0a1801cb4b41$8826c230$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D128B25@xmb-sjc-215.amer.cisco.com> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 04:47:54 -0000 Hi, Ali: ----- Original Message ----- From: "Ali C. Begen (abegen)" To: "Qin Wu" ; "Ning Zong" ; "Ross Finlayson" ; Sent: Monday, September 06, 2010 4:40 PM Subject: RE: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, September 03, 2010 11:25 AM > To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; dispatch@ietf.org > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Qin Wu" ; "Ning Zong" ; "Ross Finlayson" ; > > Sent: Thursday, September 02, 2010 7:14 PM > Subject: RE: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Thursday, September 02, 2010 1:55 PM > > To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; dispatch@ietf.org > > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > > > Hi, > > ----- Original Message ----- > > From: "Ali C. Begen (abegen)" > > To: "Ning Zong" ; "Ross Finlayson" ; > > Sent: Thursday, September 02, 2010 4:42 PM > > Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt) > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ning Zong > > >> Sent: Thursday, September 02, 2010 4:08 AM > > >> To: 'Ross Finlayson'; dispatch@ietf.org > > >> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) > > >> > > >> Hi, Ross, > > >> Thank you for your interests in HTTP streaming work. > > >> I agree with the point about the title and scope of Pantos I-D, which > > >> actually focus on a playlist file format and the corresponding usage in live > > >> streaming. In my opinion, we could investigate more about the underlying > > >> transport mechanisms for supporting such live streaming, e.g. HTTP/TCP, > > > > > > OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other > SDOs I > > am aware of are staying away from these issues since they don't wanna mandate/require any changes in the transport to > be > > able to run their specs in the current deployments. > > > > [Qin]: You are right, take a look at section 8.2 of draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP is > > not optimal for real-time interactive media application. > > Right, I was just stating a fact that probably everybody agrees with. But my concern is there is too much deployment in the > field and the currently developed approaches are all refraining from making or requiring changes to the existing gear/stacks. > > The question is whether it makes sense for any practical deployment, provider or owner to adopt the changes that IETF may > produce. How much improvement do we need to make the new approach win? For marginal improvements, substantial > hardware/software upgrade is not justified. > > [Qin]: This seems a big question. In my understanding, > > With zero change to the existing gear/stacks: > 1.Encoding live video for streaming over the Internet is extremely complicated and demands extensive CPU power. You mean encoding? [Qin]: Yes, but I think Encoding is just one component we can make use of or resued. > Therefore the current implementation may encourage the content publisher to reduce image quality, shrink the frame size, > or force the user to experience long start/seek times so that the client-based player has time to buffer content. While these > improve the situation by reducing the volume of data sent or allowing the player to get ahead, the viewing experience is > severely sacrificed. I am not following what your proposal here is. Live encoding and streaming may pose additional challenges but they will naturally exist pretty much no matter what we have. [Qin]: Yes, we can not change encoding itself. But we may need to tune the video encoder algorithm to satisfy video quality requirements. we may need to determine which bitrate to use in a given situation and when to switch from one bitrate to another as bandwidth fluctuation. In some specific cases when the network is congested or saturated with media traffic, how to downgrade the quality of content to adapt to transport capability, network condition is one possible way to solve this problem. when the network is back to normal, we also need to consider how to upgrade the quality of content. In the current implentation, we may use playlist/manifest to do this. But it is not flexible and also may cause too much starup time latency and slow response by updating playlist. In this implentation, network and server do nothing since client controls the playlist updating. > 2. The current implentation may depend on multiple bit rates encoding to deliver the same content with different quality to > clients however the cost of Multiple Bit rate encoding is very expensive, especially when streaming live video. What is the alternative? SVC? On-the-fly transcoding? [Qin] Yes, SVC is one alternative , like what I said in the ps draft. For on-the-flying transcoding, it is another choice, but I am afraid it is expensive and demand more power from CPU. Actually in the current implentation, they may also consider how to translate between differnt streaming file format, e.g., translate from MP3 file to FLV file.becos different streaming may support different streaming file format. > 3. With the current implentation, client polling for playlist is okay, client polling for real time data fragment by fragment is > not efficient way. Right, however, it won't be fragment by fragment for the updated manifests. There are certain so-called optimizations for this concern. For actual fragment download, it does not matter (much) whether the content is live or not as long as the caching system works reasonably OK. [Qin]: Yes, manifest updating is only needed at the starup or switching. However manifest updating may cause starup latency or switching latency. This latency may be not acceptable to the users who are accustomed to TV experience. > Given these above aspects, I am wondering whether the STB users or Mobile users are acceptable to the such playback > experience when they watch program using browser, which may be far from TV viewing experience.Doesn't this worth > improvement/optimization? It could be. But, to start a work, we need better alternatives. ... > Maybe something better than TCP (like SCTP), better tailored for the needs for streaming over http. This certainly would > benefit from more discussion. > > [Qin] Sounds like a good idea. So the serious issues we may need to look at are: > > How does HTTP Streaming support real time communication? How to enable migration of the real time application to Web? > > Any thoughts? I still think real-time communication is far different from streaming and we should not try to combine them. [Qin]: Agree. we may use real time streaming instead of real time communication. -acbegen From eburger@standardstrack.com Wed Sep 8 07:34:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B8D3A6861 for ; Wed, 8 Sep 2010 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6WGlNjEKh5J for ; Wed, 8 Sep 2010 07:34:32 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.249.249]) by core3.amsl.com (Postfix) with ESMTP id 529AB3A672E for ; Wed, 8 Sep 2010 07:34:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=VG3tt6kw418wntc/9Uojfp9g3IGqzD8OaIEzUB/mzMv8dsPYmBHxCpj0CcIzg/pPFA8Ni0LRCUFzBJfT9qx2gmJjYIA6eJv9e1xHJYfo1ntkaTzjK/KiVenpMcqgWhHy; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.194]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OtLgQ-00009o-Ml; Wed, 08 Sep 2010 07:31:30 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eric Burger In-Reply-To: <4C7CD90B.3030101@ericsson.com> Date: Wed, 8 Sep 2010 10:34:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26C982A4-A2B6-4FEE-BD48-2322590C9987@standardstrack.com> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <4C7CD90B.3030101@ericsson.com> To: Camarillo Gonzalo , Kaplan Hadriel X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: dispatch list mailing Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:34:35 -0000 Part of me says, "this makes sense - let's pick one and only one." Another part of me says, "INFO is always ad hoc. Infinitely better to = get the documentation out there. Those against *allowing* Hadriel to = write an Informational document clearly have too much time on their = hands." On Aug 31, 2010, at 6:27 AM, Gonzalo Camarillo wrote: > Hi, >=20 > what we need to discuss here is what is our final goal. Adding three = new > documents (the existing Cisco way, the existing 3GPP way, and the > improved INFO-based way) describing how to carry DTMF may not be the > best way forward. Let's focus on discussing the current situation, = what > problems or issues need to be resolved, and the requirements we need = to > meet. Let's be pragmatic and produce something that will actually > improve the current situation out there. >=20 > Thanks, >=20 > Gonzalo >=20 > On 24/08/2010 6:51 PM, Paul Kyzivat wrote: >> Maybe we should ask our ADs if they have an opinion about this. >>=20 >> Thanks, >> Paul >>=20 >> Hadriel Kaplan wrote: >>>=20 >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>>=20 >>>> That reduces things somewhat. But if everybody that supports the = package >>>> also supports the legacy approach, what is the win? >>>=20 >>> The legacy mode has no published standards document defining it. I = thought when the info-packages work was started, DTMF-in-info was one of = the main drivers. But I take your point - if people would prefer to = just document it as it is today (sans info-packages), I can change the = draft to just be that. I'm cool with either way (defining the current = dtmf-relay as a legacy mode was Option-2). >>>=20 >>> -hadriel=20 >>>=20 >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Wed Sep 8 13:12:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52503A691A for ; Wed, 8 Sep 2010 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a7mvh+fEswM for ; Wed, 8 Sep 2010 13:12:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7CD7B3A67E3 for ; Wed, 8 Sep 2010 13:12:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-6d-4c87ee2ee1bc Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B0.58.10125.E2EE78C4; Wed, 8 Sep 2010 22:12:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 8 Sep 2010 22:12:30 +0200 From: Christer Holmberg To: Eric Burger , Gonzalo Camarillo , Kaplan Hadriel Date: Wed, 8 Sep 2010 22:12:29 +0200 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActPYwtHyvLLpvP5RRCb10FSf+vFNAALU0Fm Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585015BCA6B@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <4C7CD90B.3030101@ericsson.com>, <26C982A4-A2B6-4FEE-BD48-2322590C9987@standardstrack.com> In-Reply-To: <26C982A4-A2B6-4FEE-BD48-2322590C9987@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: dispatch list mailing Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 20:12:07 -0000 Hi, I see no reason why we should describe existing legacy INFO mechanisms for = DTMF - or for anything else. The reason why we produced the Info Package me= chanism was to solve the problems associated with legacy INFO, so I see no = reason why we should "encourage" legacy INFO usages by describing how they = work... Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Er= ic Burger [eburger@standardstrack.com] Sent: Wednesday, September 08, 2010 5:34 PM To: Gonzalo Camarillo; Kaplan Hadriel Cc: dispatch list mailing Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-pack= age-00.txt Part of me says, "this makes sense - let's pick one and only one." Another part of me says, "INFO is always ad hoc. Infinitely better to get t= he documentation out there. Those against *allowing* Hadriel to write an In= formational document clearly have too much time on their hands." On Aug 31, 2010, at 6:27 AM, Gonzalo Camarillo wrote: > Hi, > > what we need to discuss here is what is our final goal. Adding three new > documents (the existing Cisco way, the existing 3GPP way, and the > improved INFO-based way) describing how to carry DTMF may not be the > best way forward. Let's focus on discussing the current situation, what > problems or issues need to be resolved, and the requirements we need to > meet. Let's be pragmatic and produce something that will actually > improve the current situation out there. > > Thanks, > > Gonzalo > > On 24/08/2010 6:51 PM, Paul Kyzivat wrote: >> Maybe we should ask our ADs if they have an opinion about this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that supports the packa= ge >>>> also supports the legacy approach, what is the win? >>> >>> The legacy mode has no published standards document defining it. I tho= ught when the info-packages work was started, DTMF-in-info was one of the m= ain drivers. But I take your point - if people would prefer to just docume= nt it as it is today (sans info-packages), I can change the draft to just b= e that. I'm cool with either way (defining the current dtmf-relay as a leg= acy mode was Option-2). >>> >>> -hadriel >>> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch= From allyn@cisco.com Wed Sep 8 14:10:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2723A6A04 for ; Wed, 8 Sep 2010 14:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.551 X-Spam-Level: X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQTrtEO2Ewdd for ; Wed, 8 Sep 2010 14:10:00 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CCB643A682F for ; Wed, 8 Sep 2010 14:10:00 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEqYh0yrR7Hu/2dsb2JhbACBRJ9fcaVSmzaFPQSBWYJriFk X-IronPort-AV: E=Sophos;i="4.56,335,1280707200"; d="scan'208,217";a="183390646" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 08 Sep 2010 21:10:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o88LASax029627 for ; Wed, 8 Sep 2010 21:10:28 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Sep 2010 14:10:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4F9A.43210F17" x-cr-hashedpuzzle: AYX1 BJUw Bxfw B3lH CV0T Dfnx FWu2 GJWM GhN6 Gysb HOwG IajZ J20y KN+E Kbkr Lyfl; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {14286519-1A75-4195-8878-7AD3AE7D2573}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 08 Sep 2010 21:10:23 GMT; VABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABjAGgAYQByAHQAZQByACAAdgBlAHIAcwBpAG8AbgAgADQA x-cr-puzzleid: {14286519-1A75-4195-8878-7AD3AE7D2573} Content-class: urn:content-classes:message Date: Wed, 8 Sep 2010 14:10:23 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence charter version 4 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDw== From: "Allyn Romanow (allyn)" To: "DISPATCH list" X-OriginalArrivalTime: 08 Sep 2010 21:10:28.0191 (UTC) FILETIME=[433E5EF0:01CB4F9A] Subject: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 21:10:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4F9A.43210F17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks,=20 Here is the fourth version of the charter for work on multiple streams for Telepresence. =20 It addresses issues brought up on the mailing list. There is a list of the changes at the end of the text. =20 Comments? =20 ------ =20 =20 =20 MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - Communication and Correlation of Key Telepresence Attributes for Interoperable Links MAITAI - Multi-stream Attributes for Improving Telepresence Application Interoperability TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike Applications MOJITO - Multi-stream Orientation for Joining of Interoperable Telepresence Operations =20 =20 In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. =20 Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. =20 =20 The WG will create specifications for SIP-based conferencing systems to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience.=20 =20 This working group is chartered to specify the information about media streams from one entity to another entity: =20 * Spatial relationships of cameras, displays, microphones, and Speakers - in relation to each other and to likely positions of participants =20 * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker - so that senders and middleboxes can understand how best to compose streams for receivers, and the receivers will know the characteristics of its=20 received streams =20 *Usage of the stream, for example whether the stream is presentation, or document camera output =20 * Aspect ratio of cameras and displays =20 * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). =20 =20 Information between sources and sinks about media stream capabilities will be exchanged.=20 =20 The working group will define the semantics, syntax, and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended, or another messaging method should be used. =20 =20 The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 =20 The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. =20 Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. =20 This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster.=20 =20 Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. =20 Milestones =20 =20 Nov 2010 Submit information draft to IESG on use cases and requirements =20 Nov 2011 Submit standards track specification to IESG indicating spatial relationships=20 of screens cameras (including variable field of view and orientation), speakers and microphones; and the "usage" of a stream as defined in the charter. Semantics, language and transport mechanism will be specified. =20 =20 =20 List of changes V3 to V4 =20 The WG will create specifications for SIP-based conferencing systems to enable communication.. [instead of The WG will create specifications to enable communication...] =20 This working group is chartered to specify the information about media streams from one entity to another entity=20 [instead of This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including:] =20 =20 [added] *Usage of the stream, for example whether the stream is presentation, or document camera output =20 Interoperation with SIP and related standards for audio and video is required. =20 [instead of Interoperation with standards compliant systems is required, such as SIP-based conferencing systems.] =20 Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. [instead of Reuse of existing protocols backwards compatibility with existing systems is an important factor for the working group to consider.] =20 Milestones Nov 2011 Submit standards track specification to IESG indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones; and the "usage" of a stream as defined in the charter e Semantics, language and transport will be specified. =20 [Instead of=20 Nov 2011 Submit standards track specification to IESG indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes semantics, language and transport. =20 Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. =20 =20 ------_=_NextPart_001_01CB4F9A.43210F17 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

Here is the fourth version of the charter for work = on multiple streams for Telepresence.

 

It addresses issues brought up on the mailing list. = There is a list of the changes at the end of the text.

 

Comments?

 

------

 

 

 

MALT – Multi-stream Attributes for Lifelike Telepresence

COCKTAIL – Communication and Correlation of = Key Telepresence Attributes for Interoperable Links

MAITAI – Multi-stream Attributes for = Improving Telepresence Application Interoperability

TEQUILA – Telepresence Encoding of QUalifiers = for Interoperable Lifelike Applications

MOJITO – Multi-stream Orientation for Joining = of Interoperable Telepresence Operations

 

 

In the context of this WG, the term telepresence is = used in a general manner to describe systems that provide high definition, high = quality audio/video enabling a "being-there" experience.  One = example is an immersive telepresence system using specially designed and special = purpose rooms with multiple displays permitting life size image reproduction = using multiple cameras, encoders, decoders, microphones and = loudspeakers.

 

Current telepresence systems are based on open = standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A = major factor in the inability of telepresence systems to interwork is that = there is no standardized way to describe and negotiate the use of the multiple = streams of audio and video that comprise the media flows. In addition, =  there is no standardized way to exchange semantic information about = what each media stream represents.  

 

The WG will create specifications for SIP-based = conferencing systems to enable communication of enough information about each media = stream so that each receiving system or bridge system can make reasonable = decisions about selecting and rendering media streams. This enables systems to = make display choices that optimize the "just like being there" experience. 

 

This working group is chartered to specify the = information about media streams from one entity to another entity:

 

* Spatial relationships of cameras, displays, = microphones, and

  Speakers – in relation to each = other and to likely positions of

  participants

 

* Specific characteristics such as viewpoint, field = of view/capture

  for camera/microphone/display/speaker = – so that senders and             =   

  middleboxes can understand how best to = compose streams for

  receivers, and the receivers will know = the characteristics of its 

  received streams

 

*Usage of the stream, for example whether the = stream is presentation, or document camera output

 

* Aspect ratio of cameras and = displays

 

* Which sources a receiver wants to receive.  For example, it might want = the source for the left camera, or might want the source chosen by VAD = (Voice Activity Detection).

 

 

Information between sources and sinks about media = stream capabilities will be exchanged. 

 

The working group will define the semantics, = syntax,  and transport mechanism necessary for communicating the necessary = information. It will consider whether the existing signaling mechanisms (e. g., SDP, = BFCP) can be extended, or another messaging method should be used. =  

 

The scope of the work includes describing = relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and = video streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics. =  

 

The focus of this work is on multiple audio and = video streams.  Other media types may be considered, however development = of methodologies for them is not within the scope of this = work.

 

Interoperation with SIP and related standards for = audio and video is required.  However, backwards compatibility with existing non-standards compliant telepresence systems is not = required.

 

This working group is not currently chartered to = work on issues of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster.

 

Reuse of existing protocols and backwards = compatibility with SIP-compliant audio/video endpoints  are important factors for the = working group to consider. The work will closely coordinate with the appropriate = areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.

 

 Milestones  

 

 Nov 2010 Submit information draft to IESG on = use cases and requirements

 

Nov 2011 Submit standards track specification to = IESG  indicating spatial relationships

of  = screens  cameras (including variable field of view and orientation), speakers and = microphones; and the “usage” of a stream as defined in the charter.  Semantics, language and transport mechanism will be = specified.

 

 

 

List of changes V3 to V4

 

The WG will create specifications for SIP-based conferencing systems to enable = communication..

[instead of The WG will create specifications to = enable communication…]

 

This working group is chartered to specify the = information about media streams from one entity to = another entity

[instead of  This working group is chartered = to specify the information about media streams from one endpoint to another = endpoint or conference bridge including:]

 

 

[added] *Usage of the stream, for example whether the stream is presentation, or = document camera output

 

Interoperation with SIP and related standards for = audio and video is required.  

[instead of Interoperation with standards compliant = systems is required, such as SIP-based conferencing systems.]

 

Reuse of existing protocols and backwards = compatibility with SIP-compliant audio/video endpoints  are important factors for the = working group to consider.

[instead of Reuse of existing protocols backwards compatibility with existing systems is  an important  factor = for the working group to consider.]

 

Milestones

Nov 2011 Submit standards track specification to = IESG  indicating spatial relationships of screens, cameras (including = variable

field of view and = orientation), speakers and microphones; and the “usage” of a stream as = defined in the charter e Semantics, language and transport will be = specified.

 

[Instead of

Nov 2011 Submit standards track specification to = IESG  indicating spatial relationships of screens, cameras (including = variable

field of view and = orientation), speakers and microphones. This includes semantics, language and = transport.

 

Apr 2011 Submit standards track specification to = IESG on indicating the  "usage" of a stream as define in = charter.

 

 

------_=_NextPart_001_01CB4F9A.43210F17-- From jmpolk@cisco.com Wed Sep 8 14:31:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395AC3A6975 for ; Wed, 8 Sep 2010 14:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.382 X-Spam-Level: X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlrXwcQ+BjmB for ; Wed, 8 Sep 2010 14:30:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 924253A696A for ; Wed, 8 Sep 2010 14:30:56 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,335,1280707200"; d="scan'208";a="585713502" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2010 21:31:24 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o88LVOIA027207; Wed, 8 Sep 2010 21:31:24 GMT Message-Id: <201009082131.o88LVOIA027207@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Sep 2010 16:31:23 -0500 To: "Allyn Romanow (allyn)" , "DISPATCH list" From: "James M. Polk" In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer. cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 21:31:02 -0000 At 04:10 PM 9/8/2010, Allyn Romanow (allyn) wrote: >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01CB4F9A.43210F17" >Content-class: urn:content-classes:message > >Folks, >Here is the fourth version of the charter for=20 >work on multiple streams for Telepresence. > >It addresses issues brought up on the mailing=20 >list. There is a list of the changes at the end of the text. > >Comments? a couple in-line below james > >------ > > > >MALT =96 Multi-stream Attributes for Lifelike Telepresence >COCKTAIL =96 Communication and Correlation of Key=20 >Telepresence Attributes for Interoperable Links >MAITAI =96 Multi-stream Attributes for Improving=20 >Telepresence Application Interoperability >TEQUILA =96 Telepresence Encoding of QUalifiers=20 >for Interoperable Lifelike Applications >MOJITO =96 Multi-stream Orientation for Joining of=20 >Interoperable Telepresence Operations > > >In the context of this WG, the term telepresence=20 >is used in a general manner to describe systems=20 >that provide high definition, high quality=20 >audio/video enabling a "being-there"=20 >experience. One example is an immersive=20 >telepresence system using specially designed and=20 >special purpose rooms with multiple displays=20 >permitting life size image reproduction using=20 >multiple cameras, encoders, decoders, microphones and loudspeakers. > >Current telepresence systems are based on open=20 >standards such as RTP, SIP, H.264, the H.323=20 >suite, however, they cannot easily interoperate=20 >with each other without operator assistance and=20 >expensive additional equipment which translates from one vendor to another. The use of the word "they" in above sentence can=20 be mistaken to mean either TP systems or the open standards listed. I suggest s/they/these systems to make it clearer which you are referring to. >A major factor in the inability of telepresence=20 >systems to interwork is that there is no=20 >standardized way to describe and negotiate the=20 >use of the multiple streams of audio and video that comprise the media= flows. Is this text true if the TP systems have only 2 endpoints in the session? I agree this becomes tricky when you get to 3 or=20 more endpoints - but that isn't clear in the above text. >In addition, there is no standardized way to=20 >exchange semantic information about what each media stream represents. > >The WG will create specifications for SIP-based=20 >conferencing systems to enable communication of=20 >enough information about each media stream so=20 >that each receiving system or bridge system can=20 >make reasonable decisions about selecting and=20 >rendering media streams. This enables systems to=20 >make display choices that optimize the "just like being there" experience. > >This working group is chartered to specify the=20 >information about media streams from one entity to another entity: > >* Spatial relationships of cameras, displays, microphones, and > Speakers =96 in relation to each other and to likely positions of > participants > >* Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker =96 so that senders and > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its > received streams > >*Usage of the stream, for example whether the=20 >stream is presentation, or document camera output > >* Aspect ratio of cameras and displays > >* Which sources a receiver wants to=20 >receive. For example, it might want the source=20 >for the left camera, or might want the source=20 >chosen by VAD (Voice Activity Detection). > > >Information between sources and sinks about=20 >media stream capabilities will be exchanged. > >The working group will define the semantics,=20 >syntax, and transport mechanism necessary for=20 >communicating the necessary information. It will=20 >consider whether the existing signaling=20 >mechanisms (e. g., SDP, BFCP) can be extended,=20 >or another messaging method should be used. > >The scope of the work includes describing=20 >relatively static relations between entities=20 >(participants and devices). It also includes=20 >handling more dynamic relationships, such as=20 >identifying the audio and video streams for the=20 >current speaker. The scope includes both systems=20 >that provide a fully immersive experience, and=20 >systems that interwork with them and therefore=20 >need to understand the same multiple stream semantics. > >The focus of this work is on multiple audio and=20 >video streams. Other media types may be=20 >considered, however development of methodologies=20 >for them is not within the scope of this work. > >Interoperation with SIP and related standards=20 >for audio and video is required. However,=20 >backwards compatibility with existing=20 >non-standards compliant telepresence systems is not required. > >This working group is not currently chartered to=20 >work on issues of continuous conference control=20 >including: far end camera control, indication of=20 >fast frame update for video codecs or other=20 >rapid switches, floor control, conference roster. > >Reuse of existing protocols and backwards=20 >compatibility with SIP-compliant audio/video=20 >endpoints are important factors for the working=20 >group to consider. The work will closely=20 >coordinate with the appropriate areas and=20 >working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and= SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > >Nov 2011 Submit standards track specification to=20 >IESG indicating spatial relationships >of screens cameras (including variable field=20 >of view and orientation), speakers and=20 >microphones; and the =93usage=94 of a stream as=20 >defined in the charter. Semantics, language and=20 >transport mechanism will be specified. > > > >List of changes V3 to V4 > >The WG will create specifications for SIP-based=20 >conferencing systems to enable communication.. >[instead of The WG will create specifications to enable communication=85] > >This working group is chartered to specify the=20 >information about media streams from one entity to another entity >[instead of This working group is chartered to=20 >specify the information about media streams from=20 >one endpoint to another endpoint or conference bridge including:] > > >[added] *Usage of the stream, for example=20 >whether the stream is presentation, or document camera output > >Interoperation with SIP and related standards=20 >for audio and video is required. >[instead of Interoperation with standards=20 >compliant systems is required, such as SIP-based conferencing systems.] > >Reuse of existing protocols and backwards=20 >compatibility with SIP-compliant audio/video=20 >endpoints are important factors for the working group to consider. >[instead of Reuse of existing protocols=20 >backwards compatibility with existing systems=20 >is an important factor for the working group to consider.] > >Milestones >Nov 2011 Submit standards track specification to=20 >IESG indicating spatial relationships of screens, cameras (including= variable >field of view and orientation), speakers and=20 >microphones; and the =93usage=94 of a stream as=20 >defined in the charter e Semantics, language and transport will be= specified. > >[Instead of >Nov 2011 Submit standards track specification to=20 >IESG indicating spatial relationships of screens, cameras (including= variable >field of view and orientation), speakers and=20 >microphones. This includes semantics, language and transport. > >Apr 2011 Submit standards track specification to=20 >IESG on indicating the "usage" of a stream as define in charter. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From stephen.botzko@gmail.com Wed Sep 8 15:01:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0213A67E9 for ; Wed, 8 Sep 2010 15:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sMCTxJCDCb6 for ; Wed, 8 Sep 2010 15:01:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 69D293A6952 for ; Wed, 8 Sep 2010 15:01:54 -0700 (PDT) Received: by ywk9 with SMTP id 9so391219ywk.31 for ; Wed, 08 Sep 2010 15:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NFPNboakoe32JqzuAQkE3tmt4w1n6NhU/G63+mlZqrI=; b=ElcvQ+cG1VV1/JwQnwgYqR36JphkYtO6lRQnCiaHhUv2r/ilG/MDcWKdv9ytcr4cR5 vmcSPJYfGOXCxVwdpNzmie8sMLNpLM02dE31huvzLmFDarwvZNYkqWjzmOk7YPqCsrQZ 1q9ksRmytDs7segHx4YfZPyHrJrTwJR2Xv5OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q9QMmeKwob8miwgWCtsQNht3s2UoS6c60gHpwgC4NyK4qCjmYRdR5PMFf3R77FpQab 4XDxcBvEb/hYrys6BCwmWFVgAOezQ7Pgu551loQem52yk1VkTa76AR8Q0BsgLwcT2p7q 4VaE0GPmmhWdTPQaMA92B8OdSLQpBDOfdhSjY= MIME-Version: 1.0 Received: by 10.229.237.199 with SMTP id kp7mr535600qcb.8.1283983341620; Wed, 08 Sep 2010 15:02:21 -0700 (PDT) Received: by 10.229.241.134 with HTTP; Wed, 8 Sep 2010 15:02:21 -0700 (PDT) In-Reply-To: <201009082131.o88LVOIA027207@sj-core-3.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <201009082131.o88LVOIA027207@sj-core-3.cisco.com> Date: Wed, 8 Sep 2010 18:02:21 -0400 Message-ID: From: stephen botzko To: "James M. Polk" Content-Type: multipart/alternative; boundary=0016e64b02d8f990f2048fc6aadf Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:01:56 -0000 --0016e64b02d8f990f2048fc6aadf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> Is this text true if the TP systems have only 2 endpoints in the session? I agree this becomes tricky when you get to 3 or more endpoints - but that isn't clear in the above text. >>> It is absolutely true with 2 endpoints in a call. There is no standard way for the endpoints to know how to map the incoming audio/video streams to their displays and speakers. Stephen Botzko On Wed, Sep 8, 2010 at 5:31 PM, James M. Polk wrote: > At 04:10 PM 9/8/2010, Allyn Romanow (allyn) wrote: > >> Content-Type: multipart/alternative; >> boundary=3D"----_=3D_NextPart_001_01CB4F9A.43210F17" >> Content-class: urn:content-classes:message >> >> >> Folks, >> Here is the fourth version of the charter for work on multiple streams f= or >> Telepresence. >> >> It addresses issues brought up on the mailing list. There is a list of t= he >> changes at the end of the text. >> >> Comments? >> > > a couple in-line below > > james > > > >> ------ >> >> >> >> MALT =96 Multi-stream Attributes for Lifelike Telepresence >> COCKTAIL =96 Communication and Correlation of Key Telepresence Attribute= s >> for Interoperable Links >> MAITAI =96 Multi-stream Attributes for Improving Telepresence Applicatio= n >> Interoperability >> TEQUILA =96 Telepresence Encoding of QUalifiers for Interoperable Lifeli= ke >> Applications >> MOJITO =96 Multi-stream Orientation for Joining of Interoperable >> Telepresence Operations >> >> >> In the context of this WG, the term telepresence is used in a general >> manner to describe systems that provide high definition, high quality >> audio/video enabling a "being-there" experience. One example is an >> immersive telepresence system using specially designed and special purpo= se >> rooms with multiple displays permitting life size image reproduction usi= ng >> multiple cameras, encoders, decoders, microphones and loudspeakers. >> >> Current telepresence systems are based on open standards such as RTP, SI= P, >> H.264, the H.323 suite, however, they cannot easily interoperate with ea= ch >> other without operator assistance and expensive additional equipment whi= ch >> translates from one vendor to another. >> > > The use of the word "they" in above sentence can be mistaken to mean eith= er > TP systems or the open standards listed. > > I suggest > > s/they/these systems > > to make it clearer which you are referring to. > > > A major factor in the inability of telepresence systems to interwork is >> that there is no standardized way to describe and negotiate the use of t= he >> multiple streams of audio and video that comprise the media flows. >> > > Is this text true if the TP systems have only 2 endpoints in the session? > > I agree this becomes tricky when you get to 3 or more endpoints - but tha= t > isn't clear in the above text. > > In addition, there is no standardized way to exchange semantic >> information about what each media stream represents. >> >> The WG will create specifications for SIP-based conferencing systems to >> enable communication of enough information about each media stream so th= at >> each receiving system or bridge system can make reasonable decisions abo= ut >> selecting and rendering media streams. This enables systems to make disp= lay >> choices that optimize the "just like being there" experience. >> >> This working group is chartered to specify the information about media >> streams from one entity to another entity: >> >> * Spatial relationships of cameras, displays, microphones, and >> Speakers =96 in relation to each other and to likely positions of >> participants >> >> * Specific characteristics such as viewpoint, field of view/capture >> for camera/microphone/display/speaker =96 so that senders and >> middleboxes can understand how best to compose streams for >> receivers, and the receivers will know the characteristics of its >> received streams >> >> *Usage of the stream, for example whether the stream is presentation, or >> document camera output >> >> * Aspect ratio of cameras and displays >> >> * Which sources a receiver wants to receive. For example, it might want >> the source for the left camera, or might want the source chosen by VAD >> (Voice Activity Detection). >> >> >> Information between sources and sinks about media stream capabilities wi= ll >> be exchanged. >> >> The working group will define the semantics, syntax, and transport >> mechanism necessary for communicating the necessary information. It will >> consider whether the existing signaling mechanisms (e. g., SDP, BFCP) ca= n be >> extended, or another messaging method should be used. >> >> The scope of the work includes describing relatively static relations >> between entities (participants and devices). It also includes handling m= ore >> dynamic relationships, such as identifying the audio and video streams f= or >> the current speaker. The scope includes both systems that provide a full= y >> immersive experience, and systems that interwork with them and therefore >> need to understand the same multiple stream semantics. >> >> The focus of this work is on multiple audio and video streams. Other >> media types may be considered, however development of methodologies for = them >> is not within the scope of this work. >> >> Interoperation with SIP and related standards for audio and video is >> required. However, backwards compatibility with existing non-standards >> compliant telepresence systems is not required. >> >> This working group is not currently chartered to work on issues of >> continuous conference control including: far end camera control, indicat= ion >> of fast frame update for video codecs or other rapid switches, floor >> control, conference roster. >> >> Reuse of existing protocols and backwards compatibility with SIP-complia= nt >> audio/video endpoints are important factors for the working group to >> consider. The work will closely coordinate with the appropriate areas an= d >> working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and >> SIPCORE. >> >> Milestones >> >> Nov 2010 Submit information draft to IESG on use cases and requirements >> >> Nov 2011 Submit standards track specification to IESG indicating spatia= l >> relationships >> of screens cameras (including variable field of view and orientation), >> speakers and microphones; and the =93usage=94 of a stream as defined in = the >> charter. Semantics, language and transport mechanism will be specified. >> >> >> >> List of changes V3 to V4 >> >> The WG will create specifications for SIP-based conferencing systems to >> enable communication.. >> [instead of The WG will create specifications to enable communication=85= ] >> >> This working group is chartered to specify the information about media >> streams from one entity to another entity >> [instead of This working group is chartered to specify the information >> about media streams from one endpoint to another endpoint or conference >> bridge including:] >> >> >> [added] *Usage of the stream, for example whether the stream is >> presentation, or document camera output >> >> Interoperation with SIP and related standards for audio and video is >> required. >> [instead of Interoperation with standards compliant systems is required, >> such as SIP-based conferencing systems.] >> >> Reuse of existing protocols and backwards compatibility with SIP-complia= nt >> audio/video endpoints are important factors for the working group to >> consider. >> [instead of Reuse of existing protocols backwards compatibility with >> existing systems is an important factor for the working group to >> consider.] >> >> Milestones >> Nov 2011 Submit standards track specification to IESG indicating spatia= l >> relationships of screens, cameras (including variable >> field of view and orientation), speakers and microphones; and the =93usa= ge=94 >> of a stream as defined in the charter e Semantics, language and transpor= t >> will be specified. >> >> [Instead of >> Nov 2011 Submit standards track specification to IESG indicating spatia= l >> relationships of screens, cameras (including variable >> field of view and orientation), speakers and microphones. This includes >> semantics, language and transport. >> >> Apr 2011 Submit standards track specification to IESG on indicating the >> "usage" of a stream as define in charter. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0016e64b02d8f990f2048fc6aadf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>

Is this text true if the TP systems have only 2 endpoints in the session?
I agree this becomes tricky when you get to 3 or more endpoints - but that = isn't clear in the above text.
>>>

It is absolutely = true with 2 endpoints in a call.=A0 There is no standard way for the endpoi= nts to know how to map the incoming audio/video streams to their displays a= nd speakers.

Stephen Botzko

On Wed, Sep 8, 2010 at= 5:31 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 04:10 PM 9/8/2010, Allyn Romanow (allyn) wrote:
Content-Type: multipart/alternative;
=A0 =A0 =A0 =A0boundary=3D"----_=3D_NextPart_001_01CB4F9A.43210F17&qu= ot;
Content-class: urn:content-classes:message


Folks,
Here is the fourth version of the charter for work on multiple streams for = Telepresence.

It addresses issues brought up on the mailing list. There is a list of the = changes at the end of the text.

Comments?

a couple in-line below

james



------



MALT =96 Multi-stream Attributes for Lifelike Telepresence
COCKTAIL =96 Communication and Correlation of Key Telepresence Attributes f= or Interoperable Links
MAITAI =96 Multi-stream Attributes for Improving Telepresence Application I= nteroperability
TEQUILA =96 Telepresence Encoding of QUalifiers for Interoperable Lifelike = Applications
MOJITO =96 Multi-stream Orientation for Joining of Interoperable Telepresen= ce Operations


In the context of this WG, the term telepresence is used in a general manne= r to describe systems that provide high definition, high quality audio/vide= o enabling a "being-there" experience. =A0One example is an immer= sive telepresence system using specially designed and special purpose rooms= with multiple displays permitting life size image reproduction using multi= ple cameras, encoders, decoders, microphones and loudspeakers.

Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another.

The use of the word "they" in above sentence can be mistaken to m= ean either TP systems or the open standards listed.

I suggest

=A0 =A0 =A0 =A0s/they/these systems

to make it clearer which you are referring to.


A major factor in the inability of telepresence systems to interwork is tha= t there is no standardized way to describe and negotiate the use of the mul= tiple streams of audio and video that comprise the media flows.

Is this text true if the TP systems have only 2 endpoints in the session?
I agree this becomes tricky when you get to 3 or more endpoints - but that = isn't clear in the above text.

<= div class=3D"h5"> In addition, =A0there is no standardized way to exchange semantic informati= on about what each media stream represents.

The WG will create specifications for SIP-based conferencing systems to ena= ble communication of enough information about each media stream so that eac= h receiving system or bridge system can make reasonable decisions about sel= ecting and rendering media streams. This enables systems to make display ch= oices that optimize the "just like being there" experience.

This working group is chartered to specify the information about media stre= ams from one entity to another entity:

* Spatial relationships of cameras, displays, microphones, and
=A0Speakers =96 in relation to each other and to likely positions of
=A0participants

* Specific characteristics such as viewpoint, field of view/capture
=A0for camera/microphone/display/speaker =96 so that senders and
=A0middleboxes can understand how best to compose streams for
=A0receivers, and the receivers will know the characteristics of its
=A0received streams

*Usage of the stream, for example whether the stream is presentation, or do= cument camera output

* Aspect ratio of cameras and displays

* Which sources a receiver wants to receive. =A0For example, it might want = the source for the left camera, or might want the source chosen by VAD (Voi= ce Activity Detection).


Information between sources and sinks about media stream capabilities will = be exchanged.

The working group will define the semantics, syntax, =A0and transport mecha= nism necessary for communicating the necessary information. It will conside= r whether the existing signaling mechanisms (e. g., SDP, BFCP) can be exten= ded, or another messaging method should be used.

The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics.

The focus of this work is on multiple audio and video streams. =A0Other med= ia types may be considered, however development of methodologies for them i= s not within the scope of this work.

Interoperation with SIP and related standards for audio and video is requir= ed. =A0However, backwards compatibility with existing non-standards complia= nt telepresence systems is not required.

This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster.

Reuse of existing protocols and backwards compatibility with SIP-compliant = audio/video endpoints =A0are important factors for the working group to con= sider. The work will closely coordinate with the appropriate areas and work= ing groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.
=A0Milestones

=A0Nov 2010 Submit information draft to IESG on use cases and requirements<= br>
Nov 2011 Submit standards track specification to IESG =A0indicating spatial= relationships
of =A0screens =A0cameras (including variable field of view and orientation)= , speakers and microphones; and the =93usage=94 of a stream as defined in t= he charter. =A0Semantics, language and transport mechanism will be specifie= d.



List of changes V3 to V4

The WG will create specifications for SIP-based conferencing systems to ena= ble communication..
[instead of The WG will create specifications to enable communication=85]
This working group is chartered to specify the information about media stre= ams from one entity to another entity
[instead of =A0This working group is chartered to specify the information a= bout media streams from one endpoint to another endpoint or conference brid= ge including:]


[added] *Usage of the stream, for example whether the stream is presentatio= n, or document camera output

Interoperation with SIP and related standards for audio and video is requir= ed.
[instead of Interoperation with standards compliant systems is required, su= ch as SIP-based conferencing systems.]

Reuse of existing protocols and backwards compatibility with SIP-compliant = audio/video endpoints =A0are important factors for the working group to con= sider.
[instead of Reuse of existing protocols backwards compatibility with existi= ng systems is =A0an important =A0factor for the working group to consider.]=

Milestones
Nov 2011 Submit standards track specification to IESG =A0indicating spatial= relationships of screens, cameras (including variable
field of view and orientation), speakers and microphones; and the =93usage= =94 of a stream as defined in the charter e Semantics, language and transpo= rt will be specified.

[Instead of
Nov 2011 Submit standards track specification to IESG =A0indicating spatial= relationships of screens, cameras (including variable
field of view and orientation), speakers and microphones. This includes sem= antics, language and transport.

Apr 2011 Submit standards track specification to IESG on indicating the =A0= "usage" of a stream as define in charter.


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

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

--0016e64b02d8f990f2048fc6aadf-- From jmpolk@cisco.com Wed Sep 8 16:38:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294343A69EC for ; Wed, 8 Sep 2010 16:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.502 X-Spam-Level: X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWZ0s5XaVj7e for ; Wed, 8 Sep 2010 16:38:04 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 27CE03A6A1C for ; Wed, 8 Sep 2010 16:38:04 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,336,1280707200"; d="scan'208";a="252174436" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2010 23:38:31 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o88NcU8o007604; Wed, 8 Sep 2010 23:38:30 GMT Message-Id: <201009082338.o88NcU8o007604@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Sep 2010 18:38:29 -0500 To: stephen botzko , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <201009082131.o88LVOIA027207@sj-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 23:38:08 -0000 At 05:02 PM 9/8/2010, stephen botzko wrote: > >>> > >Is this text true if the TP systems have only 2 endpoints in the session? > >I agree this becomes tricky when you get to 3 or=20 >more endpoints - but that isn't clear in the above text. > >>> > >It is absolutely true with 2 endpoints in a=20 >call. There is no standard way for the=20 >endpoints to know how to map the incoming=20 >audio/video streams to their displays and speakers. ok ok - I wasn't thinking (about 3-screen to=20 3-screen) when I wrote this comment... sorry james >Stephen Botzko > >On Wed, Sep 8, 2010 at 5:31 PM, James M. Polk=20 ><jmpolk@cisco.com> wrote: >At 04:10 PM 9/8/2010, Allyn Romanow (allyn) wrote: >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01CB4F9A.43210F17" >Content-class: urn:content-classes:message > > >Folks, >Here is the fourth version of the charter for=20 >work on multiple streams for Telepresence. > >It addresses issues brought up on the mailing=20 >list. There is a list of the changes at the end of the text. > >Comments? > > >a couple in-line below > >james > > > >------ > > > >MALT =96 Multi-stream Attributes for Lifelike Telepresence >COCKTAIL =96 Communication and Correlation of Key=20 >Telepresence Attributes for Interoperable Links >MAITAI =96 Multi-stream Attributes for Improving=20 >Telepresence Application Interoperability >TEQUILA =96 Telepresence Encoding of QUalifiers=20 >for Interoperable Lifelike Applications >MOJITO =96 Multi-stream Orientation for Joining of=20 >Interoperable Telepresence Operations > > >In the context of this WG, the term telepresence=20 >is used in a general manner to describe systems=20 >that provide high definition, high quality=20 >audio/video enabling a "being-there"=20 >experience. One example is an immersive=20 >telepresence system using specially designed and=20 >special purpose rooms with multiple displays=20 >permitting life size image reproduction using=20 >multiple cameras, encoders, decoders, microphones and loudspeakers. > >Current telepresence systems are based on open=20 >standards such as RTP, SIP, H.264, the H.323=20 >suite, however, they cannot easily interoperate=20 >with each other without operator assistance and=20 >expensive additional equipment which translates from one vendor to another. > > >The use of the word "they" in above sentence can=20 >be mistaken to mean either TP systems or the open standards listed. > >I suggest > > s/they/these systems > >to make it clearer which you are referring to. > > >A major factor in the inability of telepresence=20 >systems to interwork is that there is no=20 >standardized way to describe and negotiate the=20 >use of the multiple streams of audio and video that comprise the media= flows. > > >Is this text true if the TP systems have only 2 endpoints in the session? > >I agree this becomes tricky when you get to 3 or=20 >more endpoints - but that isn't clear in the above text. > >In addition, there is no standardized way to=20 >exchange semantic information about what each media stream represents. > >The WG will create specifications for SIP-based=20 >conferencing systems to enable communication of=20 >enough information about each media stream so=20 >that each receiving system or bridge system can=20 >make reasonable decisions about selecting and=20 >rendering media streams. This enables systems to=20 >make display choices that optimize the "just like being there" experience. > >This working group is chartered to specify the=20 >information about media streams from one entity to another entity: > >* Spatial relationships of cameras, displays, microphones, and > Speakers =96 in relation to each other and to likely positions of > participants > >* Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker =96 so that senders and > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its > received streams > >*Usage of the stream, for example whether the=20 >stream is presentation, or document camera output > >* Aspect ratio of cameras and displays > >* Which sources a receiver wants to=20 >receive. For example, it might want the source=20 >for the left camera, or might want the source=20 >chosen by VAD (Voice Activity Detection). > > >Information between sources and sinks about=20 >media stream capabilities will be exchanged. > >The working group will define the semantics,=20 >syntax, and transport mechanism necessary for=20 >communicating the necessary information. It will=20 >consider whether the existing signaling=20 >mechanisms (e. g., SDP, BFCP) can be extended,=20 >or another messaging method should be used. > >The scope of the work includes describing=20 >relatively static relations between entities=20 >(participants and devices). It also includes=20 >handling more dynamic relationships, such as=20 >identifying the audio and video streams for the=20 >current speaker. The scope includes both systems=20 >that provide a fully immersive experience, and=20 >systems that interwork with them and therefore=20 >need to understand the same multiple stream semantics. > >The focus of this work is on multiple audio and=20 >video streams. Other media types may be=20 >considered, however development of methodologies=20 >for them is not within the scope of this work. > >Interoperation with SIP and related standards=20 >for audio and video is required. However,=20 >backwards compatibility with existing=20 >non-standards compliant telepresence systems is not required. > >This working group is not currently chartered to=20 >work on issues of continuous conference control=20 >including: far end camera control, indication of=20 >fast frame update for video codecs or other=20 >rapid switches, floor control, conference roster. > >Reuse of existing protocols and backwards=20 >compatibility with SIP-compliant audio/video=20 >endpoints are important factors for the working=20 >group to consider. The work will closely=20 >coordinate with the appropriate areas and=20 >working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and= SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > >Nov 2011 Submit standards track specification to=20 >IESG indicating spatial relationships >of screens cameras (including variable field=20 >of view and orientation), speakers and=20 >microphones; and the =93usage=94 of a stream as=20 >defined in the charter. Semantics, language and=20 >transport mechanism will be specified. > > > >List of changes V3 to V4 > >The WG will create specifications for SIP-based=20 >conferencing systems to enable communication.. >[instead of The WG will create specifications to enable communication=85] > >This working group is chartered to specify the=20 >information about media streams from one entity to another entity >[instead of This working group is chartered to=20 >specify the information about media streams from=20 >one endpoint to another endpoint or conference bridge including:] > > >[added] *Usage of the stream, for example=20 >whether the stream is presentation, or document camera output > >Interoperation with SIP and related standards for audio and video is= required. >[instead of Interoperation with standards=20 >compliant systems is required, such as SIP-based conferencing systems.] > >Reuse of existing protocols and backwards=20 >compatibility with SIP-compliant audio/video=20 >endpoints are important factors for the working group to consider. >[instead of Reuse of existing protocols=20 >backwards compatibility with existing systems=20 >is an important factor for the working group to consider.] > >Milestones >Nov 2011 Submit standards track specification to=20 >IESG indicating spatial relationships of screens, cameras (including= variable >field of view and orientation), speakers and=20 >microphones; and the =93usage=94 of a stream as=20 >defined in the charter e Semantics, language and transport will be= specified. > >[Instead of >Nov 2011 Submit standards track specification to=20 >IESG indicating spatial relationships of screens, cameras (including= variable >field of view and orientation), speakers and=20 >microphones. This includes semantics, language and transport. > >Apr 2011 Submit standards track specification to=20 >IESG on indicating the "usage" of a stream as define in charter. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > From tme@americafree.tv Wed Sep 8 19:54:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DDE3A689B for ; Wed, 8 Sep 2010 19:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3z5l1yyYQsU for ; Wed, 8 Sep 2010 19:54:38 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 33A133A687B for ; Wed, 8 Sep 2010 19:54:38 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 70D738C36E7C; Wed, 8 Sep 2010 22:55:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Marshall Eubanks In-Reply-To: <201009082338.o88NcU8o007604@sj-core-1.cisco.com> Date: Wed, 8 Sep 2010 22:55:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50CDC4E4-579D-4A4E-93AD-FF43C1A6DC0E@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <201009082131.o88LVOIA027207@sj-core-3.cisco.com> <201009082338.o88NcU8o007604@sj-core-1.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 02:54:41 -0000 On Sep 8, 2010, at 7:38 PM, James M. Polk wrote: > At 05:02 PM 9/8/2010, stephen botzko wrote: >> >>> >>=20 >> Is this text true if the TP systems have only 2 endpoints in the = session? >>=20 >> I agree this becomes tricky when you get to 3 or more endpoints - but = that isn't clear in the above text. >> >>> >>=20 >> It is absolutely true with 2 endpoints in a call. There is no = standard way for the endpoints to know how to map the incoming = audio/video streams to their displays and speakers. >=20 > ok ok - I wasn't thinking (about 3-screen to 3-screen) when I wrote = this comment... sorry >=20 Much less 3 screen to 4 screen, or 2 screen to 3 screen. Marshall > james >=20 >=20 >> Stephen Botzko >>=20 >> On Wed, Sep 8, 2010 at 5:31 PM, James M. Polk = <jmpolk@cisco.com> wrote: >> At 04:10 PM 9/8/2010, Allyn Romanow (allyn) wrote: >> Content-Type: multipart/alternative; >> boundary=3D"----_=3D_NextPart_001_01CB4F9A.43210F17" >> Content-class: urn:content-classes:message >>=20 >>=20 >> Folks, >> Here is the fourth version of the charter for work on multiple = streams for Telepresence. >>=20 >> It addresses issues brought up on the mailing list. There is a list = of the changes at the end of the text. >>=20 >> Comments? >>=20 >>=20 >> a couple in-line below >>=20 >> james >>=20 >>=20 >>=20 >> ------ >>=20 >>=20 >>=20 >> MALT =96 Multi-stream Attributes for Lifelike Telepresence >> COCKTAIL =96 Communication and Correlation of Key Telepresence = Attributes for Interoperable Links >> MAITAI =96 Multi-stream Attributes for Improving Telepresence = Application Interoperability >> TEQUILA =96 Telepresence Encoding of QUalifiers for Interoperable = Lifelike Applications >> MOJITO =96 Multi-stream Orientation for Joining of Interoperable = Telepresence Operations >>=20 >>=20 >> In the context of this WG, the term telepresence is used in a general = manner to describe systems that provide high definition, high quality = audio/video enabling a "being-there" experience. One example is an = immersive telepresence system using specially designed and special = purpose rooms with multiple displays permitting life size image = reproduction using multiple cameras, encoders, decoders, microphones and = loudspeakers. >>=20 >> Current telepresence systems are based on open standards such as RTP, = SIP, H.264, the H.323 suite, however, they cannot easily interoperate = with each other without operator assistance and expensive additional = equipment which translates from one vendor to another. >>=20 >>=20 >> The use of the word "they" in above sentence can be mistaken to mean = either TP systems or the open standards listed. >>=20 >> I suggest >>=20 >> s/they/these systems >>=20 >> to make it clearer which you are referring to. >>=20 >>=20 >> A major factor in the inability of telepresence systems to interwork = is that there is no standardized way to describe and negotiate the use = of the multiple streams of audio and video that comprise the media = flows. >>=20 >>=20 >> Is this text true if the TP systems have only 2 endpoints in the = session? >>=20 >> I agree this becomes tricky when you get to 3 or more endpoints - but = that isn't clear in the above text. >>=20 >> In addition, there is no standardized way to exchange semantic = information about what each media stream represents. >>=20 >> The WG will create specifications for SIP-based conferencing systems = to enable communication of enough information about each media stream so = that each receiving system or bridge system can make reasonable = decisions about selecting and rendering media streams. This enables = systems to make display choices that optimize the "just like being = there" experience. >>=20 >> This working group is chartered to specify the information about = media streams from one entity to another entity: >>=20 >> * Spatial relationships of cameras, displays, microphones, and >> Speakers =96 in relation to each other and to likely positions of >> participants >>=20 >> * Specific characteristics such as viewpoint, field of view/capture >> for camera/microphone/display/speaker =96 so that senders and >> middleboxes can understand how best to compose streams for >> receivers, and the receivers will know the characteristics of its >> received streams >>=20 >> *Usage of the stream, for example whether the stream is presentation, = or document camera output >>=20 >> * Aspect ratio of cameras and displays >>=20 >> * Which sources a receiver wants to receive. For example, it might = want the source for the left camera, or might want the source chosen by = VAD (Voice Activity Detection). >>=20 >>=20 >> Information between sources and sinks about media stream capabilities = will be exchanged. >>=20 >> The working group will define the semantics, syntax, and transport = mechanism necessary for communicating the necessary information. It will = consider whether the existing signaling mechanisms (e. g., SDP, BFCP) = can be extended, or another messaging method should be used. >>=20 >> The scope of the work includes describing relatively static relations = between entities (participants and devices). It also includes handling = more dynamic relationships, such as identifying the audio and video = streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with = them and therefore need to understand the same multiple stream = semantics. >>=20 >> The focus of this work is on multiple audio and video streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. >>=20 >> Interoperation with SIP and related standards for audio and video is = required. However, backwards compatibility with existing non-standards = compliant telepresence systems is not required. >>=20 >> This working group is not currently chartered to work on issues of = continuous conference control including: far end camera control, = indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. >>=20 >> Reuse of existing protocols and backwards compatibility with = SIP-compliant audio/video endpoints are important factors for the = working group to consider. The work will closely coordinate with the = appropriate areas and working groups including OPS Area, AVT, MMUSIC, = MEDIACTRL, XCON, and SIPCORE. >>=20 >> Milestones >>=20 >> Nov 2010 Submit information draft to IESG on use cases and = requirements >>=20 >> Nov 2011 Submit standards track specification to IESG indicating = spatial relationships >> of screens cameras (including variable field of view and = orientation), speakers and microphones; and the =93usage=94 of a stream = as defined in the charter. Semantics, language and transport mechanism = will be specified. >>=20 >>=20 >>=20 >> List of changes V3 to V4 >>=20 >> The WG will create specifications for SIP-based conferencing systems = to enable communication.. >> [instead of The WG will create specifications to enable = communication=85] >>=20 >> This working group is chartered to specify the information about = media streams from one entity to another entity >> [instead of This working group is chartered to specify the = information about media streams from one endpoint to another endpoint or = conference bridge including:] >>=20 >>=20 >> [added] *Usage of the stream, for example whether the stream is = presentation, or document camera output >>=20 >> Interoperation with SIP and related standards for audio and video is = required. >> [instead of Interoperation with standards compliant systems is = required, such as SIP-based conferencing systems.] >>=20 >> Reuse of existing protocols and backwards compatibility with = SIP-compliant audio/video endpoints are important factors for the = working group to consider. >> [instead of Reuse of existing protocols backwards compatibility with = existing systems is an important factor for the working group to = consider.] >>=20 >> Milestones >> Nov 2011 Submit standards track specification to IESG indicating = spatial relationships of screens, cameras (including variable >> field of view and orientation), speakers and microphones; and the = =93usage=94 of a stream as defined in the charter e Semantics, language = and transport will be specified. >>=20 >> [Instead of >> Nov 2011 Submit standards track specification to IESG indicating = spatial relationships of screens, cameras (including variable >> field of view and orientation), speakers and microphones. This = includes semantics, language and transport. >>=20 >> Apr 2011 Submit standards track specification to IESG on indicating = the "usage" of a stream as define in charter. >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From alex@vidyo.com Wed Sep 8 23:52:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326E63A6987 for ; Wed, 8 Sep 2010 23:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEbXS4rabeaF for ; Wed, 8 Sep 2010 23:52:35 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 588433A696D for ; Wed, 8 Sep 2010 23:52:32 -0700 (PDT) Received: from st020.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 8DD368BCCB2; Thu, 9 Sep 2010 02:52:59 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from mx1.myoutlookonline.com (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 8DBBF8BCC63; Thu, 9 Sep 2010 02:52:58 -0400 (EDT) Received: from BH003.mail.lan ([10.110.21.103]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Sep 2010 02:51:55 -0400 Received: from HUB023.mail.lan ([10.110.17.23]) by BH003.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Sep 2010 02:51:55 -0400 Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Thu, 9 Sep 2010 02:51:54 -0400 From: Alex Eleftheriadis To: "Allyn Romanow (allyn)" Date: Thu, 9 Sep 2010 02:52:55 -0400 Thread-Topic: [dispatch] Telepresence charter version 4 Thread-Index: ActP63z3ELbvnlfnT7asIsl7Aca8gg== Message-ID: <82AF3C89-82B4-480D-9D77-35B8D84962BF@vidyo.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_82AF3C8982B4480D9D7735B8D84962BFvidyocom_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2010 06:51:55.0389 (UTC) FILETIME=[7DA252D0:01CB4FEB] Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 06:52:38 -0000 --_000_82AF3C8982B4480D9D7735B8D84962BFvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It now looks good. --Alex On Sep 9, 2010, at 12:10 AM, Allyn Romanow (allyn) wrote: Folks, Here is the fourth version of the charter for work on multiple streams for = Telepresence. It addresses issues brought up on the mailing list. There is a list of the = changes at the end of the text. Comments? ------ MALT =96 Multi-stream Attributes for Lifelike Telepresence COCKTAIL =96 Communication and Correlation of Key Telepresence Attributes f= or Interoperable Links MAITAI =96 Multi-stream Attributes for Improving Telepresence Application I= nteroperability TEQUILA =96 Telepresence Encoding of QUalifiers for Interoperable Lifelike = Applications MOJITO =96 Multi-stream Orientation for Joining of Interoperable Telepresen= ce Operations In the context of this WG, the term telepresence is used in a general manne= r to describe systems that provide high definition, high quality audio/vide= o enabling a "being-there" experience. One example is an immersive telepre= sence system using specially designed and special purpose rooms with multip= le displays permitting life size image reproduction using multiple cameras,= encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another. A major factor in the inability of t= elepresence systems to interwork is that there is no standardized way to de= scribe and negotiate the use of the multiple streams of audio and video tha= t comprise the media flows. In addition, there is no standardized way to e= xchange semantic information about what each media stream represents. The WG will create specifications for SIP-based conferencing systems to ena= ble communication of enough information about each media stream so that eac= h receiving system or bridge system can make reasonable decisions about sel= ecting and rendering media streams. This enables systems to make display ch= oices that optimize the "just like being there" experience. This working group is chartered to specify the information about media stre= ams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and Speakers =96 in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker =96 so that senders and middleboxes can understand how best to compose streams for receivers, and the receivers will know the characteristics of its received streams *Usage of the stream, for example whether the stream is presentation, or do= cument camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want th= e source for the left camera, or might want the source chosen by VAD (Voice= Activity Detection). Information between sources and sinks about media stream capabilities will = be exchanged. The working group will define the semantics, syntax, and transport mechani= sm necessary for communicating the necessary information. It will consider = whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extende= d, or another messaging method should be used. The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics. The focus of this work is on multiple audio and video streams. Other media= types may be considered, however development of methodologies for them is = not within the scope of this work. Interoperation with SIP and related standards for audio and video is requir= ed. However, backwards compatibility with existing non-standards compliant= telepresence systems is not required. This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster. Reuse of existing protocols and backwards compatibility with SIP-compliant = audio/video endpoints are important factors for the working group to consi= der. The work will closely coordinate with the appropriate areas and workin= g groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG indicating spatial r= elationships of screens cameras (including variable field of view and orientation), sp= eakers and microphones; and the =93usage=94 of a stream as defined in the c= harter. Semantics, language and transport mechanism will be specified. List of changes V3 to V4 The WG will create specifications for SIP-based conferencing systems to ena= ble communication.. [instead of The WG will create specifications to enable communication=85] This working group is chartered to specify the information about media stre= ams from one entity to another entity [instead of This working group is chartered to specify the information abo= ut media streams from one endpoint to another endpoint or conference bridge= including:] [added] *Usage of the stream, for example whether the stream is presentatio= n, or document camera output Interoperation with SIP and related standards for audio and video is requir= ed. [instead of Interoperation with standards compliant systems is required, su= ch as SIP-based conferencing systems.] Reuse of existing protocols and backwards compatibility with SIP-compliant = audio/video endpoints are important factors for the working group to consi= der. [instead of Reuse of existing protocols backwards compatibility with existi= ng systems is an important factor for the working group to consider.] Milestones Nov 2011 Submit standards track specification to IESG indicating spatial r= elationships of screens, cameras (including variable field of view and orientation), speakers and microphones; and the =93usage= =94 of a stream as defined in the charter e Semantics, language and transpo= rt will be specified. [Instead of Nov 2011 Submit standards track specification to IESG indicating spatial r= elationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes sem= antics, language and transport. Apr 2011 Submit standards track specification to IESG on indicating the "u= sage" of a stream as define in charter. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_82AF3C8982B4480D9D7735B8D84962BFvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Fol= ks,
Here is the fourth version of the charter for work on multi= ple streams for Telepresence.
 
It addresses i= ssues brought up on the mailing list. There is a list of the changes at the= end of the text.
 
Comments?
=
 
------
 
 
<= o:p> 
MALT =96 Multi-stream Attributes for Lifelike Telepresenc= e
COCKTAIL =96 Communication and Correlation of Key Telepresenc= e Attributes for Interoperable Links
MAITAI =96 Multi-stream At= tributes for Improving Telepresence Application Interoperability=
MOJITO =96 Multi-stream Orientation for Joining = of Interoperable Telepresence Operations
 
 
In the context of this WG, the term telepresence is used in= a general manner to describe systems that provide high definition, high qu= ality audio/video enabling a "being-there" experience.  One example is= an immersive telepresence system using specially designed and special purp= ose rooms with multiple displays permitting life size image reproduction us= ing multiple cameras, encoders, decoders, microphones and loudspeakers.
 
Current telepresence systems are based on open = standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot ea= sily interoperate with each other without operator assistance and expensive= additional equipment which translates from one vendor to another. A major = factor in the inability of telepresence systems to interwork is that there = is no standardized way to describe and negotiate the use of the multiple st= reams of audio and video that comprise the media flows. In addition,  = there is no standardized way to exchange semantic information abo= ut what each media stream represents.  
 <= /div>
The WG will create specifications for SIP-based conferencing systems to en= able communication of enough information about each media stream so that ea= ch receiving system or bridge system can make reasonable decisions about se= lecting and rendering media streams. This enables systems to make display c= hoices that optimize the "just like being there" experience. 
 
This working group is chartered to specify the infor= mation about media streams from one entity to another entity:
<= o:p> 
* Spatial relationships of cameras, displays, microphones= , and
  Speakers =96 in relation to each other and to= likely positions of
  participants
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">=  
* Specific characteristics such as viewpoint, field of view/c= apture
  for camera/microphone/display/speaker =96 so= that senders and               
  middleboxes can understand how best to compose stream= s for
  receivers, and the receivers will know the ch= aracteristics of its 
  received streams
 
*Usage of the stream, for example whether the strea= m is presentation, or document camera output
 <= /div>
* Aspect ratio of cameras and displays
 
=
* Which sources a receiver wants to rec= eive.  For example, it might want the source for the left camera, or m= ight want the source chosen by VAD (Voice Activity Detection).<= /o:p>
 
 
Information between sources an= d sinks about media stream capabilities will be exchanged. =
The working group will define the semantics, syntax,&n= bsp; and transport mechanism necessary for communicating the necessary info= rmation. It will consider whether the existing signaling mechanisms (e. g.,= SDP, BFCP) can be extended, or another messaging method should be used. &n= bsp;
 
The scope of the work includes describi= ng relatively static relations between entities (participants and devices).= It also includes handling more dynamic relationships, such as identifying = the audio and video streams for the current speaker. The scope includes bot= h systems that provide a fully immersive experience, and systems that inter= work with them and therefore need to understand the same multiple stream se= mantics.  
 
The focus of this work is on= multiple audio and video streams.  Other media types may be considere= d, however development of methodologies for them is not within the scope of= this work.
 
Interoperation with SIP and rela= ted standards for audio and video is required.  However, backwards com= patibility with existing non-standards compliant telepresence systems is no= t required.
 
This working group is not curren= tly chartered to work on issues of continuous conference control including:= far end camera control, indication of fast frame update for video codecs o= r other rapid switches, floor control, conference roster.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">=  
Reuse of existing protocols and backwards compatibility with = SIP-compliant audio/video endpoints  are important factors for the wor= king group to consider. The work will closely coordinate with the appropria= te areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCO= N, and SIPCORE.
 
 Milestones  =
 
 Nov 2010 Submit information draft to IESG = on use cases and requirements
 
Nov 2011 Submi= t standards track specification to IESG  indicating spatial relationsh= ips
of  screens  cameras (including variable fiel= d of view and orientation), speakers and microphones; and the =93usage=94 o= f a stream as defined in the charter.  Semantics, language and transpo= rt mechanism will be specified.
 
&nbs= p;
 
List of changes V3 to V4
 
The WG will create specifications for SIP-based confere= ncing systems to e= nable communication..
[instead of The WG will create specificat= ions to enable communication=85]
 
This workin= g group is chartered to specify the information about media streams from on= e entity to an= other entity
[instead of  This working group is= chartered to specify the information about media streams from one endpoint= to another endpoint or conference bridge including:]
&nbs= p;
 
 
Interoperation with SIP and relate= d standards for audio and video is required.  
[instead of= Interoperation with standards compliant systems is required, such as SIP-b= ased conferencing systems.]
 
Reuse of exist= ing protocols and backwards compatibility with SIP-compliant audio/video en= dpoints  are important factors for the working group to consider.=
[instead of Reuse of existing protocols backwards compatibility wit= h existing systems is  an important  factor for the working group= to consider.]
 
Milestones
Nov 20= 11 Submit standards track specification to IESG  indicating spatial re= lationships of screens, cameras (including variable
field of = view and orientation), speakers and microphones; and the =93usage=94 of a s= tream as defined in the charter e Semantics, language and transport will be= specified.
 
[Instead of
Nov 20= 11 Submit standards track specification to IESG  indicating spatial re= lationships of screens, cameras (including variable
field of = view and orientation), speakers and microphones. This includes semantics, l= anguage and transport.
 
Apr 2011 Submit sta= ndards track specification to IESG on indicating the  "usage" of a str= eam as define in charter.
 
 
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --_000_82AF3C8982B4480D9D7735B8D84962BFvidyocom_-- From john.elwell@siemens-enterprise.com Thu Sep 9 00:31:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB323A677D for ; Thu, 9 Sep 2010 00:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj1A9WkJI9rL for ; Thu, 9 Sep 2010 00:31:03 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 52F403A6778 for ; Thu, 9 Sep 2010 00:31:03 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1434892; Thu, 9 Sep 2010 09:31:29 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 09E7E1EB82AE; Thu, 9 Sep 2010 09:31:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 9 Sep 2010 09:31:29 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , DISPATCH list Date: Thu, 9 Sep 2010 09:31:28 +0200 Thread-Topic: Telepresence charter version 4 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxw Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 07:31:04 -0000 Allyn, Can you explain the following: "It will consider whether the existing signaling mechanisms (e. g., .... BF= CP) can be extended, or another messaging method should be used" and=20 "This working group is not currently chartered to work on=20 issues of continuous conference control including: .... floor control..."=20 It is unclear to me how BFCP can be within scope yet floor control is out o= f scope. John From peter.musgrave@magorcorp.com Thu Sep 9 03:32:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCC83A6782 for ; Thu, 9 Sep 2010 03:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Adm8K0rNK7H for ; Thu, 9 Sep 2010 03:32:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id C70633A6403 for ; Thu, 9 Sep 2010 03:32:38 -0700 (PDT) Received: by qyk1 with SMTP id 1so6027421qyk.10 for ; Thu, 09 Sep 2010 03:33:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.129 with SMTP id ko1mr1420865qcb.4.1284028385647; Thu, 09 Sep 2010 03:33:05 -0700 (PDT) Received: by 10.229.80.2 with HTTP; Thu, 9 Sep 2010 03:33:05 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> Date: Thu, 9 Sep 2010 06:33:05 -0400 Message-ID: From: Peter Musgrave To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 10:32:40 -0000 Hi, Good catch. That is inconsistent. I think the reference to BFCP can be removed. Otherwise I think the charter is good to go. Peter Musgrave On Thu, Sep 9, 2010 at 3:31 AM, Elwell, John wrote: > Allyn, > > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., .... BFCP) can be extended, or another messaging method should be used" > > and > > "This working group is not currently chartered to work on > issues of continuous conference control including: .... floor control..." > > It is unclear to me how BFCP can be within scope yet floor control is out of scope. > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From lorenzo@meetecho.com Fri Sep 10 06:44:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF22E3A67A7 for ; Fri, 10 Sep 2010 06:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSO44FcORpLV for ; Fri, 10 Sep 2010 06:44:51 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out9.aruba.it [62.149.158.29]) by core3.amsl.com (Postfix) with SMTP id CD0823A6403 for ; Fri, 10 Sep 2010 06:44:50 -0700 (PDT) Received: (qmail 32742 invoked by uid 89); 10 Sep 2010 13:45:06 -0000 Received: from unknown (HELO smtp6.aruba.it) (62.149.128.201) by smtplq04.aruba.it with SMTP; 10 Sep 2010 13:45:06 -0000 Received: (qmail 24757 invoked by uid 89); 10 Sep 2010 13:45:07 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.188) by smtp6.ad.aruba.it with SMTP; 10 Sep 2010 13:45:06 -0000 Date: Fri, 10 Sep 2010 15:42:46 +0200 From: Lorenzo Miniero To: Peter Musgrave Message-Id: <20100910154246.c50943eb.lorenzo@meetecho.com> In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> Organization: Meetecho X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp6.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 13:44:54 -0000 I agree. BFCP itself needs ways (e.g. RFC4583) to correlate each stream to the floor handling it, which is similar to what we want to achieve in this new WG. About limiting the scope to audio/video, why not rephrase it so that we limit the scope to whatever can be sent via RTP? That would be less strict, I guess, and allow for more flexibility. For what concerns the name, I'm for MAITAI. L. On Thu, 9 Sep 2010 06:33:05 -0400 Peter Musgrave wrote: > Hi, > > Good catch. That is inconsistent. > > I think the reference to BFCP can be removed. > > Otherwise I think the charter is good to go. > > Peter Musgrave > > On Thu, Sep 9, 2010 at 3:31 AM, Elwell, John > wrote: > > Allyn, > > > > Can you explain the following: > > "It will consider whether the existing signaling mechanisms (e. g., .... BFCP) can be extended, or another messaging method should be used" > > > > and > > > > "This working group is not currently chartered to work on > > issues of continuous conference control including: .... floor control..." > > > > It is unclear to me how BFCP can be within scope yet floor control is out of scope. > > > > John > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Lorenzo Miniero Meetecho s.r.l. http://www.meetecho.com/ From Even.roni@huawei.com Fri Sep 10 07:59:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069EB3A68D8 for ; Fri, 10 Sep 2010 07:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.048 X-Spam-Level: X-Spam-Status: No, score=-100.048 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T3IYVV0-o25 for ; Fri, 10 Sep 2010 07:59:46 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F21A63A67EF for ; Fri, 10 Sep 2010 07:59:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8J00CIFDO2TC@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 10 Sep 2010 23:00:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8J007BZDO2XU@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 10 Sep 2010 23:00:02 +0800 (CST) Received: from windows8d787f9 ([109.64.25.245]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8J00FE7DNS5T@szxml01-in.huawei.com>; Fri, 10 Sep 2010 23:00:02 +0800 (CST) Date: Fri, 10 Sep 2010 17:58:41 +0300 From: Roni Even In-reply-to: To: 'Peter Musgrave' , "'Elwell, John'" Message-id: <03dd01cb50f8$aea98d90$0bfca8b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActQCnJvGbrrnvH+SeK52EwxOQad6AA7jEvA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> Cc: 'DISPATCH list' Subject: Re: [dispatch] Telepresence charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 14:59:47 -0000 +1 Roni > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Peter Musgrave > Sent: Thursday, September 09, 2010 1:33 PM > To: Elwell, John > Cc: DISPATCH list > Subject: Re: [dispatch] Telepresence charter version 4 > > Hi, > > Good catch. That is inconsistent. > > I think the reference to BFCP can be removed. > > Otherwise I think the charter is good to go. > > Peter Musgrave > > On Thu, Sep 9, 2010 at 3:31 AM, Elwell, John > wrote: > > Allyn, > > > > Can you explain the following: > > "It will consider whether the existing signaling mechanisms (e. g., > .... BFCP) can be extended, or another messaging method should be used" > > > > and > > > > "This working group is not currently chartered to work on > > issues of continuous conference control including: .... floor > control..." > > > > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. > > > > John > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From spromano@unina.it Tue Sep 14 10:48:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86E03A682D for ; Tue, 14 Sep 2010 10:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.323 X-Spam-Level: X-Spam-Status: No, score=-99.323 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SpxAqIu+axl for ; Tue, 14 Sep 2010 10:48:30 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id 8D4DB3A695D for ; Tue, 14 Sep 2010 10:48:29 -0700 (PDT) Received: from [192.168.1.238] (host218-82-dynamic.51-82-r.retail.telecomitalia.it [82.51.82.218]) (authenticated bits=0) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id o8EHmnqb022326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Sep 2010 19:48:53 +0200 References: <4C7C0457.9070008@unina.it> <4C7E3254.6000702@unina.it> In-Reply-To: <4C7E3254.6000702@unina.it> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <06BE9F91-512C-4BEB-AEF3-BC036CCF3C50@unina.it> X-Mailer: iPhone Mail (8A306) From: Simon Pietro Romano Date: Tue, 14 Sep 2010 19:48:35 +0200 To: Simon Pietro Romano Cc: DISPATCH Subject: Re: [dispatch] [RAI] Reminder: DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:48:31 -0000 Hi guys, I hoped to receive much more feedback on the DCON proposal. Did you have a c= hance to give it a look? I'd so Il giorno 01/set/2010, alle ore 13:00, Simon Pietro Romano ha scritto: > Hi Peter, >=20 > thanks for your comment. The DisCO approach is definitely relevant to the p= roposed DCON work, especially in the case where the focus overlay network is= built and managed with a p2p approach. I think that, in case the IETF were t= o charter the DCON proposal, the mentioned draft should be taken into accoun= t since the beginning. >=20 > Cheers, > Simon >=20 > Il 31/08/2010 12.43, Peter Musgrave ha scritto: >> Hi Simon, >>=20 >> This is indeed an interesting topic. >>=20 >> How does what you are proposing relate to the approach in DisCo >> (https://datatracker.ietf.org/doc/draft-knauf-p2psip-disco/) ? >>=20 >> (I see significant overlap - and I like the use of RELOAD in DisCO, >> since it is a rich NAT/security aware mechanism for building >> distributed conferencing) >>=20 >> Regards, >>=20 >> Peter Musgrave >>=20 >> On Mon, Aug 30, 2010 at 3:19 PM, Simon Pietro Romano w= rote: >> =20 >>> Dear chairs and all, >>>=20 >>> please find attached a proposal submission related to a topic that I cal= led >>> DCON and which stands for Distributed Conferencing. I hope that with XCO= N >>> which is close to successfully concluding its work, the time is now ripe= for >>> focusing on how to improve its scalability through distribution of >>> components/responsibilities. I am sending a drafty draft of DCON's poten= tial >>> charter, just to give you some initial material to debate. I'm looking >>> forward to receiving your feedback. >>>=20 >>> Cheers, >>>=20 >>> Simon >>>=20 >>> Il 13/08/2010 18.37, Mary Barnes ha scritto: >>>=20 >>> Hi all, >>> Just a reminder that the first deadline for IETF-79 for the DISPATCH WG >>> topics is two weeks from Monday. >>> Regards, >>> Mary. >>>=20 >>> On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes >>> wrote: >>> =20 >>>> Hi folks, >>>> The following summarizes the deadlines for topics for DISPATCH for >>>> IETF-79: >>>> * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of >>>> plans to submit a proposal. [Two weeks prior to BoF proposal deadline= ] >>>>=20 >>>> * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week pri= or >>>> to BoF proposal deadline] >>>>=20 >>>> * Sept. 20, 2010. Topics that are to be the focus of IETF-79 >>>> are announced. >>>> [One week before deadline to request WG slots] >>>>=20 >>>> * Oct. 18th, 2010. -00 draft deadline. >>>>=20 >>>> * Oct. 25th, 2010. Draft deadline. >>>>=20 >>>> These deadlines have been published on the DISPATCH WG wiki page: >>>> http://trac.tools.ietf.org/wg/dispatch/trac/wiki >>>> Note that these dates are closer to the end of the meeting than those f= or >>>> IETF-78 because there is just over 3 months between the end of IETF-78= and >>>> beginning of IETF-79 (versus the 4 months we had between this meeting a= nd >>>> Anaheim). >>>>=20 >>>> Note that registration and WG/Bof scheduling for IETF-79 starts on Augu= st >>>> 9th: >>>> http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 >>>> DISPATCH sets the first deadline such that it's still possible to reque= st >>>> a BoF for topics that may be wider in scope and require broader communi= ty >>>> review. The deadlines for BoFs are set by the leadership so that there= is >>>> time to consider BoFs in the scheduling. Also, as Gonzalo noted in a >>>> separate email, WGs need to have a draft charter at the time they reque= st a >>>> WG slot. Further information on the motivation for the DISPATCH planni= ng >>>> model is provided in the wiki. >>>> Regards, >>>> Mary >>>> DISPATCH WG co-chair >>>> =20 >>>=20 >>> _______________________________________________ >>> RAI mailing list >>> RAI@ietf.org >>> https://www.ietf.org/mailman/listinfo/rai >>>=20 >>>=20 >>> -- >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Science Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7684219 >>> e-mail: spromano@unina.it >>> http://www.comics.unina.it/simonpietro.romano >>>=20 >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>> =20 >=20 > --=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From spromano@unina.it Tue Sep 14 10:52:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A8F3A69C8 for ; Tue, 14 Sep 2010 10:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.323 X-Spam-Level: X-Spam-Status: No, score=-99.323 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beF7hKHGe5pw for ; Tue, 14 Sep 2010 10:52:02 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id CB6493A6AC6 for ; Tue, 14 Sep 2010 10:51:55 -0700 (PDT) Received: from [192.168.1.238] (host218-82-dynamic.51-82-r.retail.telecomitalia.it [82.51.82.218]) (authenticated bits=0) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id o8EHq7BA022422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Sep 2010 19:52:10 +0200 References: <4C7C0457.9070008@unina.it> <4C7E3254.6000702@unina.it> <06BE9F91-512C-4BEB-AEF3-BC036CCF3C50@unina.it> In-Reply-To: <06BE9F91-512C-4BEB-AEF3-BC036CCF3C50@unina.it> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <5AEC922E-AB73-4F43-874A-D547DA6ED91B@unina.it> X-Mailer: iPhone Mail (8A306) From: Simon Pietro Romano Date: Tue, 14 Sep 2010 19:51:53 +0200 To: Simon Pietro Romano Cc: DISPATCH Subject: Re: [dispatch] [RAI] Reminder: DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:52:03 -0000 ...hops, I hit the send button too early! Sorry, just wanted to add that we w= ill appreciate your feedback. Cheers, Simon Il giorno 14/set/2010, alle ore 19:48, Simon Pietro Romano ha scritto: > Hi guys, >=20 > I hoped to receive much more feedback on the DCON proposal. Did you have a= chance to give it a look? I'd so >=20 > Il giorno 01/set/2010, alle ore 13:00, Simon Pietro Romano ha scritto: >=20 >> Hi Peter, >>=20 >> thanks for your comment. The DisCO approach is definitely relevant to the= proposed DCON work, especially in the case where the focus overlay network i= s built and managed with a p2p approach. I think that, in case the IETF were= to charter the DCON proposal, the mentioned draft should be taken into acco= unt since the beginning. >>=20 >> Cheers, >> Simon >>=20 >> Il 31/08/2010 12.43, Peter Musgrave ha scritto: >>> Hi Simon, >>>=20 >>> This is indeed an interesting topic. >>>=20 >>> How does what you are proposing relate to the approach in DisCo >>> (https://datatracker.ietf.org/doc/draft-knauf-p2psip-disco/) ? >>>=20 >>> (I see significant overlap - and I like the use of RELOAD in DisCO, >>> since it is a rich NAT/security aware mechanism for building >>> distributed conferencing) >>>=20 >>> Regards, >>>=20 >>> Peter Musgrave >>>=20 >>> On Mon, Aug 30, 2010 at 3:19 PM, Simon Pietro Romano = wrote: >>>=20 >>>> Dear chairs and all, >>>>=20 >>>> please find attached a proposal submission related to a topic that I ca= lled >>>> DCON and which stands for Distributed Conferencing. I hope that with XC= ON >>>> which is close to successfully concluding its work, the time is now rip= e for >>>> focusing on how to improve its scalability through distribution of >>>> components/responsibilities. I am sending a drafty draft of DCON's pote= ntial >>>> charter, just to give you some initial material to debate. I'm looking >>>> forward to receiving your feedback. >>>>=20 >>>> Cheers, >>>>=20 >>>> Simon >>>>=20 >>>> Il 13/08/2010 18.37, Mary Barnes ha scritto: >>>>=20 >>>> Hi all, >>>> Just a reminder that the first deadline for IETF-79 for the DISPATCH WG= >>>> topics is two weeks from Monday. >>>> Regards, >>>> Mary. >>>>=20 >>>> On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes >>>> wrote: >>>>=20 >>>>> Hi folks, >>>>> The following summarizes the deadlines for topics for DISPATCH for >>>>> IETF-79: >>>>> * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of >>>>> plans to submit a proposal. [Two weeks prior to BoF proposal deadline= ] >>>>>=20 >>>>> * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week pr= ior >>>>> to BoF proposal deadline] >>>>>=20 >>>>> * Sept. 20, 2010. Topics that are to be the focus of IETF-79 >>>>> are announced. >>>>> [One week before deadline to request WG slots] >>>>>=20 >>>>> * Oct. 18th, 2010. -00 draft deadline. >>>>>=20 >>>>> * Oct. 25th, 2010. Draft deadline. >>>>>=20 >>>>> These deadlines have been published on the DISPATCH WG wiki page: >>>>> http://trac.tools.ietf.org/wg/dispatch/trac/wiki >>>>> Note that these dates are closer to the end of the meeting than those f= or >>>>> IETF-78 because there is just over 3 months between the end of IETF-7= 8 and >>>>> beginning of IETF-79 (versus the 4 months we had between this meeting a= nd >>>>> Anaheim). >>>>>=20 >>>>> Note that registration and WG/Bof scheduling for IETF-79 starts on Aug= ust >>>>> 9th: >>>>> http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 >>>>> DISPATCH sets the first deadline such that it's still possible to requ= est >>>>> a BoF for topics that may be wider in scope and require broader commun= ity >>>>> review. The deadlines for BoFs are set by the leadership so that ther= e is >>>>> time to consider BoFs in the scheduling. Also, as Gonzalo noted in a >>>>> separate email, WGs need to have a draft charter at the time they requ= est a >>>>> WG slot. Further information on the motivation for the DISPATCH plann= ing >>>>> model is provided in the wiki. >>>>> Regards, >>>>> Mary >>>>> DISPATCH WG co-chair >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> RAI mailing list >>>> RAI@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rai >>>>=20 >>>>=20 >>>> -- >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Science Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7684219 >>>> e-mail: spromano@unina.it >>>> http://www.comics.unina.it/simonpietro.romano >>>>=20 >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> (_/ >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>>=20 >>>>=20 >>=20 >> --=20 >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Science Department >> Phone: +39 081 7683823 -- Fax: +39 081 7684219 >> e-mail: spromano@unina.it >> http://www.comics.unina.it/simonpietro.romano >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 From allyn@cisco.com Wed Sep 15 10:42:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7ADE3A68F8 for ; Wed, 15 Sep 2010 10:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.483 X-Spam-Level: X-Spam-Status: No, score=-9.483 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuI3lNozt3aS for ; Wed, 15 Sep 2010 10:42:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1CE883A6848 for ; Wed, 15 Sep 2010 10:42:36 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEaikEyrRN+J/2dsb2JhbAChZ3GqCJwhhUEEhEqIZg X-IronPort-AV: E=Sophos;i="4.56,371,1280707200"; d="scan'208";a="589719566" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 15 Sep 2010 17:42:19 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o8FHgJIi019200; Wed, 15 Sep 2010 17:42:19 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Sep 2010 10:42:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: IAXG K3y/ Lljh QIhl Uec5 WwQc XZ+x Zauq axlg dofO egoK fh00 gOCm iC86 jzPJ kaJC; 3; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAagBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AG0AYQByAHkALgBpAGUAdABmAC4AYgBhAHIAbgBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {25D4C8C5-A647-4C44-A5B9-91E33D78EBFD}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 15 Sep 2010 17:42:10 GMT; VABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABjAGgAYQByAHQAZQByACAAdgBlAHIAcwBpAG8AbgAgADUA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {25D4C8C5-A647-4C44-A5B9-91E33D78EBFD} Content-class: urn:content-classes:message Date: Wed, 15 Sep 2010 10:42:10 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Elwell, John" , "DISPATCH list" X-OriginalArrivalTime: 15 Sep 2010 17:42:19.0077 (UTC) FILETIME=[580B0F50:01CB54FD] Subject: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 17:42:39 -0000 In keeping with John's good catch, the reference to BFCP has been removed.=20 This was the only suggested change to the charter. Thanks, Allyn MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - Communication and Correlation of Key Telepresence Attributes for Interoperable Links MAITAI - Multi-stream Attributes for Improving Telepresence Application Interoperability TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike Applications MOJITO - Multi-stream Orientation for Joining of Interoperable Telepresence Operations In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. =20 The WG will create specifications for SIP-based conferencing systems to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience.=20 This working group is chartered to specify the information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and Speakers - in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker - so that senders and middleboxes can understand how best to compose streams for receivers, and the receivers will know the characteristics of its=20 received streams *Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). Information between sources and sinks about media stream capabilities will be exchanged.=20 The working group will define the semantics, syntax, and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP) can be extended, or another messaging method should be used. =20 The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster.=20 Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones =20 Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG indicating spatial relationships=20 of screens cameras (including variable field of view and orientation), speakers and microphones; and the "usage" of a stream as defined in the charter. Semantics, language and transport mechanism will be specified. ------------------------------------------------------------------------ -------- -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, September 09, 2010 12:31 AM To: Allyn Romanow (allyn); DISPATCH list Subject: RE: Telepresence charter version 4 Allyn, Can you explain the following: "It will consider whether the existing signaling mechanisms (e. g., .... BFCP) can be extended, or another messaging method should be used" and=20 "This working group is not currently chartered to work on=20 issues of continuous conference control including: .... floor control..."=20 It is unclear to me how BFCP can be within scope yet floor control is out of scope. John From 2mkristensen@gmail.com Thu Sep 16 04:40:46 2010 Return-Path: <2mkristensen@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC9F3A696D for ; Thu, 16 Sep 2010 04:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1DU0xw9DQzF for ; Thu, 16 Sep 2010 04:40:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9AA553A6AF9 for ; Thu, 16 Sep 2010 04:40:36 -0700 (PDT) Received: by vws10 with SMTP id 10so1049087vws.31 for ; Thu, 16 Sep 2010 04:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3mm5h2WtJpRLieClIdh8v7vS7k9R2CZsX+h92z/eqNA=; b=oSBQbyEDFbt3wf2wmpJD24Pss46vzGm6JJOCVXpJihd7ZsQKz7O0D7NOjQfzz21Ph9 jdGOTrV+zqY6WkY8T8kN/LefCmHjgEgkZlX3Ct+743/GsB4JzTQk4lMK7BZIigp7CPsp D0nBBHzVINPD0scQHleNRFNBosVMFPBWlrty0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tU52cw6eQhxyiDW8qj0WvllZOkDDOuiKfFS1bf2SR/VSyqJw9AA0ODTW7fZ/mOO09v ot8oDQJMSvYVxep9jkViRhaMy9EcpvjB8JPtLCIMeYzDmyDtqjblil8IQPy2N/9pDtnp rK0+pTe9MLY894B/qfyslLcCfo3DAvhQpUmXw= MIME-Version: 1.0 Received: by 10.220.127.37 with SMTP id e37mr1742730vcs.31.1284637252944; Thu, 16 Sep 2010 04:40:52 -0700 (PDT) Received: by 10.220.181.9 with HTTP; Thu, 16 Sep 2010 04:40:52 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> Date: Thu, 16 Sep 2010 13:40:52 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Allyn Romanow (allyn)" Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH list , Tom Kristensen Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 11:40:47 -0000 With a reference to a protocol for functionality (floor control) out of scope removed, this charter looks fine to me :-) Regarding name. Not that I'm associated with the temperance movement or something, but instead of all those alcohol related names I think it's nice for IETF to explicitly have (a) CLUE. As proposed earlier; CLUE ControLling mUltiple streams for TElepresence -- Tom From peter.musgrave@magorcorp.com Thu Sep 16 05:36:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325403A6915 for ; Thu, 16 Sep 2010 05:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Atl3DT4YpE+F for ; Thu, 16 Sep 2010 05:36:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0BF923A68A3 for ; Thu, 16 Sep 2010 05:36:02 -0700 (PDT) Received: by qwc9 with SMTP id 9so1001834qwc.31 for ; Thu, 16 Sep 2010 05:36:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.2.134 with SMTP id 6mr2184991qaj.44.1284640587816; Thu, 16 Sep 2010 05:36:27 -0700 (PDT) Received: by 10.229.72.135 with HTTP; Thu, 16 Sep 2010 05:36:27 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> Date: Thu, 16 Sep 2010 08:36:27 -0400 Message-ID: From: Peter Musgrave To: Tom Kristensen <2mkristensen@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list , Tom Kristensen Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:36:04 -0000 +1 Ambivalent about the name - but let's pick one and get going! Peter Musgrave On Thu, Sep 16, 2010 at 7:40 AM, Tom Kristensen <2mkristensen@gmail.com> wr= ote: > With a reference to a protocol for functionality (floor control) out > of scope removed, this charter looks fine to me :-) > > > Regarding name. Not that I'm associated with the temperance movement > or something, but instead of all those alcohol related names I think > it's nice for IETF to explicitly have (a) CLUE. > > As proposed earlier; =A0 CLUE ControLling mUltiple streams for TElepresen= ce > > -- Tom > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From lennox@cs.columbia.edu Thu Sep 16 08:21:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5493A682F for ; Thu, 16 Sep 2010 08:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bciBuQCu3JKx for ; Thu, 16 Sep 2010 08:21:31 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 85A023A698A for ; Thu, 16 Sep 2010 08:21:30 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail2.panix.com (Postfix) with ESMTP id 72A9538E53; Thu, 16 Sep 2010 11:21:55 -0400 (EDT) Received: from irtcluster02.cs.columbia.edu (irtcluster02.cs.columbia.edu [128.59.11.131]) by mailbackend.panix.com (Postfix) with ESMTP id 426CA31D20; Thu, 16 Sep 2010 11:21:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19602.13842.920779.207123@irtcluster02.cs.columbia.edu> Date: Thu, 16 Sep 2010 11:21:54 -0400 To: "Allyn Romanow (allyn)" In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 15:21:36 -0000 This charter looks good to me, other than some minor editorial nits (details of punctuation and spacing). Would it be useful to comment on those, or does the Secretariat take care of that? -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com On Wednesday, September 15 2010, "Allyn Romanow (allyn)" wrote to "Elwell, John, DISPATCH list" saying: > MALT - Multi-stream Attributes for Lifelike Telepresence > COCKTAIL - Communication and Correlation of Key Telepresence Attributes > for Interoperable Links > MAITAI - Multi-stream Attributes for Improving Telepresence Application > Interoperability > TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike > Applications > MOJITO - Multi-stream Orientation for Joining of Interoperable > Telepresence Operations > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience. One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders, microphones and > loudspeakers. > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor in > the inability of telepresence systems to interwork is that there is no > standardized way to describe and negotiate the use of the multiple > streams of audio and video that comprise the media flows. In addition, > there is no standardized way to exchange semantic information about what > each media stream represents. > > The WG will create specifications for SIP-based conferencing systems to > enable communication of enough information about each media stream so > that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience. > > This working group is chartered to specify the information about media > streams from one entity to another entity: > > * Spatial relationships of cameras, displays, microphones, and > Speakers - in relation to each other and to likely positions of > participants > > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker - so that senders and > > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its > received streams > > *Usage of the stream, for example whether the stream is presentation, or > document camera output > > * Aspect ratio of cameras and displays > > * Which sources a receiver wants to receive. For example, it might want > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > > Information between sources and sinks about media stream capabilities > will be exchanged. > > The working group will define the semantics, syntax, and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (e. g., SDP) can be > extended, or another messaging method should be used. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream > semantics. > > The focus of this work is on multiple audio and video streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. > > Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing non-standards > compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. > > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are important factors for the > working group to consider. The work will closely coordinate with the > appropriate areas and working groups including OPS Area, AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > > Nov 2011 Submit standards track specification to IESG indicating > spatial relationships > of screens cameras (including variable field of view and orientation), > speakers and microphones; and the "usage" of a stream as defined in the > charter. Semantics, language and transport mechanism will be specified. > > > > ------------------------------------------------------------------------ > -------- > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, September 09, 2010 12:31 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence charter version 4 > > Allyn, > > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., .... > BFCP) can be extended, or another messaging method should be used" > > and > > "This working group is not currently chartered to work on > issues of continuous conference control including: .... floor > control..." > > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mary.ietf.barnes@gmail.com Thu Sep 16 09:33:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912FB3A688E for ; Thu, 16 Sep 2010 09:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P26MQSEvsLlX for ; Thu, 16 Sep 2010 09:33:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A86103A6905 for ; Thu, 16 Sep 2010 09:33:01 -0700 (PDT) Received: by gyd12 with SMTP id 12so621779gyd.31 for ; Thu, 16 Sep 2010 09:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9B+r/Zrl64wBYQ4Q9wjMgWwjV++crW7xcKYWBfbygvs=; b=Jr4FJcrGUwuK4uoHwlmJgGMETNClHg4mZQ+lIHJ3PqVJmM8YhYcsVtQ/kHlaqnesJw 0+Vthbkr/yHK8s10IALTOnR41IV6D5SDB9X0QXpwp5ggqZfKcovXjJeoI3vN6GdnJttC YR6BZgj87OSmacFW+6bIuPtU+dSMBPVJV49sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CTslEYCg0Ey9YDmpMbsFqGT1TGBDCFJR24lpyqz2f/g+iqYCTgBj/kIATI5OtVOqSN 8eeGpPfzlks4vpaM1tnqX4OAoij7DfiouyzYntzHlQn5x3r/ZgR3M/eOtcstpUWKQy6v v8VunQtzJVKYFesE64KleahYRDqGDX/Mk+7OI= MIME-Version: 1.0 Received: by 10.150.195.1 with SMTP id s1mr4128712ybf.361.1284654805326; Thu, 16 Sep 2010 09:33:25 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Thu, 16 Sep 2010 09:33:25 -0700 (PDT) In-Reply-To: <19602.13842.920779.207123@irtcluster02.cs.columbia.edu> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <19602.13842.920779.207123@irtcluster02.cs.columbia.edu> Date: Thu, 16 Sep 2010 11:33:25 -0500 Message-ID: From: Mary Barnes To: lennox@cs.columbia.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 16:33:09 -0000 Hi Jonathan, If you could please just send those offlist, we can get those fixed. Thanks, Mary. On Thu, Sep 16, 2010 at 10:21 AM, wrote: > > This charter looks good to me, other than some minor editorial nits (deta= ils > of punctuation and spacing). =A0Would it be useful to comment on those, o= r > does the Secretariat take care of that? > > -- > Jonathan Lennox > lennox@cs.columbia.edu / jonathan@vidyo.com > > On Wednesday, September 15 2010, "Allyn Romanow (allyn)" wrote to "Elwell= , John, DISPATCH list" saying: > >> MALT - Multi-stream Attributes for Lifelike Telepresence >> COCKTAIL - Communication and Correlation of Key Telepresence Attributes >> for Interoperable Links >> MAITAI - Multi-stream Attributes for Improving Telepresence Application >> Interoperability >> TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike >> Applications >> MOJITO - Multi-stream Orientation for Joining of Interoperable >> Telepresence Operations >> >> >> In the context of this WG, the term telepresence is used in a general >> manner to describe systems that provide high definition, high quality >> audio/video enabling a "being-there" experience. =A0One example is an >> immersive telepresence system using specially designed and special >> purpose rooms with multiple displays permitting life size image >> reproduction using multiple cameras, encoders, decoders, microphones and >> loudspeakers. >> >> Current telepresence systems are based on open standards such as RTP, >> SIP, H.264, the H.323 suite, however, they cannot easily interoperate >> with each other without operator assistance and expensive additional >> equipment which translates from one vendor to another. A major factor in >> the inability of telepresence systems to interwork is that there is no >> standardized way to describe and negotiate the use of the multiple >> streams of audio and video that comprise the media flows. In addition, >> there is no standardized way to exchange semantic information about what >> each media stream represents. >> >> The WG will create specifications for SIP-based conferencing systems to >> enable communication of enough information about each media stream so >> that each receiving system or bridge system can make reasonable >> decisions about selecting and rendering media streams. This enables >> systems to make display choices that optimize the "just like being >> there" experience. >> >> This working group is chartered to specify the information about media >> streams from one entity to another entity: >> >> * Spatial relationships of cameras, displays, microphones, and >> =A0 Speakers - in relation to each other and to likely positions of >> =A0 participants >> >> * Specific characteristics such as viewpoint, field of view/capture >> =A0 for camera/microphone/display/speaker - so that senders and >> >> =A0 middleboxes can understand how best to compose streams for >> =A0 receivers, and the receivers will know the characteristics of its >> =A0 received streams >> >> *Usage of the stream, for example whether the stream is presentation, or >> document camera output >> >> * Aspect ratio of cameras and displays >> >> * Which sources a receiver wants to receive. =A0For example, it might wa= nt >> the source for the left camera, or might want the source chosen by VAD >> (Voice Activity Detection). >> >> >> Information between sources and sinks about media stream capabilities >> will be exchanged. >> >> The working group will define the semantics, syntax, =A0and transport >> mechanism necessary for communicating the necessary information. It will >> consider whether the existing signaling mechanisms (e. g., SDP) can be >> extended, or another messaging method should be used. >> >> The scope of the work includes describing relatively static relations >> between entities (participants and devices). It also includes handling >> more dynamic relationships, such as identifying the audio and video >> streams for the current speaker. The scope includes both systems that >> provide a fully immersive experience, and systems that interwork with >> them and therefore need to understand the same multiple stream >> semantics. >> >> The focus of this work is on multiple audio and video streams. =A0Other >> media types may be considered, however development of methodologies for >> them is not within the scope of this work. >> >> Interoperation with SIP and related standards for audio and video is >> required. =A0However, backwards compatibility with existing non-standard= s >> compliant telepresence systems is not required. >> >> This working group is not currently chartered to work on issues of >> continuous conference control including: far end camera control, >> indication of fast frame update for video codecs or other rapid >> switches, floor control, conference roster. >> >> Reuse of existing protocols and backwards compatibility with >> SIP-compliant audio/video endpoints =A0are important factors for the >> working group to consider. The work will closely coordinate with the >> appropriate areas and working groups including OPS Area, AVT, MMUSIC, >> MEDIACTRL, XCON, and SIPCORE. >> >> =A0Milestones >> >> =A0Nov 2010 Submit information draft to IESG on use cases and requiremen= ts >> >> Nov 2011 Submit standards track specification to IESG =A0indicating >> spatial relationships >> of =A0screens =A0cameras (including variable field of view and orientati= on), >> speakers and microphones; and the "usage" of a stream as defined in the >> charter. =A0Semantics, language and transport mechanism will be specifie= d. >> >> >> >> ------------------------------------------------------------------------ >> -------- >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, September 09, 2010 12:31 AM >> To: Allyn Romanow (allyn); DISPATCH list >> Subject: RE: Telepresence charter version 4 >> >> Allyn, >> >> Can you explain the following: >> "It will consider whether the existing signaling mechanisms (e. g., .... >> BFCP) can be extended, or another messaging method should be used" >> >> and >> >> "This working group is not currently chartered to work on >> issues of continuous conference control including: .... floor >> control..." >> >> It is unclear to me how BFCP can be within scope yet floor control is >> out of scope. >> >> John >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mary.ietf.barnes@gmail.com Thu Sep 16 16:34:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C89B3A6AD4 for ; Thu, 16 Sep 2010 16:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BTGYzpSffOD for ; Thu, 16 Sep 2010 16:34:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 781773A695A for ; Thu, 16 Sep 2010 16:34:51 -0700 (PDT) Received: by yxl31 with SMTP id 31so794405yxl.31 for ; Thu, 16 Sep 2010 16:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=89ZQl1IEqdrZ/vt2B0mQnPpTdJp6jfPPLxULOtm0Hms=; b=MpiOaSvRdFLJ6/smDba0aTwh/qiRsZM0R6R0miloX2fO1rAmWZCqEdb+dZTn55hNCm vQfEiIljYQz82LpGtJIuQA3dCmfu0MSvk8b2WVbP5TJYopIjxOTyHw+81sjHSHjC2pdp fzd1wLeqc9fxNtD/7GCLOz787BN4ebgbZnmn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=AwCH+Aadm4TMtaGZK6rMtOZ/sEuWWrJ1ETRpdoi0L34QEvvYS+MLc1SNvx6EsODUBz 0Nikc+xin4mA/sgBBDOfZBtzVK7nZNcybabW/QeXv9aapPbC/7+sph3nsNd7AcT/+sv4 W1xPDOT+WmiiHoDdAEAipnh+qWivyVoWhnTbg= MIME-Version: 1.0 Received: by 10.150.52.13 with SMTP id z13mr4477642ybz.397.1284680116392; Thu, 16 Sep 2010 16:35:16 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Thu, 16 Sep 2010 16:35:16 -0700 (PDT) In-Reply-To: <20100916232602.BE4603A69FC@core3.amsl.com> References: <20100916232602.BE4603A69FC@core3.amsl.com> Date: Thu, 16 Sep 2010 18:35:16 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [dispatch] Fwd: NomCom 2010-2011: Call for More Nominations X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 23:34:53 -0000 Hi folks, Per Tom's note below there have been very few nominations thus far. Please consider nominating yourself and others for the open positions. Even if you like the incumbent AD, as Tom notes, circumstances can change and they may no longer be able to serve come the March timeframe. Thanks, Mary. ---------- Forwarded message ---------- From: NomCom Chair Date: Thu, Sep 16, 2010 at 6:26 PM Subject: NomCom 2010-2011: Call for More Nominations To: IETF Announcement list Hi Folks, Nominations have slowed down dramatically, so this update is to enlist the community in an effort to pick up the pace. We are very far behind in nominations for all the open positions but in particular we need nominations for the IESG and IAOC open positions. There have been no nominations received (other than for the incumbents) in INT, RAI, and RTG, and only 1 for OPS. =A0Likewise, in IAOC there have been no nominations submitted other than the incumbent. The acceptance rates of those nominated has also been very slow. In order to initiate the open list of willing nominees we are in need of a reasonable number of acceptances, and due to the low number of nominees and acceptances have delayed the start date for publishing the first open list to September 20. =A0So if you have been nominated and are willing to serve, but have not yet confirmed this by email back to the NomCom, please do so as soon as possible. We need Community input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations =96 it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? =A0Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the IETF Nominating Committee. - You may nominate yourself. - You can nominate someone you know whom you think would do a good job. Do not worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/2468/ You may enter a nomination by going to the following URL https://wiki.tools.ietf.org/group/nomcom/10/nominate You may also nominate someone by sending an email to nomcom10@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the tools page at the following URL http://trac.tools.ietf.org/newlogin Open List: ---------- As you already know, NomCom 2010-2011 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- Once the open list is available, the entire community will be invited to provide feedback. I will send a further announcement requesting feedback on the nominees, describing how to submit feedback, and how to view the open list of nominees. Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-chair@ietf.org twalsh@juniper.net _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From br@brianrosen.net Fri Sep 17 13:16:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3A43A6947 for ; Fri, 17 Sep 2010 13:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COoIj5jJKumQ for ; Fri, 17 Sep 2010 13:16:46 -0700 (PDT) Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by core3.amsl.com (Postfix) with ESMTP id 3A23A3A6944 for ; Fri, 17 Sep 2010 13:16:46 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.60]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OwhMn-0005Xb-BC; Fri, 17 Sep 2010 13:17:10 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> Date: Fri, 17 Sep 2010 16:16:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> To: Allyn Romanow (allyn) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wwh1.winweblinux.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 20:16:48 -0000 I am happy with the charter. I am partial to MAITAI, but all of them = are fine. Pick one and let's move on. Brian On Sep 15, 2010, at 1:42 PM, Allyn Romanow (allyn) wrote: > In keeping with John's good catch, the reference to BFCP has been > removed.=20 > This was the only suggested change to the charter. >=20 >=20 > Thanks, > Allyn >=20 >=20 >=20 >=20 >=20 >=20 > MALT - Multi-stream Attributes for Lifelike Telepresence > COCKTAIL - Communication and Correlation of Key Telepresence = Attributes > for Interoperable Links > MAITAI - Multi-stream Attributes for Improving Telepresence = Application > Interoperability > TEQUILA - Telepresence Encoding of QUalifiers for Interoperable = Lifelike > Applications > MOJITO - Multi-stream Orientation for Joining of Interoperable > Telepresence Operations >=20 >=20 > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience. One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders, microphones = and > loudspeakers. >=20 > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor = in > the inability of telepresence systems to interwork is that there is no > standardized way to describe and negotiate the use of the multiple > streams of audio and video that comprise the media flows. In addition, > there is no standardized way to exchange semantic information about = what > each media stream represents. =20 >=20 > The WG will create specifications for SIP-based conferencing systems = to > enable communication of enough information about each media stream so > that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience.=20 >=20 > This working group is chartered to specify the information about media > streams from one entity to another entity: >=20 > * Spatial relationships of cameras, displays, microphones, and > Speakers - in relation to each other and to likely positions of > participants >=20 > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker - so that senders and >=20 > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its=20 > received streams >=20 > *Usage of the stream, for example whether the stream is presentation, = or > document camera output >=20 > * Aspect ratio of cameras and displays >=20 > * Which sources a receiver wants to receive. For example, it might = want > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). >=20 >=20 > Information between sources and sinks about media stream capabilities > will be exchanged.=20 >=20 > The working group will define the semantics, syntax, and transport > mechanism necessary for communicating the necessary information. It = will > consider whether the existing signaling mechanisms (e. g., SDP) can be > extended, or another messaging method should be used. =20 >=20 > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream > semantics. =20 >=20 > The focus of this work is on multiple audio and video streams. Other > media types may be considered, however development of methodologies = for > them is not within the scope of this work. >=20 > Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing = non-standards > compliant telepresence systems is not required. >=20 > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster.=20 >=20 > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are important factors for the > working group to consider. The work will closely coordinate with the > appropriate areas and working groups including OPS Area, AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. >=20 > Milestones =20 >=20 > Nov 2010 Submit information draft to IESG on use cases and = requirements >=20 > Nov 2011 Submit standards track specification to IESG indicating > spatial relationships=20 > of screens cameras (including variable field of view and = orientation), > speakers and microphones; and the "usage" of a stream as defined in = the > charter. Semantics, language and transport mechanism will be = specified. >=20 >=20 >=20 > = ------------------------------------------------------------------------ > -------- > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, September 09, 2010 12:31 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence charter version 4 >=20 > Allyn, >=20 > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., = .... > BFCP) can be extended, or another messaging method should be used" >=20 > and=20 >=20 > "This working group is not currently chartered to work on=20 > issues of continuous conference control including: .... floor > control..."=20 >=20 > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. >=20 > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Mon Sep 20 02:17:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC673A690F for ; Mon, 20 Sep 2010 02:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.83 X-Spam-Level: X-Spam-Status: No, score=-4.83 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZOgpyQdcACI for ; Mon, 20 Sep 2010 02:17:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CFB4B3A68AB for ; Mon, 20 Sep 2010 02:17:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b0bae000000f9a-6b-4c9726d883e4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A8.BB.03994.8D6279C4; Mon, 20 Sep 2010 11:18:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 20 Sep 2010 11:18:16 +0200 From: Christer Holmberg To: "'Allyn Romanow (allyn)'" , "Elwell, John" , DISPATCH list Date: Mon, 20 Sep 2010 11:18:15 +0200 Thread-Topic: Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 09:17:55 -0000 Hi, One question for clarification. The text says: "In addition, there is no standardized way to exchange semantic information= about what each media stream represents." Isn't that something RFC 4574 could be used for? Regards, Christer =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Allyn Romanow (allyn) Sent: 15. syyskuuta 2010 20:42 To: Elwell, John; DISPATCH list Subject: [dispatch] Telepresence charter version 5 In keeping with John's good catch, the reference to BFCP has been removed.= =20 This was the only suggested change to the charter. Thanks, Allyn MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - Communi= cation and Correlation of Key Telepresence Attributes for Interoperable Lin= ks MAITAI - Multi-stream Attributes for Improving Telepresence Application = Interoperability TEQUILA - Telepresence Encoding of QUalifiers for Interope= rable Lifelike Applications MOJITO - Multi-stream Orientation for Joining o= f Interoperable Telepresence Operations In the context of this WG, the term telepresence is used in a general manne= r to describe systems that provide high definition, high quality audio/vide= o enabling a "being-there" experience. One example is an immersive telepre= sence system using specially designed and special purpose rooms with multip= le displays permitting life size image reproduction using multiple cameras,= encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another. A major factor in the inability of t= elepresence systems to interwork is that there is no standardized way to de= scribe and negotiate the use of the multiple streams of audio and video tha= t comprise the media flows. In addition, there is no standardized way to ex= change semantic information about what each media stream represents. =20 The WG will create specifications for SIP-based conferencing systems to ena= ble communication of enough information about each media stream so that eac= h receiving system or bridge system can make reasonable decisions about sel= ecting and rendering media streams. This enables systems to make display ch= oices that optimize the "just like being there" experience.=20 This working group is chartered to specify the information about media stre= ams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and Speakers - in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker - so that senders and middleboxes can understand how best to compose streams for receivers, and the receivers will know the characteristics of its received streams *Usage of the stream, for example whether the stream is presentation, or do= cument camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want th= e source for the left camera, or might want the source chosen by VAD (Voice= Activity Detection). Information between sources and sinks about media stream capabilities will = be exchanged.=20 The working group will define the semantics, syntax, and transport mechani= sm necessary for communicating the necessary information. It will consider = whether the existing signaling mechanisms (e. g., SDP) can be extended, or = another messaging method should be used. =20 The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics. =20 The focus of this work is on multiple audio and video streams. Other media= types may be considered, however development of methodologies for them is = not within the scope of this work. Interoperation with SIP and related standards for audio and video is requir= ed. However, backwards compatibility with existing non-standards compliant= telepresence systems is not required. This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster.=20 Reuse of existing protocols and backwards compatibility with SIP-compliant = audio/video endpoints are important factors for the working group to consi= der. The work will closely coordinate with the appropriate areas and workin= g groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones =20 Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG indicating spatial r= elationships of screens cameras (including variable field of view and ori= entation), speakers and microphones; and the "usage" of a stream as defined= in the charter. Semantics, language and transport mechanism will be speci= fied. ------------------------------------------------------------------------ -------- -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, September 09, 2010 12:31 AM To: Allyn Romanow (allyn); DISPATCH list Subject: RE: Telepresence charter version 4 Allyn, Can you explain the following: "It will consider whether the existing signaling mechanisms (e. g., .... BFCP) can be extended, or another messaging method should be used" and=20 "This working group is not currently chartered to work on=20 issues of continuous conference control including: .... floor control..."=20 It is unclear to me how BFCP can be within scope yet floor control is out of scope. John _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gerardmxf@yahoo.co.uk Mon Sep 20 03:05:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A073A69B9 for ; Mon, 20 Sep 2010 03:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5MLwrTYlYIo for ; Mon, 20 Sep 2010 03:05:11 -0700 (PDT) Received: from web24006.mail.ird.yahoo.com (web24006.mail.ird.yahoo.com [87.248.114.93]) by core3.amsl.com (Postfix) with SMTP id B72DF3A688A for ; Mon, 20 Sep 2010 03:05:10 -0700 (PDT) Received: (qmail 97359 invoked by uid 60001); 20 Sep 2010 10:05:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1284977132; bh=whQufuhGA8o0CIHbMDg/dyiKfI40zfewXrQIODLFOJs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BA8hWzXsoy6WMWBrSVhLG+JbhJditlX3zwj7lcz3/YG2oYIbwLfkUyZFMdwzUpTjiLkdEmpClvH/n0FqHH1OiIIeRVn8nvF3w/iK9tL8BDff14WxkLDf89itL+A6SuwSavPYIGUYruQgnCuemc1fpXbb3NqlXNSUex7u7Dz2pik= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Yb3V95GzLwLCM3Wk5HebPb61SFnIkSQVDiLQ99jXROcHYqj8q4WabwEtE7xCogup236LoE05UidoAKNFyZmlBkjoQitWDpRmfuoz2g5NVElhQ7YUmGSbhaF6Esk7PdXiVmQUAdoUi+B5ImEFGHHT3/iOdWQqpwW2DNlxTrwTYbI=; Message-ID: <85928.86133.qm@web24006.mail.ird.yahoo.com> X-YMail-OSG: iju.DiYVM1kKB54Xt02e8U0.BeuhgsBqu5vyy6LODEPmu7H ry.NHXxw2xwXW.T9..7s_4cCEKKD.2GyHwOGESk4mmMIB9Eylx1kZzmJsLSM 6qMe4peIEVxfyJXrWzkpKeQnZ21.NBf5G4JLRcBY.YlHadEQEHUmnXtbaRA2 51AyCIDdzcysqjxk5hxKmgqT6lbQr3Tdtu9n0TFW6M0h7lErYALutciC8_xW .DdSOmNVRl2omlJBx.4a9wDyu9evLkLOSX728jgtyk0wVNu.Vu6BXeJQywRT A7O8tdix9N5hQf3EK0UL9jw536.RbQWE- Received: from [99.113.35.251] by web24006.mail.ird.yahoo.com via HTTP; Mon, 20 Sep 2010 10:05:31 GMT X-Mailer: YahooMailRC/497 YahooMailWebService/0.8.105.279950 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> Date: Mon, 20 Sep 2010 10:05:31 +0000 (GMT) From: Gerard Fernando To: "Allyn Romanow \(allyn\)" , DISPATCH list In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1362688346-1284977131=:86133" Cc: Gerard.M.X.Fernando@zte.com.cn Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 10:05:13 -0000 --0-1362688346-1284977131=:86133 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Allyn, All,=0A =0AI see the statement on interoperability. However, I = would guess that the most =0Aimportant aspect is interoperability with H.3= 23. If it's possible to explicitly =0Astate that in the charter then that c= ould much help with the success of this =0Awork. I view the following reaso= ns for inclusion of such a statement on H.323 =0Ainteroperability:=0A=0A(a)= It ensures that there's no perception of IETF neglecting this aspect of = =0Ainteroperability=0A(b) Bring in companies who have a focus on H.323 into= the IETF activity. My =0Aunderstanding is that many vendors have products = that use the H.323 suite of =0Aprotocols.=0A=0AThanks=0A=0AGerard=0A-------= --=0A=0AGerard Fernando=0AZTE Corporation=0A=0A=0A=0A=0A___________________= _____________=0AFrom: Allyn Romanow (allyn) =0ATo: "Elwell= , John" ; DISPATCH list =0A=0ASent: Wed, 15 September, 2010 10:42:10=0ASubject: [dispatch] Tele= presence charter version 5=0A=0AIn keeping with John's good catch, the refe= rence to BFCP has been=0Aremoved. =0AThis was the only suggested change to = the charter.=0A=0A=0AThanks,=0AAllyn=0A=0A=0A=0A=0A=0A=0AMALT - Multi-strea= m Attributes for Lifelike Telepresence=0ACOCKTAIL - Communication and Corre= lation of Key Telepresence Attributes=0Afor Interoperable Links=0AMAITAI - = Multi-stream Attributes for Improving Telepresence Application=0AInteropera= bility=0ATEQUILA - Telepresence Encoding of QUalifiers for Interoperable Li= felike=0AApplications=0AMOJITO - Multi-stream Orientation for Joining of In= teroperable=0ATelepresence Operations=0A=0A=0AIn the context of this WG, th= e term telepresence is used in a general=0Amanner to describe systems that = provide high definition, high quality=0Aaudio/video enabling a "being-there= " experience. One example is an=0Aimmersive telepresence system using spec= ially designed and special=0Apurpose rooms with multiple displays permittin= g life size image=0Areproduction using multiple cameras, encoders, decoders= , microphones and=0Aloudspeakers.=0A=0ACurrent telepresence systems are bas= ed on open standards such as RTP,=0ASIP, H.264, the H.323 suite, however, t= hey cannot easily interoperate=0Awith each other without operator assistanc= e and expensive additional=0Aequipment which translates from one vendor to = another. A major factor in=0Athe inability of telepresence systems to inter= work is that there is no=0Astandardized way to describe and negotiate the u= se of the multiple=0Astreams of audio and video that comprise the media flo= ws. In addition,=0Athere is no standardized way to exchange semantic inform= ation about what=0Aeach media stream represents. =0A=0AThe WG will create = specifications for SIP-based conferencing systems to=0Aenable communication= of enough information about each media stream so=0Athat each receiving sys= tem or bridge system can make reasonable=0Adecisions about selecting and re= ndering media streams. This enables=0Asystems to make display choices that = optimize the "just like being=0Athere" experience. =0A=0AThis working group= is chartered to specify the information about media=0Astreams from one ent= ity to another entity:=0A=0A* Spatial relationships of cameras, displays, m= icrophones, and=0A Speakers - in relation to each other and to likely posi= tions of=0A participants=0A=0A* Specific characteristics such as viewpoint= , field of view/capture=0A for camera/microphone/display/speaker - so that= senders and=0A=0A middleboxes can understand how best to compose streams = for=0A receivers, and the receivers will know the characteristics of its = =0A received streams=0A=0A*Usage of the stream, for example whether the st= ream is presentation, or=0Adocument camera output=0A=0A* Aspect ratio of ca= meras and displays=0A=0A* Which sources a receiver wants to receive. For e= xample, it might want=0Athe source for the left camera, or might want the s= ource chosen by VAD=0A(Voice Activity Detection).=0A=0A=0AInformation betwe= en sources and sinks about media stream capabilities=0Awill be exchanged. = =0A=0AThe working group will define the semantics, syntax, and transport= =0Amechanism necessary for communicating the necessary information. It will= =0Aconsider whether the existing signaling mechanisms (e. g., SDP) can be= =0Aextended, or another messaging method should be used. =0A=0AThe scope o= f the work includes describing relatively static relations=0Abetween entiti= es (participants and devices). It also includes handling=0Amore dynamic rel= ationships, such as identifying the audio and video=0Astreams for the curre= nt speaker. The scope includes both systems that=0Aprovide a fully immersiv= e experience, and systems that interwork with=0Athem and therefore need to = understand the same multiple stream=0Asemantics. =0A=0AThe focus of this w= ork is on multiple audio and video streams. Other=0Amedia types may be con= sidered, however development of methodologies for=0Athem is not within the = scope of this work.=0A=0AInteroperation with SIP and related standards for = audio and video is=0Arequired. However, backwards compatibility with exist= ing non-standards=0Acompliant telepresence systems is not required.=0A=0ATh= is working group is not currently chartered to work on issues of=0Acontinuo= us conference control including: far end camera control,=0Aindication of fa= st frame update for video codecs or other rapid=0Aswitches, floor control, = conference roster. =0A=0AReuse of existing protocols and backwards compatib= ility with=0ASIP-compliant audio/video endpoints are important factors for= the=0Aworking group to consider. The work will closely coordinate with the= =0Aappropriate areas and working groups including OPS Area, AVT, MMUSIC,=0A= MEDIACTRL, XCON, and SIPCORE.=0A=0AMilestones =0A=0ANov 2010 Submit inform= ation draft to IESG on use cases and requirements=0A=0ANov 2011 Submit stan= dards track specification to IESG indicating=0Aspatial relationships =0Aof= screens cameras (including variable field of view and orientation),=0Asp= eakers and microphones; and the "usage" of a stream as defined in the=0Acha= rter. Semantics, language and transport mechanism will be specified.=0A=0A= =0A=0A---------------------------------------------------------------------= ---=0A--------=0A-----Original Message-----=0AFrom: Elwell, John [mailto:jo= hn.elwell@siemens-enterprise.com] =0ASent: Thursday, September 09, 2010 12:= 31 AM=0ATo: Allyn Romanow (allyn); DISPATCH list=0ASubject: RE: Telepresenc= e charter version 4=0A=0AAllyn,=0A=0ACan you explain the following:=0A"It w= ill consider whether the existing signaling mechanisms (e. g., ....=0ABFCP)= can be extended, or another messaging method should be used"=0A=0Aand =0A= =0A"This working group is not currently chartered to work on =0Aissues of c= ontinuous conference control including: .... floor=0Acontrol..." =0A=0AIt i= s unclear to me how BFCP can be within scope yet floor control is=0Aout of = scope.=0A=0AJohn=0A_______________________________________________=0Adispat= ch mailing list=0Adispatch@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo= /dispatch=0A --0-1362688346-1284977131=:86133 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Allyn, All,
 
I see the statement on interoperabili= ty. However, I would guess that the most important aspect is  interope= rability with H.323. If it's possible to explicitly state that in the chart= er then that could much help with the success of this work. I view the foll= owing reasons for inclusion of such a statement on H.323 interoperability:<= br>
(a) It ensures that there's no perception of IETF neglecting this as= pect of interoperability
(b) Bring in companies who have a focus on H.32= 3 into the IETF activity. My understanding is that many vendors have produc= ts that use the H.323 suite of protocols.

Thanks

Gerard
--= -------

Gerard Fernando
ZTE Corporation

From: Allyn Romanow (allyn) <allyn@cisco.com>
<= span style=3D"font-weight: bold;">To: "Elwell, John" <john.el= well@siemens-enterprise.com>; DISPATCH list <dispatch@ietf.org>Sent: Wed, 15 September, = 2010 10:42:10
Subject: = [dispatch] Telepresence charter version 5

In keeping with Joh= n's good catch, the reference to BFCP has been
removed.
This was the= only suggested change to the charter.


Thanks,
Allyn

<= br>



MALT - Multi-stream Attributes for Lifelike Telepresence=
COCKTAIL - Communication and Correlation of Key Telepresence Attributes=
for Interoperable Links
MAITAI - Multi-stream Attributes for Improvi= ng Telepresence Application
Interoperability
TEQUILA - Telepresence Enc= oding of QUalifiers for Interoperable Lifelike
Applications
MOJITO - = Multi-stream Orientation for Joining of Interoperable
Telepresence Opera= tions


In the context of this WG, the term telepresence is used i= n a general
manner to describe systems that provide high definition, hig= h quality
audio/video enabling a "being-there" experience.  One exa= mple is an
immersive telepresence system using specially designed and sp= ecial
purpose rooms with multiple displays permitting life size imagereproduction using multiple cameras, encoders, decoders, microphones andloudspeakers.

Current telepresence systems are based on open stand= ards such as RTP,
SIP, H.264, the H.323 suite, however, they cannot easi= ly interoperate
with each other without operator assistance and expensiv= e additional
equipment which translates from one vendor to another. A major factor in
the inability of telepresence systems to int= erwork is that there is no
standardized way to describe and negotiate th= e use of the multiple
streams of audio and video that comprise the media= flows. In addition,
there is no standardized way to exchange semantic i= nformation about what
each media stream represents. 

The WG= will create specifications for SIP-based conferencing systems to
enable= communication of enough information about each media stream so
that eac= h receiving system or bridge system can make reasonable
decisions about = selecting and rendering media streams. This enables
systems to make disp= lay choices that optimize the "just like being
there" experience.
This working group is chartered to specify the information about mediastreams from one entity to another entity:

* Spatial relationships = of cameras, displays, microphones, and
  Speakers - in relation to each other and to likely positions of
  participants
* Specific characteristics such as viewpoint, field of view/capture  for camera/microphone/display/speaker - so that senders and
  middleboxes can understand how best to compose streams for
 = ; receivers, and the receivers will know the characteristics of its
&nb= sp; received streams

*Usage of the stream, for example whether the s= tream is presentation, or
document camera output

* Aspect ratio o= f cameras and displays

* Which sources a receiver wants to receive.&= nbsp; For example, it might want
the source for the left camera, or migh= t want the source chosen by VAD
(Voice Activity Detection).


I= nformation between sources and sinks about media stream capabilities
wil= l be exchanged.

The working group will define the semantics, syntax= ,  and transport
mechanism necessary for communicating the necessary information. It will
consider whether the existing signaling = mechanisms (e. g., SDP) can be
extended, or another messaging method sho= uld be used. 

The scope of the work includes describing relati= vely static relations
between entities (participants and devices). It al= so includes handling
more dynamic relationships, such as identifying the= audio and video
streams for the current speaker. The scope includes bot= h systems that
provide a fully immersive experience, and systems that in= terwork with
them and therefore need to understand the same multiple str= eam
semantics. 

The focus of this work is on multiple audio= and video streams.  Other
media types may be considered, however d= evelopment of methodologies for
them is not within the scope of this wor= k.

Interoperation with SIP and related standards for audio and video= is
required.  However, backwards compatibility with existing non-standards
compliant telepresence systems is not required.<= br>
This working group is not currently chartered to work on issues ofcontinuous conference control including: far end camera control,
indic= ation of fast frame update for video codecs or other rapid
switches, flo= or control, conference roster.

Reuse of existing protocols and back= wards compatibility with
SIP-compliant audio/video endpoints  are i= mportant factors for the
working group to consider. The work will closel= y coordinate with the
appropriate areas and working groups including OPS= Area, AVT, MMUSIC,
MEDIACTRL, XCON, and SIPCORE.

Milestones&nbs= p;

Nov 2010 Submit information draft to IESG on use cases and requ= irements

Nov 2011 Submit standards track specification to IESG = indicating
spatial relationships
of  screens  cameras (in= cluding variable field of view and orientation),
speakers and microphones; and the "usage" of a stream as defined in the
charter.&nbs= p; Semantics, language and transport mechanism will be specified.


---------------------------------------------------------------------= ---
--------
-----Original Message-----
From: Elwell, John [mailto= :john.elwell@siemens-enterprise.com] <= br>Sent: Thursday, September 09, 2010 12:31 AM
To: Allyn Romanow (allyn)= ; DISPATCH list
Subject: RE: Telepresence charter version 4

Allyn= ,

Can you explain the following:
"It will consider whether the ex= isting signaling mechanisms (e. g., ....
BFCP) can be extended, or anoth= er messaging method should be used"

and

"This working group = is not currently chartered to work on
issues of continuous conference c= ontrol including: .... floor
control..."

It is unclear to me how BFCP can be within scope yet floor control is
out of scope.

= John
_______________________________________________
dispatch mailing= list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/di= spatch
=0A
--0-1362688346-1284977131=:86133-- From peter.musgrave@magorcorp.com Mon Sep 20 03:37:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5BD3A6A3E for ; Mon, 20 Sep 2010 03:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgN+P-43niOV for ; Mon, 20 Sep 2010 03:37:06 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 0EC3C3A6A44 for ; Mon, 20 Sep 2010 03:37:00 -0700 (PDT) Received: by qyk9 with SMTP id 9so4352520qyk.10 for ; Mon, 20 Sep 2010 03:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.2.134 with SMTP id 6mr2840883qaj.101.1284979040031; Mon, 20 Sep 2010 03:37:20 -0700 (PDT) Received: by 10.229.80.21 with HTTP; Mon, 20 Sep 2010 03:37:19 -0700 (PDT) In-Reply-To: <85928.86133.qm@web24006.mail.ird.yahoo.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <85928.86133.qm@web24006.mail.ird.yahoo.com> Date: Mon, 20 Sep 2010 06:37:19 -0400 Message-ID: From: Peter Musgrave To: Gerard Fernando Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list , Gerard.M.X.Fernando@zte.com.cn Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 10:37:09 -0000 Hi, I can understand the motivation for that but I think it greatly increases the scope - to the point where I think a separate WG is called for. I would suggest we get interoperability between systems which at least have SIP in common and then see if the community has interest/commitment to extending it to H.323 ina new WG. Regards Peter Musgrave On Mon, Sep 20, 2010 at 6:05 AM, Gerard Fernando wr= ote: > Dear Allyn, All, > > I see the statement on interoperability. However, I would guess that the > most important aspect is=A0 interoperability with H.323. If it's possible= to > explicitly state that in the charter then that could much help with the > success of this work. I view the following reasons for inclusion of such = a > statement on H.323 interoperability: > > (a) It ensures that there's no perception of IETF neglecting this aspect = of > interoperability > (b) Bring in companies who have a focus on H.323 into the IETF activity. = My > understanding is that many vendors have products that use the H.323 suite= of > protocols. > > Thanks > > Gerard > --------- > > Gerard Fernando > ZTE Corporation > > ________________________________ > From: Allyn Romanow (allyn) > To: "Elwell, John" ; DISPATCH list > > Sent: Wed, 15 September, 2010 10:42:10 > Subject: [dispatch] Telepresence charter version 5 > > In keeping with John's good catch, the reference to BFCP has been > removed. > This was the only suggested change to the charter. > > > Thanks, > Allyn > > > > > > > MALT - Multi-stream Attributes for Lifelike Telepresence > COCKTAIL - Communication and Correlation of Key Telepresence Attributes > for Interoperable Links > MAITAI - Multi-stream Attributes for Improving Telepresence Application > Interoperability > TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike > Applications > MOJITO - Multi-stream Orientation for Joining of Interoperable > Telepresence Operations > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience.=A0 One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders, microphones and > loudspeakers. > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor in > the inability of telepresence systems to interwork is that there is no > standardized way to describe and negotiate the use of the multiple > streams of audio and video that comprise the media flows. In addition, > there is no standardized way to exchange semantic information about what > each media stream represents. > > The WG will create specifications for SIP-based conferencing systems to > enable communication of enough information about each media stream so > that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience. > > This working group is chartered to specify the information about media > streams from one entity to another entity: > > * Spatial relationships of cameras, displays, microphones, and > =A0 Speakers - in relation to each other and to likely positions of > =A0 participants > > * Specific characteristics such as viewpoint, field of view/capture > =A0 for camera/microphone/display/speaker - so that senders and > > =A0 middleboxes can understand how best to compose streams for > =A0 receivers, and the receivers will know the characteristics of its > =A0 received streams > > *Usage of the stream, for example whether the stream is presentation, or > document camera output > > * Aspect ratio of cameras and displays > > * Which sources a receiver wants to receive.=A0 For example, it might wan= t > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > > Information between sources and sinks about media stream capabilities > will be exchanged. > > The working group will define the semantics, syntax,=A0 and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (e. g., SDP) can be > extended, or another messaging method should be used. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream > semantics. > > The focus of this work is on multiple audio and video streams.=A0 Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. > > Interoperation with SIP and related standards for audio and video is > required.=A0 However, backwards compatibility with existing non-standards > compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. > > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints=A0 are important factors for the > working group to consider. The work will closely coordinate with the > appropriate areas and working groups including OPS Area, AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > > Nov 2011 Submit standards track specification to IESG=A0 indicating > spatial relationships > of=A0 screens=A0 cameras (including variable field of view and orientatio= n), > speakers and microphones; and the "usage" of a stream as defined in the > charter.=A0 Semantics, language and transport mechanism will be specified= . > > > > ------------------------------------------------------------------------ > -------- > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, September 09, 2010 12:31 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence charter version 4 > > Allyn, > > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., .... > BFCP) can be extended, or another messaging method should be used" > > and > > "This working group is not currently chartered to work on > issues of continuous conference control including: .... floor > control..." > > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From stephen.botzko@gmail.com Mon Sep 20 03:39:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55393A6A49 for ; Mon, 20 Sep 2010 03:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7Uf8hrIw8Un for ; Mon, 20 Sep 2010 03:38:01 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B77FD3A6A4B for ; Mon, 20 Sep 2010 03:37:33 -0700 (PDT) Received: by qwc9 with SMTP id 9so3795066qwc.31 for ; Mon, 20 Sep 2010 03:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5oZyk03I9mcoFqx2T9FJzsUCRfNcGv61k8ILELjzCB8=; b=ZCYAJvWVeo1TW6+QPF4uKu6zIdhJZcsZFki0bu3ShPdznzTDGn7Nn81lrxrH4jGuz+ CB7ULRoxxJBUq+J8VSSNSv+l4VEEjASu7ehiTnhnkyCypD5kpacuxOwoWqJeLVeFWDrt 1dTmkyjhtJTGiY+WSJY4b6zVs5mu96hck+Dac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Uo3Xz6gJUQ8OFDjD27GNgQaaCZSDeW3LSrrXpaYC3YNT0sgVpG5ethFjtTVeRlVf8v nqIijfzdNfFxb/PAFa7Ip/RTXcAPwtjAVk4oW8pGWOcqeJ3UqbebDoCVnUtCfh44ktDl wz1PBztBZcheJg6mjWNNj1ROjSxmuXQrA8MX0= MIME-Version: 1.0 Received: by 10.224.60.205 with SMTP id q13mr5637781qah.353.1284979074973; Mon, 20 Sep 2010 03:37:54 -0700 (PDT) Received: by 10.229.5.8 with HTTP; Mon, 20 Sep 2010 03:37:54 -0700 (PDT) In-Reply-To: <85928.86133.qm@web24006.mail.ird.yahoo.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <85928.86133.qm@web24006.mail.ird.yahoo.com> Date: Mon, 20 Sep 2010 06:37:54 -0400 Message-ID: From: Stephen Botzko To: Gerard Fernando Content-Type: multipart/alternative; boundary=0015175caae44ebfbb0490ae81d6 Cc: DISPATCH list , Gerard.M.X.Fernando@zte.com.cn Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 10:39:16 -0000 --0015175caae44ebfbb0490ae81d6 Content-Type: text/plain; charset=ISO-8859-1 Hi Gerard, IMHO the contributing members in ITU-T Q5/16 and the IETF work are already well aware of the need to maintain H.323/SIP interoperability. However, as you know, H.323 has no signaling for telepresence either. It seems problematic to create a charter mandate to interoperate with H.323 multistreams, since there is no way to assure this can be done until the ITU-T consents such signaling. So while I agree that H.323/SIP telepresence interoperability through non-transcoding gateways is a desirable outcome, I think it is best to leave this out of the charter. Regards, Stephen Botzko On Mon, Sep 20, 2010 at 6:05 AM, Gerard Fernando wrote: > Dear Allyn, All, > > I see the statement on interoperability. However, I would guess that the > most important aspect is interoperability with H.323. If it's possible to > explicitly state that in the charter then that could much help with the > success of this work. I view the following reasons for inclusion of such a > statement on H.323 interoperability: > > (a) It ensures that there's no perception of IETF neglecting this aspect of > interoperability > (b) Bring in companies who have a focus on H.323 into the IETF activity. My > understanding is that many vendors have products that use the H.323 suite of > protocols. > > Thanks > > Gerard > --------- > > Gerard Fernando > ZTE Corporation > > ------------------------------ > *From:* Allyn Romanow (allyn) > *To:* "Elwell, John" ; DISPATCH list < > dispatch@ietf.org> > *Sent:* Wed, 15 September, 2010 10:42:10 > > *Subject:* [dispatch] Telepresence charter version 5 > > In keeping with John's good catch, the reference to BFCP has been > removed. > This was the only suggested change to the charter. > > > Thanks, > Allyn > > > > > > > MALT - Multi-stream Attributes for Lifelike Telepresence > COCKTAIL - Communication and Correlation of Key Telepresence Attributes > for Interoperable Links > MAITAI - Multi-stream Attributes for Improving Telepresence Application > Interoperability > TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike > Applications > MOJITO - Multi-stream Orientation for Joining of Interoperable > Telepresence Operations > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience. One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders, microphones and > loudspeakers. > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor in > the inability of telepresence systems to interwork is that there is no > standardized way to describe and negotiate the use of the multiple > streams of audio and video that comprise the media flows. In addition, > there is no standardized way to exchange semantic information about what > each media stream represents. > > The WG will create specifications for SIP-based conferencing systems to > enable communication of enough information about each media stream so > that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience. > > This working group is chartered to specify the information about media > streams from one entity to another entity: > > * Spatial relationships of cameras, displays, microphones, and > Speakers - in relation to each other and to likely positions of > participants > > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker - so that senders and > > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its > received streams > > *Usage of the stream, for example whether the stream is presentation, or > document camera output > > * Aspect ratio of cameras and displays > > * Which sources a receiver wants to receive. For example, it might want > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > > Information between sources and sinks about media stream capabilities > will be exchanged. > > The working group will define the semantics, syntax, and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (e. g., SDP) can be > extended, or another messaging method should be used. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream > semantics. > > The focus of this work is on multiple audio and video streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. > > Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing non-standards > compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. > > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are important factors for the > working group to consider. The work will closely coordinate with the > appropriate areas and working groups including OPS Area, AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > > Nov 2011 Submit standards track specification to IESG indicating > spatial relationships > of screens cameras (including variable field of view and orientation), > speakers and microphones; and the "usage" of a stream as defined in the > charter. Semantics, language and transport mechanism will be specified. > > > > ------------------------------------------------------------------------ > -------- > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, September 09, 2010 12:31 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence charter version 4 > > Allyn, > > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., .... > BFCP) can be extended, or another messaging method should be used" > > and > > "This working group is not currently chartered to work on > issues of continuous conference control including: .... floor > control..." > > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --0015175caae44ebfbb0490ae81d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gerard,

IMHO the contributing members in ITU-T Q5/16 and the IETF work are already well aware of the need to maintain H.323/SIP interoperability.

Howe= ver, as you know, H.323 has no signaling for telepresence either.=A0 It see= ms problematic to create a charter mandate to interoperate with H.323 multi= streams, since there is no way to assure this can be done until the ITU-T c= onsents such signaling.=A0

So while I agree that H.323/SIP telepresence interoperability through n= on-transcoding gateways is a desirable outcome, I think it is best to leave= this out of the charter.=A0

Regards,
Stephen Botzko





On Mon, Sep 20, 2010 at 6:05 AM, Ger= ard Fernando <gerardmxf@yahoo.co.uk> wrote:
Dear Allyn, All,
=A0
I see the statement on interoperability.= However, I would guess that the most important aspect is=A0 interoperabili= ty with H.323. If it's possible to explicitly state that in the charter= then that could much help with the success of this work. I view the follow= ing reasons for inclusion of such a statement on H.323 interoperability:
(a) It ensures that there's no perception of IETF neglecting this a= spect of interoperability
(b) Bring in companies who have a focus on H.3= 23 into the IETF activity. My understanding is that many vendors have produ= cts that use the H.323 suite of protocols.

Thanks

Gerard
---------

Gerard Fernando
ZTE Corpora= tion

From: Allyn Romanow (allyn) <allyn@cisco.com>
To: "Elwell, John" <john.elwel= l@siemens-enterprise.com>; DISPATCH list <dispatch@ietf.org>
Sent: Wed, 15 September, 2= 010 10:42:10

Sub= ject: [dispatch] Telepresence charter version 5
=

In keeping with John's good catch, the= reference to BFCP has been
removed.
This was the only suggested cha= nge to the charter.


Thanks,
Allyn






MALT - Multi-stream Attributes for Lifelike Telepresence
COCKTAIL - Comm= unication and Correlation of Key Telepresence Attributes
for Interoperab= le Links
MAITAI - Multi-stream Attributes for Improving Telepresence Application
Interoperability
TEQUILA - Telepresence Enc= oding of QUalifiers for Interoperable Lifelike
Applications
MOJITO - = Multi-stream Orientation for Joining of Interoperable
Telepresence Opera= tions


In the context of this WG, the term telepresence is used in a gener= al
manner to describe systems that provide high definition, high quality=
audio/video enabling a "being-there" experience.=A0 One examp= le is an
immersive telepresence system using specially designed and special
purpo= se rooms with multiple displays permitting life size image
reproduction = using multiple cameras, encoders, decoders, microphones and
loudspeakers= .

Current telepresence systems are based on open standards such as RTP,SIP, H.264, the H.323 suite, however, they cannot easily interoperate
= with each other without operator assistance and expensive additional
equipment which translates from one vendor to another. A major factor in
the inability of telepresence systems to int= erwork is that there is no
standardized way to describe and negotiate th= e use of the multiple
streams of audio and video that comprise the media= flows. In addition,
there is no standardized way to exchange semantic information about whateach media stream represents.=A0

The WG will create specifications= for SIP-based conferencing systems to
enable communication of enough in= formation about each media stream so
that each receiving system or bridge system can make reasonable
decision= s about selecting and rendering media streams. This enables
systems to m= ake display choices that optimize the "just like being
there" = experience.

This working group is chartered to specify the information about media<= br>streams from one entity to another entity:

* Spatial relationship= s of cameras, displays, microphones, and
=A0 Speakers - in relation to each other and to likely positions of
=A0 participants
<= br>* Specific characteristics such as viewpoint, field of view/capture
= =A0 for camera/microphone/display/speaker - so that senders and

=A0 = middleboxes can understand how best to compose streams for
=A0 receivers, and the receivers will know the characteristics of its
= =A0 received streams

*Usage of the stream, for example whether the s= tream is presentation, or
document camera output

* Aspect ratio o= f cameras and displays

* Which sources a receiver wants to receive.=A0 For example, it might w= ant
the source for the left camera, or might want the source chosen by V= AD
(Voice Activity Detection).


Information between sources an= d sinks about media stream capabilities
will be exchanged.

The working group will define the semantics, syn= tax,=A0 and transport
mechanism necessary for communicating the necessary information. It will
consider whether the existing signaling = mechanisms (e. g., SDP) can be
extended, or another messaging method sho= uld be used.=A0

The scope of the work includes describing relativel= y static relations
between entities (participants and devices). It also includes handling
m= ore dynamic relationships, such as identifying the audio and video
strea= ms for the current speaker. The scope includes both systems that
provide= a fully immersive experience, and systems that interwork with
them and therefore need to understand the same multiple stream
semantics= .=A0

The focus of this work is on multiple audio and video streams.= =A0 Other
media types may be considered, however development of methodol= ogies for
them is not within the scope of this work.

Interoperation with SIP a= nd related standards for audio and video is
required.=A0 However, backwa= rds compatibility with existing non-standards
compliant telepresence systems is not required.<= br>
This working group is not currently chartered to work on issues ofcontinuous conference control including: far end camera control,
indication of fast frame update for video codecs or other rapid
switches= , floor control, conference roster.

Reuse of existing protocols and= backwards compatibility with
SIP-compliant audio/video endpoints=A0 are= important factors for the
working group to consider. The work will closely coordinate with the
app= ropriate areas and working groups including OPS Area, AVT, MMUSIC,
MEDIA= CTRL, XCON, and SIPCORE.

Milestones=A0

Nov 2010 Submit inf= ormation draft to IESG on use cases and requirements

Nov 2011 Submit standards track specification to IESG=A0 indicating
= spatial relationships
of=A0 screens=A0 cameras (including variable fiel= d of view and orientation),
speakers and microphones; and the "usage" of a stream as defined in the
ch= arter.=A0 Semantics, language and transport mechanism will be specified.


--------------------------------------------------------------= ----------
--------
-----Original Message-----
From: Elwell, John [mailto:john.elwe= ll@siemens-enterprise.com]
Sent: Thursday, September 09, 2010 12:31= AM
To: Allyn Romanow (allyn); DISPATCH list
Subject: RE: Telepresence chart= er version 4

Allyn,

Can you explain the following:
"I= t will consider whether the existing signaling mechanisms (e. g., ....
BFCP) can be extended, or another messaging method should be used"
=
and

"This working group is not currently chartered to work= on
issues of continuous conference control including: .... floor
control..."

It is unclear to me how BFCP can be within scope yet floor control is
out of scope.

= John
_______________________________________________
dispatch mailing= list
dispatch@ie= tf.org
https://www.ietf.org/mailman/listinfo/dispatch
<= /div>

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


--0015175caae44ebfbb0490ae81d6-- From eckelcu@cisco.com Mon Sep 20 12:29:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5303A63EC for ; Mon, 20 Sep 2010 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT+4KB7DtVuE for ; Mon, 20 Sep 2010 12:29:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 45DF93A686B for ; Mon, 20 Sep 2010 12:29:11 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFNTl0yrR7Ht/2dsb2JhbACiG3Gma5wYhUEEhE6Ibg X-IronPort-AV: E=Sophos;i="4.56,395,1280707200"; d="scan'208";a="189242448" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Sep 2010 19:29:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8KJTZCA025067; Mon, 20 Sep 2010 19:29:35 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 12:29:35 -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 Date: Mon, 20 Sep 2010 12:29:33 -0700 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoAAVWaHg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> From: "Charles Eckel (eckelcu)" To: "Christer Holmberg" , "Allyn Romanow (allyn)" , "Elwell, John" , "DISPATCH list" X-OriginalArrivalTime: 20 Sep 2010 19:29:35.0029 (UTC) FILETIME=[283C2650:01CB58FA] Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 19:29:12 -0000 Hi Christer, I think RFC label attribute may be useful; however, we would need to establish and register set of tokens and the semantics of those tokens. Once we get to the actual design, that would be worth considering. Without addition specification, I think you would have proprietary sets of labels being used at best. Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, September 20, 2010 2:18 AM > To: Allyn Romanow (allyn); Elwell, John; DISPATCH list > Subject: Re: [dispatch] Telepresence charter version 5 >=20 >=20 > Hi, >=20 > One question for clarification. The text says: >=20 > "In addition, there is no standardized way to exchange semantic information about what each media > stream represents." >=20 > Isn't that something RFC 4574 could be used for? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) > Sent: 15. syyskuuta 2010 20:42 > To: Elwell, John; DISPATCH list > Subject: [dispatch] Telepresence charter version 5 >=20 > In keeping with John's good catch, the reference to BFCP has been removed. > This was the only suggested change to the charter. >=20 >=20 > Thanks, > Allyn >=20 >=20 >=20 >=20 >=20 >=20 > MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - Communication and Correlation of > Key Telepresence Attributes for Interoperable Links MAITAI - Multi-stream Attributes for Improving > Telepresence Application Interoperability TEQUILA - Telepresence Encoding of QUalifiers for > Interoperable Lifelike Applications MOJITO - Multi-stream Orientation for Joining of Interoperable > Telepresence Operations >=20 >=20 > In the context of this WG, the term telepresence is used in a general manner to describe systems that > provide high definition, high quality audio/video enabling a "being-there" experience. One example is > an immersive telepresence system using specially designed and special purpose rooms with multiple > displays permitting life size image reproduction using multiple cameras, encoders, decoders, > microphones and loudspeakers. >=20 > Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, > however, they cannot easily interoperate with each other without operator assistance and expensive > additional equipment which translates from one vendor to another. A major factor in the inability of > telepresence systems to interwork is that there is no standardized way to describe and negotiate the > use of the multiple streams of audio and video that comprise the media flows. In addition, there is no > standardized way to exchange semantic information about what each media stream represents. >=20 > The WG will create specifications for SIP-based conferencing systems to enable communication of enough > information about each media stream so that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables systems to make display choices > that optimize the "just like being there" experience. >=20 > This working group is chartered to specify the information about media streams from one entity to > another entity: >=20 > * Spatial relationships of cameras, displays, microphones, and > Speakers - in relation to each other and to likely positions of > participants >=20 > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker - so that senders and >=20 > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its > received streams >=20 > *Usage of the stream, for example whether the stream is presentation, or document camera output >=20 > * Aspect ratio of cameras and displays >=20 > * Which sources a receiver wants to receive. For example, it might want the source for the left > camera, or might want the source chosen by VAD (Voice Activity Detection). >=20 >=20 > Information between sources and sinks about media stream capabilities will be exchanged. >=20 > The working group will define the semantics, syntax, and transport mechanism necessary for > communicating the necessary information. It will consider whether the existing signaling mechanisms > (e. g., SDP) can be extended, or another messaging method should be used. >=20 > The scope of the work includes describing relatively static relations between entities (participants > and devices). It also includes handling more dynamic relationships, such as identifying the audio and > video streams for the current speaker. The scope includes both systems that provide a fully immersive > experience, and systems that interwork with them and therefore need to understand the same multiple > stream semantics. >=20 > The focus of this work is on multiple audio and video streams. Other media types may be considered, > however development of methodologies for them is not within the scope of this work. >=20 > Interoperation with SIP and related standards for audio and video is required. However, backwards > compatibility with existing non-standards compliant telepresence systems is not required. >=20 > This working group is not currently chartered to work on issues of continuous conference control > including: far end camera control, indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. >=20 > Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are > important factors for the working group to consider. The work will closely coordinate with the > appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >=20 > Milestones >=20 > Nov 2010 Submit information draft to IESG on use cases and requirements >=20 > Nov 2011 Submit standards track specification to IESG indicating spatial relationships of screens > cameras (including variable field of view and orientation), speakers and microphones; and the "usage" > of a stream as defined in the charter. Semantics, language and transport mechanism will be specified. >=20 >=20 >=20 > ------------------------------------------------------------------------ > -------- > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, September 09, 2010 12:31 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence charter version 4 >=20 > Allyn, >=20 > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., .... > BFCP) can be extended, or another messaging method should be used" >=20 > and >=20 > "This working group is not currently chartered to work on > issues of continuous conference control including: .... floor > control..." >=20 > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. >=20 > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From allyn@cisco.com Mon Sep 20 20:49:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73113A68CD for ; Mon, 20 Sep 2010 20:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POglOe10FHoA for ; Mon, 20 Sep 2010 20:49:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 917723A6844 for ; Mon, 20 Sep 2010 20:49:15 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM/Hl0yrRN+K/2dsb2JhbACBRYFXniVicapNigeSTYROcwSETohuglw X-IronPort-AV: E=Sophos;i="4.56,396,1280707200"; d="scan'208,217";a="280011177" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2010 03:49:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o8L3ndbM022811; Tue, 21 Sep 2010 03:49:39 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 20:49:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB5940.039543E0" Date: Mon, 20 Sep 2010 20:49:36 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1CCB@xmb-sjc-221.amer.cisco.com> In-Reply-To: <85928.86133.qm@web24006.mail.ird.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: ActYq183KxJxYhhfSsSPH63YkWKbLwAkzAhA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <85928.86133.qm@web24006.mail.ird.yahoo.com> From: "Allyn Romanow (allyn)" To: "Gerard Fernando" , "DISPATCH list" X-OriginalArrivalTime: 21 Sep 2010 03:49:39.0118 (UTC) FILETIME=[0410CCE0:01CB5940] Cc: Gerard.M.X.Fernando@zte.com.cn Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 03:49:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB5940.039543E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2VyYXJkLA0KDQpJ4oCZbSBpbiBhZ3JlZW1lbnQgd2l0aCBQZXRlciBhbmQgU3RldmXigJlz IG5vdGVzLg0KDQogDQoNCkFzIHlvdSBtYXkga25vdyB0aGUgSVRVIGhhcyByZWNlbnRseSBjaGFy dGVyZWQgYSBncm91cCB0byB3b3JrIG9uIFRlbGVwcmVzZW5jZS4gV2UgYXJlIGhvcGluZyB0aGF0 IHRoZXkgd2lsbCByZWZlcmVuY2UgdGhlIHdvcmsgd2UgZG8gZm9yIGhhbmRsaW5nIG11bHRpcGxl IHN0cmVhbXMuDQoNCiANCg0KSU1UQywgdGhlIEludGVybmF0aW9uYWwgTXVsdGltZWRpYSBUZWxl Y29tbXVuaWNhdGlvbnMgQ29uc29ydGl1bSwgYW4gaW5kdXN0cnkgZ3JvdXAsIGhhcyBiZWVuIGxv b2tpbmcgYXQgc3BlY2lmaWMgYXNwZWN0cyBvZiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gU0lQ IGFuZCBILjMyMyAgYW5kIG1hZGUgc29tZSByZWNvbW1lbmRhdGlvbnMuIFlvdSBtYXkgd2FudCB0 byBzZWUgd2hhdCB5b3UgdGhpbmsgb2YgdGhlIHdvcmsgdGhleSBoYXZlIGRvbmUuIA0KDQogDQoN CkFzIG90aGVycyBoYXZlIHNhaWQsIHRoZSBjaGFydGVyIGhlcmUgaXMgZm9jdXNlZCBzcGVjaWZp Y2FsbHkgb24gc3BlY2lmeWluZyBhIGNvbW1vbiBhcHByb2FjaCB0byBoYW5kbGluZyBtdWx0aXBs ZSBzdHJlYW1zLCByYXRoZXIgdGhhbiB0YWtpbmcgdXAgYSB3aWRlciByYW5nZSBvZiB0ZWxlcHJl c2VuY2UgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMuDQoNCiANCg0KQmVzdCByZWdhcmRzLA0KDQpB bGx5bg0KDQogDQoNCkZyb206IEdlcmFyZCBGZXJuYW5kbyBbbWFpbHRvOmdlcmFyZG14ZkB5YWhv by5jby51a10gDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMCwgMjAxMCAzOjA2IEFNDQpUbzog QWxseW4gUm9tYW5vdyAoYWxseW4pOyBESVNQQVRDSCBsaXN0DQpDYzogR2VyYXJkIEZlcm5hbmRv OyBHZXJhcmQuTS5YLkZlcm5hbmRvQHp0ZS5jb20uY24NClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hd IFRlbGVwcmVzZW5jZSBjaGFydGVyIHZlcnNpb24gNQ0KDQogDQoNCkRlYXIgQWxseW4sIEFsbCwN CiANCkkgc2VlIHRoZSBzdGF0ZW1lbnQgb24gaW50ZXJvcGVyYWJpbGl0eS4gSG93ZXZlciwgSSB3 b3VsZCBndWVzcyB0aGF0IHRoZSBtb3N0IGltcG9ydGFudCBhc3BlY3QgaXMgIGludGVyb3BlcmFi aWxpdHkgd2l0aCBILjMyMy4gSWYgaXQncyBwb3NzaWJsZSB0byBleHBsaWNpdGx5IHN0YXRlIHRo YXQgaW4gdGhlIGNoYXJ0ZXIgdGhlbiB0aGF0IGNvdWxkIG11Y2ggaGVscCB3aXRoIHRoZSBzdWNj ZXNzIG9mIHRoaXMgd29yay4gSSB2aWV3IHRoZSBmb2xsb3dpbmcgcmVhc29ucyBmb3IgaW5jbHVz aW9uIG9mIHN1Y2ggYSBzdGF0ZW1lbnQgb24gSC4zMjMgaW50ZXJvcGVyYWJpbGl0eToNCg0KKGEp IEl0IGVuc3VyZXMgdGhhdCB0aGVyZSdzIG5vIHBlcmNlcHRpb24gb2YgSUVURiBuZWdsZWN0aW5n IHRoaXMgYXNwZWN0IG9mIGludGVyb3BlcmFiaWxpdHkNCihiKSBCcmluZyBpbiBjb21wYW5pZXMg d2hvIGhhdmUgYSBmb2N1cyBvbiBILjMyMyBpbnRvIHRoZSBJRVRGIGFjdGl2aXR5LiBNeSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgbWFueSB2ZW5kb3JzIGhhdmUgcHJvZHVjdHMgdGhhdCB1c2UgdGhl IEguMzIzIHN1aXRlIG9mIHByb3RvY29scy4NCg0KVGhhbmtzDQoNCkdlcmFyZA0KLS0tLS0tLS0t DQoNCkdlcmFyZCBGZXJuYW5kbw0KWlRFIENvcnBvcmF0aW9uDQoNCiANCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogQWxseW4gUm9tYW5vdyAoYWxseW4pIDxhbGx5 bkBjaXNjby5jb20+DQpUbzogIkVsd2VsbCwgSm9obiIgPGpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50 ZXJwcmlzZS5jb20+OyBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz4NClNlbnQ6IFdl ZCwgMTUgU2VwdGVtYmVyLCAyMDEwIDEwOjQyOjEwDQpTdWJqZWN0OiBbZGlzcGF0Y2hdIFRlbGVw cmVzZW5jZSBjaGFydGVyIHZlcnNpb24gNQ0KDQpJbiBrZWVwaW5nIHdpdGggSm9obidzIGdvb2Qg Y2F0Y2gsIHRoZSByZWZlcmVuY2UgdG8gQkZDUCBoYXMgYmVlbg0KcmVtb3ZlZC4gDQpUaGlzIHdh cyB0aGUgb25seSBzdWdnZXN0ZWQgY2hhbmdlIHRvIHRoZSBjaGFydGVyLg0KDQoNClRoYW5rcywN CkFsbHluDQoNCg0KDQoNCg0KDQpNQUxUIC0gTXVsdGktc3RyZWFtIEF0dHJpYnV0ZXMgZm9yIExp ZmVsaWtlIFRlbGVwcmVzZW5jZQ0KQ09DS1RBSUwgLSBDb21tdW5pY2F0aW9uIGFuZCBDb3JyZWxh dGlvbiBvZiBLZXkgVGVsZXByZXNlbmNlIEF0dHJpYnV0ZXMNCmZvciBJbnRlcm9wZXJhYmxlIExp bmtzDQpNQUlUQUkgLSBNdWx0aS1zdHJlYW0gQXR0cmlidXRlcyBmb3IgSW1wcm92aW5nIFRlbGVw cmVzZW5jZSBBcHBsaWNhdGlvbg0KSW50ZXJvcGVyYWJpbGl0eQ0KVEVRVUlMQSAtIFRlbGVwcmVz ZW5jZSBFbmNvZGluZyBvZiBRVWFsaWZpZXJzIGZvciBJbnRlcm9wZXJhYmxlIExpZmVsaWtlDQpB cHBsaWNhdGlvbnMNCk1PSklUTyAtIE11bHRpLXN0cmVhbSBPcmllbnRhdGlvbiBmb3IgSm9pbmlu ZyBvZiBJbnRlcm9wZXJhYmxlDQpUZWxlcHJlc2VuY2UgT3BlcmF0aW9ucw0KDQoNCkluIHRoZSBj b250ZXh0IG9mIHRoaXMgV0csIHRoZSB0ZXJtIHRlbGVwcmVzZW5jZSBpcyB1c2VkIGluIGEgZ2Vu ZXJhbA0KbWFubmVyIHRvIGRlc2NyaWJlIHN5c3RlbXMgdGhhdCBwcm92aWRlIGhpZ2ggZGVmaW5p dGlvbiwgaGlnaCBxdWFsaXR5DQphdWRpby92aWRlbyBlbmFibGluZyBhICJiZWluZy10aGVyZSIg ZXhwZXJpZW5jZS4gIE9uZSBleGFtcGxlIGlzIGFuDQppbW1lcnNpdmUgdGVsZXByZXNlbmNlIHN5 c3RlbSB1c2luZyBzcGVjaWFsbHkgZGVzaWduZWQgYW5kIHNwZWNpYWwNCnB1cnBvc2Ugcm9vbXMg d2l0aCBtdWx0aXBsZSBkaXNwbGF5cyBwZXJtaXR0aW5nIGxpZmUgc2l6ZSBpbWFnZQ0KcmVwcm9k dWN0aW9uIHVzaW5nIG11bHRpcGxlIGNhbWVyYXMsIGVuY29kZXJzLCBkZWNvZGVycywgbWljcm9w aG9uZXMgYW5kDQpsb3Vkc3BlYWtlcnMuDQoNCkN1cnJlbnQgdGVsZXByZXNlbmNlIHN5c3RlbXMg YXJlIGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzIHN1Y2ggYXMgUlRQLA0KU0lQLCBILjI2NCwgdGhl IEguMzIzIHN1aXRlLCBob3dldmVyLCB0aGV5IGNhbm5vdCBlYXNpbHkgaW50ZXJvcGVyYXRlDQp3 aXRoIGVhY2ggb3RoZXIgd2l0aG91dCBvcGVyYXRvciBhc3Npc3RhbmNlIGFuZCBleHBlbnNpdmUg YWRkaXRpb25hbA0KZXF1aXBtZW50IHdoaWNoIHRyYW5zbGF0ZXMgZnJvbSBvbmUgdmVuZG9yIHRv IGFub3RoZXIuIEEgbWFqb3IgZmFjdG9yIGluDQp0aGUgaW5hYmlsaXR5IG9mIHRlbGVwcmVzZW5j ZSBzeXN0ZW1zIHRvIGludGVyd29yayBpcyB0aGF0IHRoZXJlIGlzIG5vDQpzdGFuZGFyZGl6ZWQg d2F5IHRvIGRlc2NyaWJlIGFuZCBuZWdvdGlhdGUgdGhlIHVzZSBvZiB0aGUgbXVsdGlwbGUNCnN0 cmVhbXMgb2YgYXVkaW8gYW5kIHZpZGVvIHRoYXQgY29tcHJpc2UgdGhlIG1lZGlhIGZsb3dzLiBJ biBhZGRpdGlvbiwNCnRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB3YXkgdG8gZXhjaGFuZ2Ugc2Vt YW50aWMgaW5mb3JtYXRpb24gYWJvdXQgd2hhdA0KZWFjaCBtZWRpYSBzdHJlYW0gcmVwcmVzZW50 cy4gIA0KDQpUaGUgV0cgd2lsbCBjcmVhdGUgc3BlY2lmaWNhdGlvbnMgZm9yIFNJUC1iYXNlZCBj b25mZXJlbmNpbmcgc3lzdGVtcyB0bw0KZW5hYmxlIGNvbW11bmljYXRpb24gb2YgZW5vdWdoIGlu Zm9ybWF0aW9uIGFib3V0IGVhY2ggbWVkaWEgc3RyZWFtIHNvDQp0aGF0IGVhY2ggcmVjZWl2aW5n IHN5c3RlbSBvciBicmlkZ2Ugc3lzdGVtIGNhbiBtYWtlIHJlYXNvbmFibGUNCmRlY2lzaW9ucyBh Ym91dCBzZWxlY3RpbmcgYW5kIHJlbmRlcmluZyBtZWRpYSBzdHJlYW1zLiBUaGlzIGVuYWJsZXMN CnN5c3RlbXMgdG8gbWFrZSBkaXNwbGF5IGNob2ljZXMgdGhhdCBvcHRpbWl6ZSB0aGUgImp1c3Qg bGlrZSBiZWluZw0KdGhlcmUiIGV4cGVyaWVuY2UuIA0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgaXMg Y2hhcnRlcmVkIHRvIHNwZWNpZnkgdGhlIGluZm9ybWF0aW9uIGFib3V0IG1lZGlhDQpzdHJlYW1z IGZyb20gb25lIGVudGl0eSB0byBhbm90aGVyIGVudGl0eToNCg0KKiBTcGF0aWFsIHJlbGF0aW9u c2hpcHMgb2YgY2FtZXJhcywgZGlzcGxheXMsIG1pY3JvcGhvbmVzLCBhbmQNCiAgU3BlYWtlcnMg LSBpbiByZWxhdGlvbiB0byBlYWNoIG90aGVyIGFuZCB0byBsaWtlbHkgcG9zaXRpb25zIG9mDQog IHBhcnRpY2lwYW50cw0KDQoqIFNwZWNpZmljIGNoYXJhY3RlcmlzdGljcyBzdWNoIGFzIHZpZXdw b2ludCwgZmllbGQgb2Ygdmlldy9jYXB0dXJlDQogIGZvciBjYW1lcmEvbWljcm9waG9uZS9kaXNw bGF5L3NwZWFrZXIgLSBzbyB0aGF0IHNlbmRlcnMgYW5kDQoNCiAgbWlkZGxlYm94ZXMgY2FuIHVu ZGVyc3RhbmQgaG93IGJlc3QgdG8gY29tcG9zZSBzdHJlYW1zIGZvcg0KICByZWNlaXZlcnMsIGFu ZCB0aGUgcmVjZWl2ZXJzIHdpbGwga25vdyB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIGl0cyANCiAg cmVjZWl2ZWQgc3RyZWFtcw0KDQoqVXNhZ2Ugb2YgdGhlIHN0cmVhbSwgZm9yIGV4YW1wbGUgd2hl dGhlciB0aGUgc3RyZWFtIGlzIHByZXNlbnRhdGlvbiwgb3INCmRvY3VtZW50IGNhbWVyYSBvdXRw dXQNCg0KKiBBc3BlY3QgcmF0aW8gb2YgY2FtZXJhcyBhbmQgZGlzcGxheXMNCg0KKiBXaGljaCBz b3VyY2VzIGEgcmVjZWl2ZXIgd2FudHMgdG8gcmVjZWl2ZS4gIEZvciBleGFtcGxlLCBpdCBtaWdo dCB3YW50DQp0aGUgc291cmNlIGZvciB0aGUgbGVmdCBjYW1lcmEsIG9yIG1pZ2h0IHdhbnQgdGhl IHNvdXJjZSBjaG9zZW4gYnkgVkFEDQooVm9pY2UgQWN0aXZpdHkgRGV0ZWN0aW9uKS4NCg0KDQpJ bmZvcm1hdGlvbiBiZXR3ZWVuIHNvdXJjZXMgYW5kIHNpbmtzIGFib3V0IG1lZGlhIHN0cmVhbSBj YXBhYmlsaXRpZXMNCndpbGwgYmUgZXhjaGFuZ2VkLiANCg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBkZWZpbmUgdGhlIHNlbWFudGljcywgc3ludGF4LCAgYW5kIHRyYW5zcG9ydA0KbWVjaGFuaXNt IG5lY2Vzc2FyeSBmb3IgY29tbXVuaWNhdGluZyB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uLiBJ dCB3aWxsDQpjb25zaWRlciB3aGV0aGVyIHRoZSBleGlzdGluZyBzaWduYWxpbmcgbWVjaGFuaXNt cyAoZS4gZy4sIFNEUCkgY2FuIGJlDQpleHRlbmRlZCwgb3IgYW5vdGhlciBtZXNzYWdpbmcgbWV0 aG9kIHNob3VsZCBiZSB1c2VkLiAgDQoNClRoZSBzY29wZSBvZiB0aGUgd29yayBpbmNsdWRlcyBk ZXNjcmliaW5nIHJlbGF0aXZlbHkgc3RhdGljIHJlbGF0aW9ucw0KYmV0d2VlbiBlbnRpdGllcyAo cGFydGljaXBhbnRzIGFuZCBkZXZpY2VzKS4gSXQgYWxzbyBpbmNsdWRlcyBoYW5kbGluZw0KbW9y ZSBkeW5hbWljIHJlbGF0aW9uc2hpcHMsIHN1Y2ggYXMgaWRlbnRpZnlpbmcgdGhlIGF1ZGlvIGFu ZCB2aWRlbw0Kc3RyZWFtcyBmb3IgdGhlIGN1cnJlbnQgc3BlYWtlci4gVGhlIHNjb3BlIGluY2x1 ZGVzIGJvdGggc3lzdGVtcyB0aGF0DQpwcm92aWRlIGEgZnVsbHkgaW1tZXJzaXZlIGV4cGVyaWVu Y2UsIGFuZCBzeXN0ZW1zIHRoYXQgaW50ZXJ3b3JrIHdpdGgNCnRoZW0gYW5kIHRoZXJlZm9yZSBu ZWVkIHRvIHVuZGVyc3RhbmQgdGhlIHNhbWUgbXVsdGlwbGUgc3RyZWFtDQpzZW1hbnRpY3MuICAN Cg0KVGhlIGZvY3VzIG9mIHRoaXMgd29yayBpcyBvbiBtdWx0aXBsZSBhdWRpbyBhbmQgdmlkZW8g c3RyZWFtcy4gIE90aGVyDQptZWRpYSB0eXBlcyBtYXkgYmUgY29uc2lkZXJlZCwgaG93ZXZlciBk ZXZlbG9wbWVudCBvZiBtZXRob2RvbG9naWVzIGZvcg0KdGhlbSBpcyBub3Qgd2l0aGluIHRoZSBz Y29wZSBvZiB0aGlzIHdvcmsuDQoNCkludGVyb3BlcmF0aW9uIHdpdGggU0lQIGFuZCByZWxhdGVk IHN0YW5kYXJkcyBmb3IgYXVkaW8gYW5kIHZpZGVvIGlzDQpyZXF1aXJlZC4gIEhvd2V2ZXIsIGJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3Rpbmcgbm9uLXN0YW5kYXJkcw0KY29tcGxp YW50IHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGlzIG5vdCByZXF1aXJlZC4NCg0KVGhpcyB3b3JraW5n IGdyb3VwIGlzIG5vdCBjdXJyZW50bHkgY2hhcnRlcmVkIHRvIHdvcmsgb24gaXNzdWVzIG9mDQpj b250aW51b3VzIGNvbmZlcmVuY2UgY29udHJvbCBpbmNsdWRpbmc6IGZhciBlbmQgY2FtZXJhIGNv bnRyb2wsDQppbmRpY2F0aW9uIG9mIGZhc3QgZnJhbWUgdXBkYXRlIGZvciB2aWRlbyBjb2RlY3Mg b3Igb3RoZXIgcmFwaWQNCnN3aXRjaGVzLCBmbG9vciBjb250cm9sLCBjb25mZXJlbmNlIHJvc3Rl ci4gDQoNClJldXNlIG9mIGV4aXN0aW5nIHByb3RvY29scyBhbmQgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkgd2l0aA0KU0lQLWNvbXBsaWFudCBhdWRpby92aWRlbyBlbmRwb2ludHMgIGFyZSBpbXBv cnRhbnQgZmFjdG9ycyBmb3IgdGhlDQp3b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVyLiBUaGUgd29y ayB3aWxsIGNsb3NlbHkgY29vcmRpbmF0ZSB3aXRoIHRoZQ0KYXBwcm9wcmlhdGUgYXJlYXMgYW5k IHdvcmtpbmcgZ3JvdXBzIGluY2x1ZGluZyBPUFMgQXJlYSwgQVZULCBNTVVTSUMsDQpNRURJQUNU UkwsIFhDT04sIGFuZCBTSVBDT1JFLg0KDQpNaWxlc3RvbmVzICANCg0KTm92IDIwMTAgU3VibWl0 IGluZm9ybWF0aW9uIGRyYWZ0IHRvIElFU0cgb24gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMN Cg0KTm92IDIwMTEgU3VibWl0IHN0YW5kYXJkcyB0cmFjayBzcGVjaWZpY2F0aW9uIHRvIElFU0cg IGluZGljYXRpbmcNCnNwYXRpYWwgcmVsYXRpb25zaGlwcyANCm9mICBzY3JlZW5zICBjYW1lcmFz IChpbmNsdWRpbmcgdmFyaWFibGUgZmllbGQgb2YgdmlldyBhbmQgb3JpZW50YXRpb24pLA0Kc3Bl YWtlcnMgYW5kIG1pY3JvcGhvbmVzOyBhbmQgdGhlICJ1c2FnZSIgb2YgYSBzdHJlYW0gYXMgZGVm aW5lZCBpbiB0aGUNCmNoYXJ0ZXIuICBTZW1hbnRpY3MsIGxhbmd1YWdlIGFuZCB0cmFuc3BvcnQg bWVjaGFuaXNtIHdpbGwgYmUgc3BlY2lmaWVkLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0t LS0tLQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVsd2VsbCwgSm9obiBbbWFp bHRvOmpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5jb21dIA0KU2VudDogVGh1cnNkYXks IFNlcHRlbWJlciAwOSwgMjAxMCAxMjozMSBBTQ0KVG86IEFsbHluIFJvbWFub3cgKGFsbHluKTsg RElTUEFUQ0ggbGlzdA0KU3ViamVjdDogUkU6IFRlbGVwcmVzZW5jZSBjaGFydGVyIHZlcnNpb24g NA0KDQpBbGx5biwNCg0KQ2FuIHlvdSBleHBsYWluIHRoZSBmb2xsb3dpbmc6DQoiSXQgd2lsbCBj b25zaWRlciB3aGV0aGVyIHRoZSBleGlzdGluZyBzaWduYWxpbmcgbWVjaGFuaXNtcyAoZS4gZy4s IC4uLi4NCkJGQ1ApIGNhbiBiZSBleHRlbmRlZCwgb3IgYW5vdGhlciBtZXNzYWdpbmcgbWV0aG9k IHNob3VsZCBiZSB1c2VkIg0KDQphbmQgDQoNCiJUaGlzIHdvcmtpbmcgZ3JvdXAgaXMgbm90IGN1 cnJlbnRseSBjaGFydGVyZWQgdG8gd29yayBvbiANCmlzc3VlcyBvZiBjb250aW51b3VzIGNvbmZl cmVuY2UgY29udHJvbCBpbmNsdWRpbmc6IC4uLi4gZmxvb3INCmNvbnRyb2wuLi4iIA0KDQpJdCBp cyB1bmNsZWFyIHRvIG1lIGhvdyBCRkNQIGNhbiBiZSB3aXRoaW4gc2NvcGUgeWV0IGZsb29yIGNv bnRyb2wgaXMNCm91dCBvZiBzY29wZS4NCg0KSm9obg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gN Cg0K ------_=_NextPart_001_01CB5940.039543E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9V29y ZFNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PkhpIEdlcmFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SeKAmW0gaW4gYWdyZWVtZW50IHdpdGggUGV0ZXIgYW5k IFN0ZXZl4oCZcyBub3Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkFzIHlvdSBt YXkga25vdyB0aGUgSVRVIGhhcyByZWNlbnRseSBjaGFydGVyZWQgYSBncm91cCB0byB3b3JrDQpv biBUZWxlcHJlc2VuY2UuIFdlIGFyZSBob3BpbmcgdGhhdCB0aGV5IHdpbGwgcmVmZXJlbmNlIHRo ZSB3b3JrIHdlIGRvIGZvciBoYW5kbGluZw0KbXVsdGlwbGUgc3RyZWFtcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPklNVEMsIHRoZSBJbnRlcm5hdGlvbmFsIE11bHRpbWVkaWEgVGVs ZWNvbW11bmljYXRpb25zDQpDb25zb3J0aXVtLCBhbiBpbmR1c3RyeSBncm91cCwgaGFzIGJlZW4g bG9va2luZyBhdCBzcGVjaWZpYyBhc3BlY3RzIG9mDQppbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4g U0lQIGFuZCBILjMyMyDCoGFuZCBtYWRlIHNvbWUgcmVjb21tZW5kYXRpb25zLiBZb3UgbWF5DQp3 YW50IHRvIHNlZSB3aGF0IHlvdSB0aGluayBvZiB0aGUgd29yayB0aGV5IGhhdmUgZG9uZS4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5BcyBvdGhlcnMgaGF2ZSBzYWlkLCB0aGUgY2hh cnRlciBoZXJlIGlzIGZvY3VzZWQgc3BlY2lmaWNhbGx5IG9uDQpzcGVjaWZ5aW5nIGEgY29tbW9u IGFwcHJvYWNoIHRvIGhhbmRsaW5nIG11bHRpcGxlIHN0cmVhbXMsIHJhdGhlciB0aGFuIHRha2lu ZyB1cA0KYSB3aWRlciByYW5nZSBvZiB0ZWxlcHJlc2VuY2UgaW50ZXJvcGVyYWJpbGl0eSBpc3N1 ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPkFsbHluPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRp dj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEdlcmFyZCBGZXJuYW5kbw0KW21haWx0 bzpnZXJhcmRteGZAeWFob28uY28udWtdIDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRl bWJlciAyMCwgMjAxMCAzOjA2IEFNPGJyPg0KPGI+VG86PC9iPiBBbGx5biBSb21hbm93IChhbGx5 bik7IERJU1BBVENIIGxpc3Q8YnI+DQo8Yj5DYzo8L2I+IEdlcmFyZCBGZXJuYW5kbzsgR2VyYXJk Lk0uWC5GZXJuYW5kb0B6dGUuY29tLmNuPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGlzcGF0 Y2hdIFRlbGVwcmVzZW5jZSBjaGFydGVyIHZlcnNpb24gNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+RGVh cg0KQWxseW4sIEFsbCw8YnI+DQombmJzcDs8YnI+DQpJIHNlZSB0aGUgc3RhdGVtZW50IG9uIGlu dGVyb3BlcmFiaWxpdHkuIEhvd2V2ZXIsIEkgd291bGQgZ3Vlc3MgdGhhdCB0aGUgbW9zdA0KaW1w b3J0YW50IGFzcGVjdCBpcyZuYnNwOyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggSC4zMjMuIElmIGl0 J3MgcG9zc2libGUgdG8NCmV4cGxpY2l0bHkgc3RhdGUgdGhhdCBpbiB0aGUgY2hhcnRlciB0aGVu IHRoYXQgY291bGQgbXVjaCBoZWxwIHdpdGggdGhlIHN1Y2Nlc3MNCm9mIHRoaXMgd29yay4gSSB2 aWV3IHRoZSBmb2xsb3dpbmcgcmVhc29ucyBmb3IgaW5jbHVzaW9uIG9mIHN1Y2ggYSBzdGF0ZW1l bnQgb24NCkguMzIzIGludGVyb3BlcmFiaWxpdHk6PGJyPg0KPGJyPg0KKGEpIEl0IGVuc3VyZXMg dGhhdCB0aGVyZSdzIG5vIHBlcmNlcHRpb24gb2YgSUVURiBuZWdsZWN0aW5nIHRoaXMgYXNwZWN0 IG9mDQppbnRlcm9wZXJhYmlsaXR5PGJyPg0KKGIpIEJyaW5nIGluIGNvbXBhbmllcyB3aG8gaGF2 ZSBhIGZvY3VzIG9uIEguMzIzIGludG8gdGhlIElFVEYgYWN0aXZpdHkuIE15DQp1bmRlcnN0YW5k aW5nIGlzIHRoYXQgbWFueSB2ZW5kb3JzIGhhdmUgcHJvZHVjdHMgdGhhdCB1c2UgdGhlIEguMzIz IHN1aXRlIG9mDQpwcm90b2NvbHMuPGJyPg0KPGJyPg0KVGhhbmtzPGJyPg0KPGJyPg0KR2VyYXJk PGJyPg0KLS0tLS0tLS0tPGJyPg0KPGJyPg0KR2VyYXJkIEZlcm5hbmRvPGJyPg0KWlRFIENvcnBv cmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXY+ DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpj ZW50ZXInPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPg0KDQo8aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+ DQoNCjwvc3Bhbj48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPiBBbGx5biBSb21hbm93IChhbGx5bikNCiZsdDthbGx5bkBjaXNj by5jb20mZ3Q7PGJyPg0KPGI+VG86PC9iPiAmcXVvdDtFbHdlbGwsIEpvaG4mcXVvdDsgJmx0O2pv aG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5jb20mZ3Q7Ow0KRElTUEFUQ0ggbGlzdCAmbHQ7 ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFdlZCwgMTUgU2VwdGVtYmVy LCAyMDEwIDEwOjQyOjEwPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtkaXNwYXRjaF0gVGVsZXByZXNl bmNlIGNoYXJ0ZXIgdmVyc2lvbiA1PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+DQpJbiBrZWVwaW5n IHdpdGggSm9obidzIGdvb2QgY2F0Y2gsIHRoZSByZWZlcmVuY2UgdG8gQkZDUCBoYXMgYmVlbjxi cj4NCnJlbW92ZWQuIDxicj4NClRoaXMgd2FzIHRoZSBvbmx5IHN1Z2dlc3RlZCBjaGFuZ2UgdG8g dGhlIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkFsbHluPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KTUFMVCAtIE11bHRpLXN0cmVhbSBBdHRy aWJ1dGVzIGZvciBMaWZlbGlrZSBUZWxlcHJlc2VuY2U8YnI+DQpDT0NLVEFJTCAtIENvbW11bmlj YXRpb24gYW5kIENvcnJlbGF0aW9uIG9mIEtleSBUZWxlcHJlc2VuY2UgQXR0cmlidXRlczxicj4N CmZvciBJbnRlcm9wZXJhYmxlIExpbmtzPGJyPg0KTUFJVEFJIC0gTXVsdGktc3RyZWFtIEF0dHJp YnV0ZXMgZm9yIEltcHJvdmluZyBUZWxlcHJlc2VuY2UgQXBwbGljYXRpb248YnI+DQpJbnRlcm9w ZXJhYmlsaXR5PGJyPg0KVEVRVUlMQSAtIFRlbGVwcmVzZW5jZSBFbmNvZGluZyBvZiBRVWFsaWZp ZXJzIGZvciBJbnRlcm9wZXJhYmxlIExpZmVsaWtlPGJyPg0KQXBwbGljYXRpb25zPGJyPg0KTU9K SVRPIC0gTXVsdGktc3RyZWFtIE9yaWVudGF0aW9uIGZvciBKb2luaW5nIG9mIEludGVyb3BlcmFi bGU8YnI+DQpUZWxlcHJlc2VuY2UgT3BlcmF0aW9uczxicj4NCjxicj4NCjxicj4NCkluIHRoZSBj b250ZXh0IG9mIHRoaXMgV0csIHRoZSB0ZXJtIHRlbGVwcmVzZW5jZSBpcyB1c2VkIGluIGEgZ2Vu ZXJhbDxicj4NCm1hbm5lciB0byBkZXNjcmliZSBzeXN0ZW1zIHRoYXQgcHJvdmlkZSBoaWdoIGRl ZmluaXRpb24sIGhpZ2ggcXVhbGl0eTxicj4NCmF1ZGlvL3ZpZGVvIGVuYWJsaW5nIGEgJnF1b3Q7 YmVpbmctdGhlcmUmcXVvdDsgZXhwZXJpZW5jZS4mbmJzcDsgT25lIGV4YW1wbGUgaXMNCmFuPGJy Pg0KaW1tZXJzaXZlIHRlbGVwcmVzZW5jZSBzeXN0ZW0gdXNpbmcgc3BlY2lhbGx5IGRlc2lnbmVk IGFuZCBzcGVjaWFsPGJyPg0KcHVycG9zZSByb29tcyB3aXRoIG11bHRpcGxlIGRpc3BsYXlzIHBl cm1pdHRpbmcgbGlmZSBzaXplIGltYWdlPGJyPg0KcmVwcm9kdWN0aW9uIHVzaW5nIG11bHRpcGxl IGNhbWVyYXMsIGVuY29kZXJzLCBkZWNvZGVycywgbWljcm9waG9uZXMgYW5kPGJyPg0KbG91ZHNw ZWFrZXJzLjxicj4NCjxicj4NCkN1cnJlbnQgdGVsZXByZXNlbmNlIHN5c3RlbXMgYXJlIGJhc2Vk IG9uIG9wZW4gc3RhbmRhcmRzIHN1Y2ggYXMgUlRQLDxicj4NClNJUCwgSC4yNjQsIHRoZSBILjMy MyBzdWl0ZSwgaG93ZXZlciwgdGhleSBjYW5ub3QgZWFzaWx5IGludGVyb3BlcmF0ZTxicj4NCndp dGggZWFjaCBvdGhlciB3aXRob3V0IG9wZXJhdG9yIGFzc2lzdGFuY2UgYW5kIGV4cGVuc2l2ZSBh ZGRpdGlvbmFsPGJyPg0KZXF1aXBtZW50IHdoaWNoIHRyYW5zbGF0ZXMgZnJvbSBvbmUgdmVuZG9y IHRvIGFub3RoZXIuIEEgbWFqb3IgZmFjdG9yIGluPGJyPg0KdGhlIGluYWJpbGl0eSBvZiB0ZWxl cHJlc2VuY2Ugc3lzdGVtcyB0byBpbnRlcndvcmsgaXMgdGhhdCB0aGVyZSBpcyBubzxicj4NCnN0 YW5kYXJkaXplZCB3YXkgdG8gZGVzY3JpYmUgYW5kIG5lZ290aWF0ZSB0aGUgdXNlIG9mIHRoZSBt dWx0aXBsZTxicj4NCnN0cmVhbXMgb2YgYXVkaW8gYW5kIHZpZGVvIHRoYXQgY29tcHJpc2UgdGhl IG1lZGlhIGZsb3dzLiBJbiBhZGRpdGlvbiw8YnI+DQp0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQg d2F5IHRvIGV4Y2hhbmdlIHNlbWFudGljIGluZm9ybWF0aW9uIGFib3V0IHdoYXQ8YnI+DQplYWNo IG1lZGlhIHN0cmVhbSByZXByZXNlbnRzLiZuYnNwOyA8YnI+DQo8YnI+DQpUaGUgV0cgd2lsbCBj cmVhdGUgc3BlY2lmaWNhdGlvbnMgZm9yIFNJUC1iYXNlZCBjb25mZXJlbmNpbmcgc3lzdGVtcyB0 bzxicj4NCmVuYWJsZSBjb21tdW5pY2F0aW9uIG9mIGVub3VnaCBpbmZvcm1hdGlvbiBhYm91dCBl YWNoIG1lZGlhIHN0cmVhbSBzbzxicj4NCnRoYXQgZWFjaCByZWNlaXZpbmcgc3lzdGVtIG9yIGJy aWRnZSBzeXN0ZW0gY2FuIG1ha2UgcmVhc29uYWJsZTxicj4NCmRlY2lzaW9ucyBhYm91dCBzZWxl Y3RpbmcgYW5kIHJlbmRlcmluZyBtZWRpYSBzdHJlYW1zLiBUaGlzIGVuYWJsZXM8YnI+DQpzeXN0 ZW1zIHRvIG1ha2UgZGlzcGxheSBjaG9pY2VzIHRoYXQgb3B0aW1pemUgdGhlICZxdW90O2p1c3Qg bGlrZSBiZWluZzxicj4NCnRoZXJlJnF1b3Q7IGV4cGVyaWVuY2UuIDxicj4NCjxicj4NClRoaXMg d29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8gc3BlY2lmeSB0aGUgaW5mb3JtYXRpb24gYWJv dXQgbWVkaWE8YnI+DQpzdHJlYW1zIGZyb20gb25lIGVudGl0eSB0byBhbm90aGVyIGVudGl0eTo8 YnI+DQo8YnI+DQoqIFNwYXRpYWwgcmVsYXRpb25zaGlwcyBvZiBjYW1lcmFzLCBkaXNwbGF5cywg bWljcm9waG9uZXMsIGFuZDxicj4NCiZuYnNwOyBTcGVha2VycyAtIGluIHJlbGF0aW9uIHRvIGVh Y2ggb3RoZXIgYW5kIHRvIGxpa2VseSBwb3NpdGlvbnMgb2Y8YnI+DQombmJzcDsgcGFydGljaXBh bnRzPGJyPg0KPGJyPg0KKiBTcGVjaWZpYyBjaGFyYWN0ZXJpc3RpY3Mgc3VjaCBhcyB2aWV3cG9p bnQsIGZpZWxkIG9mIHZpZXcvY2FwdHVyZTxicj4NCiZuYnNwOyBmb3IgY2FtZXJhL21pY3JvcGhv bmUvZGlzcGxheS9zcGVha2VyIC0gc28gdGhhdCBzZW5kZXJzIGFuZDxicj4NCjxicj4NCiZuYnNw OyBtaWRkbGVib3hlcyBjYW4gdW5kZXJzdGFuZCBob3cgYmVzdCB0byBjb21wb3NlIHN0cmVhbXMg Zm9yPGJyPg0KJm5ic3A7IHJlY2VpdmVycywgYW5kIHRoZSByZWNlaXZlcnMgd2lsbCBrbm93IHRo ZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgaXRzIDxicj4NCiZuYnNwOyByZWNlaXZlZCBzdHJlYW1zPGJy Pg0KPGJyPg0KKlVzYWdlIG9mIHRoZSBzdHJlYW0sIGZvciBleGFtcGxlIHdoZXRoZXIgdGhlIHN0 cmVhbSBpcyBwcmVzZW50YXRpb24sIG9yPGJyPg0KZG9jdW1lbnQgY2FtZXJhIG91dHB1dDxicj4N Cjxicj4NCiogQXNwZWN0IHJhdGlvIG9mIGNhbWVyYXMgYW5kIGRpc3BsYXlzPGJyPg0KPGJyPg0K KiBXaGljaCBzb3VyY2VzIGEgcmVjZWl2ZXIgd2FudHMgdG8gcmVjZWl2ZS4mbmJzcDsgRm9yIGV4 YW1wbGUsIGl0IG1pZ2h0IHdhbnQ8YnI+DQp0aGUgc291cmNlIGZvciB0aGUgbGVmdCBjYW1lcmEs IG9yIG1pZ2h0IHdhbnQgdGhlIHNvdXJjZSBjaG9zZW4gYnkgVkFEPGJyPg0KKFZvaWNlIEFjdGl2 aXR5IERldGVjdGlvbikuPGJyPg0KPGJyPg0KPGJyPg0KSW5mb3JtYXRpb24gYmV0d2VlbiBzb3Vy Y2VzIGFuZCBzaW5rcyBhYm91dCBtZWRpYSBzdHJlYW0gY2FwYWJpbGl0aWVzPGJyPg0Kd2lsbCBi ZSBleGNoYW5nZWQuIDxicj4NCjxicj4NClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVmaW5lIHRo ZSBzZW1hbnRpY3MsIHN5bnRheCwmbmJzcDsgYW5kIHRyYW5zcG9ydDxicj4NCm1lY2hhbmlzbSBu ZWNlc3NhcnkgZm9yIGNvbW11bmljYXRpbmcgdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbi4gSXQg d2lsbDxicj4NCmNvbnNpZGVyIHdoZXRoZXIgdGhlIGV4aXN0aW5nIHNpZ25hbGluZyBtZWNoYW5p c21zIChlLiBnLiwgU0RQKSBjYW4gYmU8YnI+DQpleHRlbmRlZCwgb3IgYW5vdGhlciBtZXNzYWdp bmcgbWV0aG9kIHNob3VsZCBiZSB1c2VkLiZuYnNwOyA8YnI+DQo8YnI+DQpUaGUgc2NvcGUgb2Yg dGhlIHdvcmsgaW5jbHVkZXMgZGVzY3JpYmluZyByZWxhdGl2ZWx5IHN0YXRpYyByZWxhdGlvbnM8 YnI+DQpiZXR3ZWVuIGVudGl0aWVzIChwYXJ0aWNpcGFudHMgYW5kIGRldmljZXMpLiBJdCBhbHNv IGluY2x1ZGVzIGhhbmRsaW5nPGJyPg0KbW9yZSBkeW5hbWljIHJlbGF0aW9uc2hpcHMsIHN1Y2gg YXMgaWRlbnRpZnlpbmcgdGhlIGF1ZGlvIGFuZCB2aWRlbzxicj4NCnN0cmVhbXMgZm9yIHRoZSBj dXJyZW50IHNwZWFrZXIuIFRoZSBzY29wZSBpbmNsdWRlcyBib3RoIHN5c3RlbXMgdGhhdDxicj4N CnByb3ZpZGUgYSBmdWxseSBpbW1lcnNpdmUgZXhwZXJpZW5jZSwgYW5kIHN5c3RlbXMgdGhhdCBp bnRlcndvcmsgd2l0aDxicj4NCnRoZW0gYW5kIHRoZXJlZm9yZSBuZWVkIHRvIHVuZGVyc3RhbmQg dGhlIHNhbWUgbXVsdGlwbGUgc3RyZWFtPGJyPg0Kc2VtYW50aWNzLiZuYnNwOyA8YnI+DQo8YnI+ DQpUaGUgZm9jdXMgb2YgdGhpcyB3b3JrIGlzIG9uIG11bHRpcGxlIGF1ZGlvIGFuZCB2aWRlbyBz dHJlYW1zLiZuYnNwOyBPdGhlcjxicj4NCm1lZGlhIHR5cGVzIG1heSBiZSBjb25zaWRlcmVkLCBo b3dldmVyIGRldmVsb3BtZW50IG9mIG1ldGhvZG9sb2dpZXMgZm9yPGJyPg0KdGhlbSBpcyBub3Qg d2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIHdvcmsuPGJyPg0KPGJyPg0KSW50ZXJvcGVyYXRpb24g d2l0aCBTSVAgYW5kIHJlbGF0ZWQgc3RhbmRhcmRzIGZvciBhdWRpbyBhbmQgdmlkZW8gaXM8YnI+ DQpyZXF1aXJlZC4mbmJzcDsgSG93ZXZlciwgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBl eGlzdGluZyBub24tc3RhbmRhcmRzPGJyPg0KY29tcGxpYW50IHRlbGVwcmVzZW5jZSBzeXN0ZW1z IGlzIG5vdCByZXF1aXJlZC48YnI+DQo8YnI+DQpUaGlzIHdvcmtpbmcgZ3JvdXAgaXMgbm90IGN1 cnJlbnRseSBjaGFydGVyZWQgdG8gd29yayBvbiBpc3N1ZXMgb2Y8YnI+DQpjb250aW51b3VzIGNv bmZlcmVuY2UgY29udHJvbCBpbmNsdWRpbmc6IGZhciBlbmQgY2FtZXJhIGNvbnRyb2wsPGJyPg0K aW5kaWNhdGlvbiBvZiBmYXN0IGZyYW1lIHVwZGF0ZSBmb3IgdmlkZW8gY29kZWNzIG9yIG90aGVy IHJhcGlkPGJyPg0Kc3dpdGNoZXMsIGZsb29yIGNvbnRyb2wsIGNvbmZlcmVuY2Ugcm9zdGVyLiA8 YnI+DQo8YnI+DQpSZXVzZSBvZiBleGlzdGluZyBwcm90b2NvbHMgYW5kIGJhY2t3YXJkcyBjb21w YXRpYmlsaXR5IHdpdGg8YnI+DQpTSVAtY29tcGxpYW50IGF1ZGlvL3ZpZGVvIGVuZHBvaW50cyZu YnNwOyBhcmUgaW1wb3J0YW50IGZhY3RvcnMgZm9yIHRoZTxicj4NCndvcmtpbmcgZ3JvdXAgdG8g Y29uc2lkZXIuIFRoZSB3b3JrIHdpbGwgY2xvc2VseSBjb29yZGluYXRlIHdpdGggdGhlPGJyPg0K YXBwcm9wcmlhdGUgYXJlYXMgYW5kIHdvcmtpbmcgZ3JvdXBzIGluY2x1ZGluZyBPUFMgQXJlYSwg QVZULCBNTVVTSUMsPGJyPg0KTUVESUFDVFJMLCBYQ09OLCBhbmQgU0lQQ09SRS48YnI+DQo8YnI+ DQpNaWxlc3RvbmVzJm5ic3A7IDxicj4NCjxicj4NCk5vdiAyMDEwIFN1Ym1pdCBpbmZvcm1hdGlv biBkcmFmdCB0byBJRVNHIG9uIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzPGJyPg0KPGJyPg0K Tm92IDIwMTEgU3VibWl0IHN0YW5kYXJkcyB0cmFjayBzcGVjaWZpY2F0aW9uIHRvIElFU0cmbmJz cDsgaW5kaWNhdGluZzxicj4NCnNwYXRpYWwgcmVsYXRpb25zaGlwcyA8YnI+DQpvZiZuYnNwOyBz Y3JlZW5zJm5ic3A7IGNhbWVyYXMgKGluY2x1ZGluZyB2YXJpYWJsZSBmaWVsZCBvZiB2aWV3IGFu ZA0Kb3JpZW50YXRpb24pLDxicj4NCnNwZWFrZXJzIGFuZCBtaWNyb3Bob25lczsgYW5kIHRoZSAm cXVvdDt1c2FnZSZxdW90OyBvZiBhIHN0cmVhbSBhcyBkZWZpbmVkIGluDQp0aGU8YnI+DQpjaGFy dGVyLiZuYnNwOyBTZW1hbnRpY3MsIGxhbmd1YWdlIGFuZCB0cmFuc3BvcnQgbWVjaGFuaXNtIHdp bGwgYmUgc3BlY2lmaWVkLjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCi0tLS0tLS0tPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBF bHdlbGwsIEpvaG4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86am9obi5lbHdlbGxAc2llbWVucy1l bnRlcnByaXNlLmNvbSI+am9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNlLmNvbTwvYT5dDQo8 YnI+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA5LCAyMDEwIDEyOjMxIEFNPGJyPg0KVG86 IEFsbHluIFJvbWFub3cgKGFsbHluKTsgRElTUEFUQ0ggbGlzdDxicj4NClN1YmplY3Q6IFJFOiBU ZWxlcHJlc2VuY2UgY2hhcnRlciB2ZXJzaW9uIDQ8YnI+DQo8YnI+DQpBbGx5biw8YnI+DQo8YnI+ DQpDYW4geW91IGV4cGxhaW4gdGhlIGZvbGxvd2luZzo8YnI+DQomcXVvdDtJdCB3aWxsIGNvbnNp ZGVyIHdoZXRoZXIgdGhlIGV4aXN0aW5nIHNpZ25hbGluZyBtZWNoYW5pc21zIChlLiBnLiwgLi4u Ljxicj4NCkJGQ1ApIGNhbiBiZSBleHRlbmRlZCwgb3IgYW5vdGhlciBtZXNzYWdpbmcgbWV0aG9k IHNob3VsZCBiZSB1c2VkJnF1b3Q7PGJyPg0KPGJyPg0KYW5kIDxicj4NCjxicj4NCiZxdW90O1Ro aXMgd29ya2luZyBncm91cCBpcyBub3QgY3VycmVudGx5IGNoYXJ0ZXJlZCB0byB3b3JrIG9uIDxi cj4NCmlzc3VlcyBvZiBjb250aW51b3VzIGNvbmZlcmVuY2UgY29udHJvbCBpbmNsdWRpbmc6IC4u Li4gZmxvb3I8YnI+DQpjb250cm9sLi4uJnF1b3Q7IDxicj4NCjxicj4NCkl0IGlzIHVuY2xlYXIg dG8gbWUgaG93IEJGQ1AgY2FuIGJlIHdpdGhpbiBzY29wZSB5ZXQgZmxvb3IgY29udHJvbCBpczxi cj4NCm91dCBvZiBzY29wZS48YnI+DQo8YnI+DQpKb2huPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGlzcGF0Y2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwv ZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01CB5940.039543E0-- From christer.holmberg@ericsson.com Mon Sep 20 22:06:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBEE3A6941 for ; Mon, 20 Sep 2010 22:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.781 X-Spam-Level: X-Spam-Status: No, score=-5.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVfeIH7yZNjj for ; Mon, 20 Sep 2010 22:06:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CB6B53A693F for ; Mon, 20 Sep 2010 22:06:16 -0700 (PDT) X-AuditID: c1b4fb39-b7b0bae000000f9a-b4-4c983d5f682e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.D9.03994.F5D389C4; Tue, 21 Sep 2010 07:06:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 21 Sep 2010 07:06:40 +0200 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "Allyn Romanow (allyn)" , "Elwell, John" , DISPATCH list Date: Tue, 21 Sep 2010 07:06:38 +0200 Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoAAVWaHgABQtK0A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 05:06:19 -0000 Hi Charles,=20 >I think RFC label attribute may be useful; however, we would=20 >need to establish and register set of tokens and the=20 >semantics of those tokens. >Once we get to the actual design, that would be worth considering. >Without addition specification, I think you would have=20 >proprietary sets of labels being used at best. Yes, I agree that we would need to specify the labels. My point was that there does exist a mechanism for doing so. So, maybe the = text could say something like: "In addition, standardization work, in order to be able to exchange semanti= c information about what each media stream represents, might be needed." Regards, Christer > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > Behalf Of Christer Holmberg > > Sent: Monday, September 20, 2010 2:18 AM > > To: Allyn Romanow (allyn); Elwell, John; DISPATCH list > > Subject: Re: [dispatch] Telepresence charter version 5 > >=20 > >=20 > > Hi, > >=20 > > One question for clarification. The text says: > >=20 > > "In addition, there is no standardized way to exchange semantic > information about what each media > > stream represents." > >=20 > > Isn't that something RFC 4574 could be used for? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > Behalf Of Allyn Romanow (allyn) > > Sent: 15. syyskuuta 2010 20:42 > > To: Elwell, John; DISPATCH list > > Subject: [dispatch] Telepresence charter version 5 > >=20 > > In keeping with John's good catch, the reference to BFCP has been > removed. > > This was the only suggested change to the charter. > >=20 > >=20 > > Thanks, > > Allyn > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - > Communication and Correlation of > > Key Telepresence Attributes for Interoperable Links MAITAI - > Multi-stream Attributes for Improving > > Telepresence Application Interoperability TEQUILA - Telepresence > Encoding of QUalifiers for > > Interoperable Lifelike Applications MOJITO - Multi-stream=20 > Orientation > for Joining of Interoperable > > Telepresence Operations > >=20 > >=20 > > In the context of this WG, the term telepresence is used in=20 > a general > manner to describe systems that > > provide high definition, high quality audio/video enabling a > "being-there" experience. One example is > > an immersive telepresence system using specially designed=20 > and special > purpose rooms with multiple > > displays permitting life size image reproduction using multiple > cameras, encoders, decoders, > > microphones and loudspeakers. > >=20 > > Current telepresence systems are based on open standards=20 > such as RTP, > SIP, H.264, the H.323 suite, > > however, they cannot easily interoperate with each other without > operator assistance and expensive > > additional equipment which translates from one vendor to another. A > major factor in the inability of > > telepresence systems to interwork is that there is no=20 > standardized way > to describe and negotiate the > > use of the multiple streams of audio and video that=20 > comprise the media > flows. In addition, there is no > > standardized way to exchange semantic information about what each > media stream represents. > >=20 > > The WG will create specifications for SIP-based conferencing systems > to enable communication of enough > > information about each media stream so that each receiving system or > bridge system can make reasonable > > decisions about selecting and rendering media streams. This enables > systems to make display choices > > that optimize the "just like being there" experience. > >=20 > > This working group is chartered to specify the information=20 > about media > streams from one entity to > > another entity: > >=20 > > * Spatial relationships of cameras, displays, microphones, and > > Speakers - in relation to each other and to likely positions of > > participants > >=20 > > * Specific characteristics such as viewpoint, field of view/capture > > for camera/microphone/display/speaker - so that senders and > >=20 > > middleboxes can understand how best to compose streams for > > receivers, and the receivers will know the characteristics of its > > received streams > >=20 > > *Usage of the stream, for example whether the stream is=20 > presentation, > or document camera output > >=20 > > * Aspect ratio of cameras and displays > >=20 > > * Which sources a receiver wants to receive. For example, it might > want the source for the left > > camera, or might want the source chosen by VAD (Voice Activity > Detection). > >=20 > >=20 > > Information between sources and sinks about media stream=20 > capabilities > will be exchanged. > >=20 > > The working group will define the semantics, syntax, and transport > mechanism necessary for > > communicating the necessary information. It will consider=20 > whether the > existing signaling mechanisms > > (e. g., SDP) can be extended, or another messaging method should be > used. > >=20 > > The scope of the work includes describing relatively static=20 > relations > between entities (participants > > and devices). It also includes handling more dynamic relationships, > such as identifying the audio and > > video streams for the current speaker. The scope includes=20 > both systems > that provide a fully immersive > > experience, and systems that interwork with them and=20 > therefore need to > understand the same multiple > > stream semantics. > >=20 > > The focus of this work is on multiple audio and video=20 > streams. Other > media types may be considered, > > however development of methodologies for them is not within=20 > the scope > of this work. > >=20 > > Interoperation with SIP and related standards for audio and video is > required. However, backwards > > compatibility with existing non-standards compliant telepresence > systems is not required. > >=20 > > This working group is not currently chartered to work on issues of > continuous conference control > > including: far end camera control, indication of fast frame=20 > update for > video codecs or other rapid > > switches, floor control, conference roster. > >=20 > > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are > > important factors for the working group to consider. The work will > closely coordinate with the > > appropriate areas and working groups including OPS Area,=20 > AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. > >=20 > > Milestones > >=20 > > Nov 2010 Submit information draft to IESG on use cases and > requirements > >=20 > > Nov 2011 Submit standards track specification to IESG indicating > spatial relationships of screens > > cameras (including variable field of view and orientation), speakers > and microphones; and the "usage" > > of a stream as defined in the charter. Semantics, language and > transport mechanism will be specified. > >=20 > >=20 > >=20 > > > -------------------------------------------------------------- > ---------- > > -------- > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, September 09, 2010 12:31 AM > > To: Allyn Romanow (allyn); DISPATCH list > > Subject: RE: Telepresence charter version 4 > >=20 > > Allyn, > >=20 > > Can you explain the following: > > "It will consider whether the existing signaling mechanisms (e. g., > .... > > BFCP) can be extended, or another messaging method should be used" > >=20 > > and > >=20 > > "This working group is not currently chartered to work on issues of=20 > > continuous conference control including: .... floor control..." > >=20 > > It is unclear to me how BFCP can be within scope yet floor=20 > control is=20 > > out of scope. > >=20 > > John > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > = From allyn@cisco.com Mon Sep 20 22:16:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCD53A6922 for ; Mon, 20 Sep 2010 22:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj5tg5H16PZn for ; Mon, 20 Sep 2010 22:16:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8042E3A692C for ; Mon, 20 Sep 2010 22:16:43 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADLcl0yrR7Ht/2dsb2JhbACiI3GpSZxLhUEEhE6Ibg X-IronPort-AV: E=Sophos;i="4.56,397,1280707200"; d="scan'208";a="189478456" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Sep 2010 05:17:06 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8L5H6sH025789; Tue, 21 Sep 2010 05:17:06 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Sep 2010 22:17:06 -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 Date: Mon, 20 Sep 2010 22:17:03 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1D20@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoAAVWaHgABQtK0AAAEn6sA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" , "Charles Eckel (eckelcu)" , "Elwell, John" , "DISPATCH list" X-OriginalArrivalTime: 21 Sep 2010 05:17:06.0133 (UTC) FILETIME=[3B87C050:01CB594C] Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 05:16:49 -0000 Hi Christer, Thanks for pointing out that the original sentence is not strictly accurate, and also not precisely what was meant. I think it is fine to change the wording along the lines you suggest, can I get back to you shortly on precise wording? =20 Best regards, Allyn -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, September 20, 2010 10:07 PM To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell, John; DISPATCH list Subject: RE: [dispatch] Telepresence charter version 5 Hi Charles,=20 >I think RFC label attribute may be useful; however, we would=20 >need to establish and register set of tokens and the=20 >semantics of those tokens. >Once we get to the actual design, that would be worth considering. >Without addition specification, I think you would have=20 >proprietary sets of labels being used at best. Yes, I agree that we would need to specify the labels. My point was that there does exist a mechanism for doing so. So, maybe the text could say something like: "In addition, standardization work, in order to be able to exchange semantic information about what each media stream represents, might be needed." Regards, Christer > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > Behalf Of Christer Holmberg > > Sent: Monday, September 20, 2010 2:18 AM > > To: Allyn Romanow (allyn); Elwell, John; DISPATCH list > > Subject: Re: [dispatch] Telepresence charter version 5 > >=20 > >=20 > > Hi, > >=20 > > One question for clarification. The text says: > >=20 > > "In addition, there is no standardized way to exchange semantic > information about what each media > > stream represents." > >=20 > > Isn't that something RFC 4574 could be used for? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > Behalf Of Allyn Romanow (allyn) > > Sent: 15. syyskuuta 2010 20:42 > > To: Elwell, John; DISPATCH list > > Subject: [dispatch] Telepresence charter version 5 > >=20 > > In keeping with John's good catch, the reference to BFCP has been > removed. > > This was the only suggested change to the charter. > >=20 > >=20 > > Thanks, > > Allyn > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - > Communication and Correlation of > > Key Telepresence Attributes for Interoperable Links MAITAI - > Multi-stream Attributes for Improving > > Telepresence Application Interoperability TEQUILA - Telepresence > Encoding of QUalifiers for > > Interoperable Lifelike Applications MOJITO - Multi-stream=20 > Orientation > for Joining of Interoperable > > Telepresence Operations > >=20 > >=20 > > In the context of this WG, the term telepresence is used in=20 > a general > manner to describe systems that > > provide high definition, high quality audio/video enabling a > "being-there" experience. One example is > > an immersive telepresence system using specially designed=20 > and special > purpose rooms with multiple > > displays permitting life size image reproduction using multiple > cameras, encoders, decoders, > > microphones and loudspeakers. > >=20 > > Current telepresence systems are based on open standards=20 > such as RTP, > SIP, H.264, the H.323 suite, > > however, they cannot easily interoperate with each other without > operator assistance and expensive > > additional equipment which translates from one vendor to another. A > major factor in the inability of > > telepresence systems to interwork is that there is no=20 > standardized way > to describe and negotiate the > > use of the multiple streams of audio and video that=20 > comprise the media > flows. In addition, there is no > > standardized way to exchange semantic information about what each > media stream represents. > >=20 > > The WG will create specifications for SIP-based conferencing systems > to enable communication of enough > > information about each media stream so that each receiving system or > bridge system can make reasonable > > decisions about selecting and rendering media streams. This enables > systems to make display choices > > that optimize the "just like being there" experience. > >=20 > > This working group is chartered to specify the information=20 > about media > streams from one entity to > > another entity: > >=20 > > * Spatial relationships of cameras, displays, microphones, and > > Speakers - in relation to each other and to likely positions of > > participants > >=20 > > * Specific characteristics such as viewpoint, field of view/capture > > for camera/microphone/display/speaker - so that senders and > >=20 > > middleboxes can understand how best to compose streams for > > receivers, and the receivers will know the characteristics of its > > received streams > >=20 > > *Usage of the stream, for example whether the stream is=20 > presentation, > or document camera output > >=20 > > * Aspect ratio of cameras and displays > >=20 > > * Which sources a receiver wants to receive. For example, it might > want the source for the left > > camera, or might want the source chosen by VAD (Voice Activity > Detection). > >=20 > >=20 > > Information between sources and sinks about media stream=20 > capabilities > will be exchanged. > >=20 > > The working group will define the semantics, syntax, and transport > mechanism necessary for > > communicating the necessary information. It will consider=20 > whether the > existing signaling mechanisms > > (e. g., SDP) can be extended, or another messaging method should be > used. > >=20 > > The scope of the work includes describing relatively static=20 > relations > between entities (participants > > and devices). It also includes handling more dynamic relationships, > such as identifying the audio and > > video streams for the current speaker. The scope includes=20 > both systems > that provide a fully immersive > > experience, and systems that interwork with them and=20 > therefore need to > understand the same multiple > > stream semantics. > >=20 > > The focus of this work is on multiple audio and video=20 > streams. Other > media types may be considered, > > however development of methodologies for them is not within=20 > the scope > of this work. > >=20 > > Interoperation with SIP and related standards for audio and video is > required. However, backwards > > compatibility with existing non-standards compliant telepresence > systems is not required. > >=20 > > This working group is not currently chartered to work on issues of > continuous conference control > > including: far end camera control, indication of fast frame=20 > update for > video codecs or other rapid > > switches, floor control, conference roster. > >=20 > > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are > > important factors for the working group to consider. The work will > closely coordinate with the > > appropriate areas and working groups including OPS Area,=20 > AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. > >=20 > > Milestones > >=20 > > Nov 2010 Submit information draft to IESG on use cases and > requirements > >=20 > > Nov 2011 Submit standards track specification to IESG indicating > spatial relationships of screens > > cameras (including variable field of view and orientation), speakers > and microphones; and the "usage" > > of a stream as defined in the charter. Semantics, language and > transport mechanism will be specified. > >=20 > >=20 > >=20 > > > -------------------------------------------------------------- > ---------- > > -------- > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, September 09, 2010 12:31 AM > > To: Allyn Romanow (allyn); DISPATCH list > > Subject: RE: Telepresence charter version 4 > >=20 > > Allyn, > >=20 > > Can you explain the following: > > "It will consider whether the existing signaling mechanisms (e. g., > .... > > BFCP) can be extended, or another messaging method should be used" > >=20 > > and > >=20 > > "This working group is not currently chartered to work on issues of=20 > > continuous conference control including: .... floor control..." > >=20 > > It is unclear to me how BFCP can be within scope yet floor=20 > control is=20 > > out of scope. > >=20 > > John > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 From christer.holmberg@ericsson.com Mon Sep 20 22:19:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93CB3A693F for ; Mon, 20 Sep 2010 22:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfvRwDE5AnwU for ; Mon, 20 Sep 2010 22:19:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4DD7C3A6938 for ; Mon, 20 Sep 2010 22:19:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbeae00000772f-a2-4c984062d7bd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 12.AF.30511.260489C4; Tue, 21 Sep 2010 07:19:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 21 Sep 2010 07:19:30 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "Charles Eckel (eckelcu)" , "Elwell, John" , DISPATCH list Date: Tue, 21 Sep 2010 07:19:28 +0200 Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoAAVWaHgABQtK0AAAEn6sAAAOkXA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058501703C50@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1D20@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1D20@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 05:19:10 -0000 Hi,=20 >Thanks for pointing out that the original sentence is not=20 >strictly accurate, and also not precisely what was meant. I=20 >think it is fine to change the wording along the lines you=20 >suggest, can I get back to you shortly on precise wording? =20 Sure, no problem. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, September 20, 2010 10:07 PM > To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell,=20 > John; DISPATCH list > Subject: RE: [dispatch] Telepresence charter version 5 >=20 >=20 > Hi Charles,=20 >=20 > >I think RFC label attribute may be useful; however, we would=20 > >need to establish and register set of tokens and the=20 > >semantics of those tokens. > >Once we get to the actual design, that would be worth considering. > >Without addition specification, I think you would have=20 > >proprietary sets of labels being used at best. >=20 > Yes, I agree that we would need to specify the labels. >=20 > My point was that there does exist a mechanism for doing so. So, maybe > the text could say something like: >=20 > "In addition, standardization work, in order to be able to exchange > semantic > information about what each media stream represents, might be needed." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > > Sent: Monday, September 20, 2010 2:18 AM > > > To: Allyn Romanow (allyn); Elwell, John; DISPATCH list > > > Subject: Re: [dispatch] Telepresence charter version 5 > > >=20 > > >=20 > > > Hi, > > >=20 > > > One question for clarification. The text says: > > >=20 > > > "In addition, there is no standardized way to exchange semantic > > information about what each media > > > stream represents." > > >=20 > > > Isn't that something RFC 4574 could be used for? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Allyn Romanow (allyn) > > > Sent: 15. syyskuuta 2010 20:42 > > > To: Elwell, John; DISPATCH list > > > Subject: [dispatch] Telepresence charter version 5 > > >=20 > > > In keeping with John's good catch, the reference to BFCP has been > > removed. > > > This was the only suggested change to the charter. > > >=20 > > >=20 > > > Thanks, > > > Allyn > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > MALT - Multi-stream Attributes for Lifelike Telepresence=20 > COCKTAIL - > > Communication and Correlation of > > > Key Telepresence Attributes for Interoperable Links MAITAI - > > Multi-stream Attributes for Improving > > > Telepresence Application Interoperability TEQUILA - Telepresence > > Encoding of QUalifiers for > > > Interoperable Lifelike Applications MOJITO - Multi-stream=20 > > Orientation > > for Joining of Interoperable > > > Telepresence Operations > > >=20 > > >=20 > > > In the context of this WG, the term telepresence is used in=20 > > a general > > manner to describe systems that > > > provide high definition, high quality audio/video enabling a > > "being-there" experience. One example is > > > an immersive telepresence system using specially designed=20 > > and special > > purpose rooms with multiple > > > displays permitting life size image reproduction using multiple > > cameras, encoders, decoders, > > > microphones and loudspeakers. > > >=20 > > > Current telepresence systems are based on open standards=20 > > such as RTP, > > SIP, H.264, the H.323 suite, > > > however, they cannot easily interoperate with each other without > > operator assistance and expensive > > > additional equipment which translates from one vendor to=20 > another. A > > major factor in the inability of > > > telepresence systems to interwork is that there is no=20 > > standardized way > > to describe and negotiate the > > > use of the multiple streams of audio and video that=20 > > comprise the media > > flows. In addition, there is no > > > standardized way to exchange semantic information about what each > > media stream represents. > > >=20 > > > The WG will create specifications for SIP-based=20 > conferencing systems > > to enable communication of enough > > > information about each media stream so that each=20 > receiving system or > > bridge system can make reasonable > > > decisions about selecting and rendering media streams.=20 > This enables > > systems to make display choices > > > that optimize the "just like being there" experience. > > >=20 > > > This working group is chartered to specify the information=20 > > about media > > streams from one entity to > > > another entity: > > >=20 > > > * Spatial relationships of cameras, displays, microphones, and > > > Speakers - in relation to each other and to likely positions of > > > participants > > >=20 > > > * Specific characteristics such as viewpoint, field of=20 > view/capture > > > for camera/microphone/display/speaker - so that senders and > > >=20 > > > middleboxes can understand how best to compose streams for > > > receivers, and the receivers will know the=20 > characteristics of its > > > received streams > > >=20 > > > *Usage of the stream, for example whether the stream is=20 > > presentation, > > or document camera output > > >=20 > > > * Aspect ratio of cameras and displays > > >=20 > > > * Which sources a receiver wants to receive. For=20 > example, it might > > want the source for the left > > > camera, or might want the source chosen by VAD (Voice Activity > > Detection). > > >=20 > > >=20 > > > Information between sources and sinks about media stream=20 > > capabilities > > will be exchanged. > > >=20 > > > The working group will define the semantics, syntax, and=20 > transport > > mechanism necessary for > > > communicating the necessary information. It will consider=20 > > whether the > > existing signaling mechanisms > > > (e. g., SDP) can be extended, or another messaging method=20 > should be > > used. > > >=20 > > > The scope of the work includes describing relatively static=20 > > relations > > between entities (participants > > > and devices). It also includes handling more dynamic=20 > relationships, > > such as identifying the audio and > > > video streams for the current speaker. The scope includes=20 > > both systems > > that provide a fully immersive > > > experience, and systems that interwork with them and=20 > > therefore need to > > understand the same multiple > > > stream semantics. > > >=20 > > > The focus of this work is on multiple audio and video=20 > > streams. Other > > media types may be considered, > > > however development of methodologies for them is not within=20 > > the scope > > of this work. > > >=20 > > > Interoperation with SIP and related standards for audio=20 > and video is > > required. However, backwards > > > compatibility with existing non-standards compliant telepresence > > systems is not required. > > >=20 > > > This working group is not currently chartered to work on issues of > > continuous conference control > > > including: far end camera control, indication of fast frame=20 > > update for > > video codecs or other rapid > > > switches, floor control, conference roster. > > >=20 > > > Reuse of existing protocols and backwards compatibility with > > SIP-compliant audio/video endpoints are > > > important factors for the working group to consider. The work will > > closely coordinate with the > > > appropriate areas and working groups including OPS Area,=20 > > AVT, MMUSIC, > > MEDIACTRL, XCON, and SIPCORE. > > >=20 > > > Milestones > > >=20 > > > Nov 2010 Submit information draft to IESG on use cases and > > requirements > > >=20 > > > Nov 2011 Submit standards track specification to IESG indicating > > spatial relationships of screens > > > cameras (including variable field of view and=20 > orientation), speakers > > and microphones; and the "usage" > > > of a stream as defined in the charter. Semantics, language and > > transport mechanism will be specified. > > >=20 > > >=20 > > >=20 > > > > > -------------------------------------------------------------- > > ---------- > > > -------- > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, September 09, 2010 12:31 AM > > > To: Allyn Romanow (allyn); DISPATCH list > > > Subject: RE: Telepresence charter version 4 > > >=20 > > > Allyn, > > >=20 > > > Can you explain the following: > > > "It will consider whether the existing signaling=20 > mechanisms (e. g., > > .... > > > BFCP) can be extended, or another messaging method should be used" > > >=20 > > > and > > >=20 > > > "This working group is not currently chartered to work on=20 > issues of=20 > > > continuous conference control including: .... floor control..." > > >=20 > > > It is unclear to me how BFCP can be within scope yet floor=20 > > control is=20 > > > out of scope. > > >=20 > > > John > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > = From mary.ietf.barnes@gmail.com Tue Sep 21 08:37:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2343A6A5B for ; Tue, 21 Sep 2010 08:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o2aM33xhBBV for ; Tue, 21 Sep 2010 08:37:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D06043A6A4B for ; Tue, 21 Sep 2010 08:36:59 -0700 (PDT) Received: by gyd12 with SMTP id 12so2309199gyd.31 for ; Tue, 21 Sep 2010 08:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=vle3kXNo/KalUcnwA6sKMmb0e3i5dzFSp/If5TcU/5Y=; b=sYuupQVWctR0xyXH1KS5cyc7C94ZuhKfWeb1kTBBucGTjMtxQY2qdC0NU0BUN2if82 QDImpPPF9Qts7LlQRFpR4MebBhT4LjxLFjGtDcIOonKiNw5qhtTDVmNJlsEMEhNHFbut y3BMn6VaPmwMr/lDD5MKpGWn9rD4M7ZL1DXjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rNZtPBadBCqnuEvqdFU88SjIeexxoSvosBK6SRJbIQvVfWw3oqRb38bJ37bT+NQQmz iCz+obXM1QWzs6m4kZFB8ujePIw23qPn8g83djnRYXTDTO6L1i84sarg6f6kxdf01JGG ZtfkYtYj2oGVcYZwbdYS6kRyTB3WZqgN8dVsk= MIME-Version: 1.0 Received: by 10.151.21.18 with SMTP id y18mr11121977ybi.296.1285083444286; Tue, 21 Sep 2010 08:37:24 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 21 Sep 2010 08:37:24 -0700 (PDT) Date: Tue, 21 Sep 2010 10:37:24 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] IETF-79 DISPATCH Topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 15:37:01 -0000 Per the reminder posted on the ML on August 23rd and as listed on the DISPATCH WG wiki, proposals for the topics to be the focus for IETF-79 discussions were due on Sept. 6th, 2010. The following topics were put forth for IETF-79: 1) DTMF Info. Draft/discussion thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg02494.html 2) Telepresence. Charter proposal: http://www.ietf.org/mail-archive/web/dispatch/current/msg02608.html 3) BFCP for UDP. Draft/discussion thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg02583.html TSV Area mailing list discussion: http://www.ietf.org/mail-archive/web/tsv-area/current/msg00639.html Mailing list discussion on these topics will allow us to determine the dispatchment for these work items at IETF-79. We'll upload a preliminary agenda in a few weeks time. Regards, Mary and Cullen DISPATCH WG co-chairs From ted.ietf@gmail.com Tue Sep 21 10:19:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2603A691E for ; Tue, 21 Sep 2010 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91PMJ7bdyJNE for ; Tue, 21 Sep 2010 10:19:50 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 8F30A3A659C for ; Tue, 21 Sep 2010 10:19:50 -0700 (PDT) Received: by qyk9 with SMTP id 9so5771499qyk.10 for ; Tue, 21 Sep 2010 10:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=g2g/kKOz2BxAbX3KIgjmwJ/loVaVEjXL046iqzP7Tug=; b=j/CWeQ4y44f5yS3i0Cu0V/9bi9JvLUFMJPvZD90KxO1/JGDABLBhRSF3U460DPiA0E fok+eG9mraWhPQ4jZgPkSIv4oA40haY8iCLBXNTmrOAR9yUSCqg6+Eyhevc+dmlbkpoE tRSpAVjGNQ1r9lT+RDcE+QvcCGaCQzvBWvobE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=B5FXVvcBfbi7LH1fbNE4HjwCqkLjz/cOrcv/qtBnFEPhF0FOl7yvHTZ0MhMqYys1CV FcqbnLt8fRxhhWcJRr12wlq50VBziOGQJhsIE2IHzULbTAtTfP8wtl81vsH3tufxnKLu V9IcDX4umXaZD3+Mrankff6FD4lQaCjJse7V4= MIME-Version: 1.0 Received: by 10.229.217.149 with SMTP id hm21mr7505418qcb.121.1285089614344; Tue, 21 Sep 2010 10:20:14 -0700 (PDT) Received: by 10.229.249.208 with HTTP; Tue, 21 Sep 2010 10:20:14 -0700 (PDT) Date: Tue, 21 Sep 2010 10:20:14 -0700 Message-ID: From: Ted Hardie To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 21 Sep 2010 10:28:11 -0700 Subject: [dispatch] Telepresence charter comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 17:19:52 -0000 Howdy, I was asked off-list to take a look at the Telepresence charter currently under discussion, and to try to relate it to work previously done in CONNEG or other APPS groups (I chaired the CONNEG group donkey's years ago, and some sins seem to follow you no matter what). For those not familiar with CONNEG, the charter is here: http://www.ietf.org/wg/concluded/conneg Some additional backstory is that the two working groups with strong needs in the area were HTTP and Internet Fax. The fax folks had a long history of negotiation using T30 frames, and needed a way to accomplish the same thing on the internet; the HTTP group wanted to get away from user-agent based content negotiation and toward something that allowed description of media features "and enable the development of a cross-protocol vocabulary for exchanging information on recipient capabilities, characteristics, and preferences." This same system was later adapted in SIP contexts in ways no doubt familiar to you. Reading through the telepresence charter, I do see some potential parallels. You have a need to be able to describe the systems in use (number of cameras and their angles, number of mics, etc.), for example, in ways that are "system features" similar to media features. You also seem to be heading down a path that will lead either to active negotiation or recipient selection from a set/collection of system aspects that the sender believes works together. The main difference is in the charter's description of "semantic information about what each media stream represents." Trying to draw helpful lessons learned from conneg for this work, I have three pieces of charter advice. First, set an early milestone that describes the framework by which physical system features will be described. This is a relatively concrete piece of work and it is useful in a variety of contexts. Deciding early whether the group wants registration or some other interoperability mechanism for describing those will also inform later discussion in useful ways. At least to a first-time reader the two current milestones seem to require the entire system to be described and then the entire solution to be specified. In general, smaller chunks may be easier, and they will certainly help the group focus, given the broad set of issues you are tackling. Second, make one of the use cases one in which there is no human present at one or more ends of the telepresence system. A use case recording a telepresence session could be enormously useful in keeping the semantic discussion on target. It is very difficult to avoid saying "user selects among...." in these case or to presume that the users under semantic statements because they can parse natural languages. If the system works when there is no user present on one side, it will work far better when users are present on both. This will require a lot of discipline on the part of the working group, and some stuckee (probably a chair) to say "how will this work in the recording case" a lot, but I firmly believe it will help make the system more usable overall. Third, the current charter notes that the group will define a transport mechanism, but also says that it expects the work may be applicable beyond audio and video streams. There is a tension between these two. If this will be applicable beyond those, there is a fairly hard requirement that the syntax/semantics be transport agnostic. The group should decide early on whether or not it will define a transport-agnostic syntax or not. Given the likely growth in collaboration environments that combine audio/video with other types of media, I personally suspect that this aspect could end up being the most important part of the overall system. I hope you'll forgive my parachuting in with such a long set of comments. I'm also not currently following dispatch closely, and I would appreciate being cc'ed on any questions or comments to which you'd like me to respond. regards, Ted Hardie NB: My current employer has products in this space (along with bicycles, photovoltaic panels, avionics-focused entertainment systems, and pretty much anything else you can think of). I am not involved in that work at this time, and my opinion in no way reflects their thinking on this matter. From tme@americafree.tv Tue Sep 21 11:41:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D073A6A86 for ; Tue, 21 Sep 2010 11:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOkifrtb0j0V for ; Tue, 21 Sep 2010 11:41:55 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 1760E3A6ABF for ; Tue, 21 Sep 2010 11:41:55 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 29BBB8E6C96A; Tue, 21 Sep 2010 14:42:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Tue, 21 Sep 2010 14:42:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D29A3E6-85B4-44C3-A814-E2BFF4B539BB@americafree.tv> References: To: Ted Hardie X-Mailer: Apple Mail (2.1081) Cc: dispatch@ietf.org Subject: Re: [dispatch] Telepresence charter comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 18:41:56 -0000 On Sep 21, 2010, at 1:20 PM, Ted Hardie wrote: > Howdy, >=20 > I was asked off-list to take a look at the Telepresence charter > currently under discussion, > and to try to relate it to work previously done in CONNEG or other > APPS groups (I chaired > the CONNEG group donkey's years ago, and some sins seem to follow you > no matter what). > For those not familiar with CONNEG, the charter is here: > http://www.ietf.org/wg/concluded/conneg > Some additional backstory is that the two working groups with strong > needs in the area > were HTTP and Internet Fax. The fax folks had a long history of > negotiation using T30 > frames, and needed a way to accomplish the same thing on the internet; > the HTTP group > wanted to get away from user-agent based content negotiation and > toward something > that allowed description of media features "and enable the > development of a cross-protocol > vocabulary for exchanging information on recipient capabilities, > characteristics, and > preferences." This same system was later adapted in SIP contexts in > ways no doubt > familiar to you. >=20 > Reading through the telepresence charter, I do see some potential > parallels. You have > a need to be able to describe the systems in use (number of cameras > and their angles, > number of mics, etc.), for example, in ways that are "system features" > similar to media features. You also > seem to be heading down a path that will lead either to active > negotiation or recipient selection > from a set/collection of system aspects that the sender believes works = together. > The main difference is in the charter's description of "semantic > information about what > each media stream represents." >=20 > Trying to draw helpful lessons learned from conneg for this work, I > have three pieces of charter > advice. >=20 > First, set an early milestone that describes the framework by which > physical system > features will be described. This is a relatively concrete piece of > work and it is useful in > a variety of contexts. Deciding early whether the group wants > registration or some other > interoperability mechanism for describing those will also inform later > discussion in useful ways. > At least to a first-time reader the two current milestones seem to > require the entire system > to be described and then the entire solution to be specified. In > general, smaller chunks may be easier, > and they will certainly help the group focus, given the broad set of > issues you are tackling. >=20 > Second, make one of the use cases one in which there is no human > present at one or more > ends of the telepresence system. A use case recording a telepresence > session could be > enormously useful in keeping the semantic discussion on target. It is = very > difficult to avoid saying "user selects among...." in these case or to > presume that the > users under semantic statements because they can parse natural > languages. If the system > works when there is no user present on one side, it will work far > better when users are > present on both. This will require a lot of discipline on the part of > the working group, and > some stuckee (probably a chair) to say "how will this work in the > recording case" a lot, > but I firmly believe it will help make the system more usable overall. >=20 Dear Ted; I have no trouble with any of this. The second point is (IMO) not as artificial in immersive Telepresence as = it might seem. There is a strong desire to "just have things work" in these multi-screen units or, to put it = another way, interop is now frequently done behind the scenes by humans at some service provider, and getting = telepresence interop truly automated is a major driver in this work. Regards Marshall > Third, the current charter notes that the group will define a > transport mechanism, but > also says that it expects the work may be applicable beyond audio and > video streams. > There is a tension between these two. If this will be applicable > beyond those, there > is a fairly hard requirement that the syntax/semantics be transport > agnostic. The group > should decide early on whether or not it will define a > transport-agnostic syntax or not. > Given the likely growth in collaboration environments that combine > audio/video with > other types of media, I personally suspect that this aspect could end > up being the > most important part of the overall system. >=20 > I hope you'll forgive my parachuting in with such a long set of > comments. I'm also not > currently following dispatch closely, and I would appreciate being > cc'ed on any questions > or comments to which you'd like me to respond. >=20 > regards, >=20 > Ted Hardie >=20 > NB: My current employer has products in this space (along with > bicycles, photovoltaic > panels, avionics-focused entertainment systems, and pretty much > anything else you > can think of). I am not involved in that work at this time, and my > opinion in no way > reflects their thinking on this matter. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From keith.drage@alcatel-lucent.com Wed Sep 22 15:22:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091733A6B55 for ; Wed, 22 Sep 2010 15:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.997 X-Spam-Level: X-Spam-Status: No, score=-104.997 tagged_above=-999 required=5 tests=[AWL=1.251, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uixr3QgbodVE for ; Wed, 22 Sep 2010 15:22:00 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 60F533A6B58 for ; Wed, 22 Sep 2010 15:21:58 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o8MMMIjc013150 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Sep 2010 00:22:18 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 23 Sep 2010 00:22:17 +0200 From: "DRAGE, Keith (Keith)" To: "Parthasarathi R (partr)" , Christer Holmberg , "Paul Kyzivat (pkyzivat)" Date: Thu, 23 Sep 2010 00:22:16 +0200 Thread-Topic: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAAJ61h4Fm5qjMA== Message-ID: References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21732174DFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 22:22:02 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21732174DFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think we are going to end up with a new IETF consensus based specif= ication to do this. To do this would be going against the ethos of trying t= o get usages of INFO registered, and essentially there are too many differe= nt ways of doing this out there. So if you have a DTMF usage that you want to register as a INFO package, th= en register it. It will either be registered or not based on the IANA rules= provided in info-events. If you need a published specification using the I= ETF route to do that, then the route is surely RFC individual submission, r= ather than pushing it through and trying to get consensus on it. regards Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Parthasarathi R (partr) Sent: Wednesday, August 25, 2010 5:51 AM To: Christer Holmberg; Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-0= 0.txt Christer, I haven't seen reply to my second question: "2) Whether current IETF standard (KPML) has to be deprecated for the propo= sed DTMF Info packages. Both KPML, DTMF Info package are SIP signaling base= d mechanism for DTMF relay." It is not clear to me why IMS take different stance than current IETF stand= ard (KPML) for DTMF relay. In case of the analysis has done for not selecti= ng KPML in IMS, please let us know as it will help us to proceed in the INF= O based DTMF package direction in IETF. Also Currently, IANA registration is yet to be done for DTMF Info package a= nd so, the modification is possible. Thanks Partha ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 9:04 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal (mperumal) Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00= .txt Hi, >1) whether 3GPP DTMF Info package is in the state to be accepted as IETF s= tandards. The Info Package registration procedure requires an expert review, which pu= rpose is to ensure that the Info Package does not break the SIP protocol et= c. I assume such review will take place when the package is registered with= IANA. Regards, Christer ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 8:45 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal (mpe= rumal) Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-pa= ckage-00.txt Hi, >In case IMS needs new INFO based DTMF relay mechanism, I agree tha= t it is the valid requirement and we need to evaluate it. Before concluding= about new >INFO based mechanism in IMS, Please throw the light for not select= ing KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are bas= ed on SIP >signaling based mechanism. KPML has limited deployment as mentione= d in Hadriel Info draft but new INFO package is yet to be defined. It is be= tter to have >the single active IETF SIP signaling based dtmf-relay mechanism ra= ther than producing more standards wherein implementers will completely con= fused which >one to select. > >As Muthu mentioned, I also heard about KPML deployment issues but = the legacy INFO based dtmf-relay has lot more caveats. I guess that Info pa= ckage is >designed as generic as KPML, and then both KPML and INFO may look = heavyweight. The 3GPP DTMF Info Package is very simple. Regards, Christer ________________________________ From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (= pkyzivat) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-inf= o-dtmf-package-00.txt Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a clai= m there already exists a number of legacy ways of there. Not everyone has i= mplemented the same (if any) of them, and the whole purpose of the Info Pac= kage framework is to come up with a mechanism for which the usage can be ne= gotiated. > > And, as I said earlier, at least in IMS an Info Package i= s being used for DTMF transport. It is currently defined in 3GPP specificat= ions, but there shouldn't be anything IMS specific about the package itself= . I wasn't asserting a general principle. I was talking about this particular mechanism. If there is yet another dtmf package, then I guess we can c= onsider the pros/cons of it. Those are probably best assessed by those = who use the existing one and/or might use whatever info package you mig= ht propose to replace it. We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would im= prove the situation, it is going to be a hard sell. OTOH, the more there are the more case it makes for having = an SBC in the path to "fix" the interoperability. We sell them, so maybe = I should be cheering on every new one as a way to boost sales. Thanks, Paul > Regards, > > Christer > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyz= ivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion abou= t this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that su= pports the >>>> package also supports the legacy approach, what is the= win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But = I >> take your point - if people would prefer to just documen= t it >> as it is today (sans info-packages), I can change the dr= aft >> to just be that. I'm cool with either way (defining the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_EDC0A1AE77C57744B664A310A0B23AE21732174DFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.= txt
I don't think we are going to end up with a new IE= TF=20 consensus based specification to do this. To do this would be going against= the=20 ethos of trying to get usages of INFO registered, and essentially there are= too=20 many different ways of doing this out there.
 
So if you have a DTMF usage that you want to regis= ter as a=20 INFO package, then register it. It will either be registered or not based o= n the=20 IANA rules provided in info-events. If you need a published specification u= sing=20 the IETF route to do that, then the route is surely RFC individual submissi= on,=20 rather than pushing it through and trying to get consensus on=20 it.
 
regards
 
Keith

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R=20 (partr)
Sent: Wednesday, August 25, 2010 5:51 AM
To:= =20 Christer Holmberg; Paul Kyzivat (pkyzivat)
Cc: dispatch@ietf.or= g;=20 Hadriel Kaplan
Subject: Re: [dispatch]=20 I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt

Christer,

 

I haven't seen re= ply=20 to my second question:

 

"2) Whether current IETF st= andard=20 (KPML) has to be deprecated for the proposed DTMF Info packages. Bot= h=20 KPML, DTMF Info package are SIP signaling based mechanism for DTMF=20 relay."

 

It is not clear to me why I= MS take=20 different stance than current IETF standard (KPML) for DTMF relay. In cas= e of=20 the analysis has done for not selecting KPML in IMS, please let us know a= s it=20 will help us to proceed in the INFO based DTMF package direction in=20 IETF.

 

Also Currently, IANA regist= ration=20 is yet to be done for DTMF Info package and so, the modification is=20 possible.

 

Thanks

Partha

From: Christer Holmber= g=20 [mailto:christer.holmberg@ericsson.com]
Sent: Wed 8/25/2010 9:0= 4=20 AM
To: Parthasarathi R (partr); Paul Kyzivat=20 (pkyzivat)
Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMoz= hi=20 Perumal (mperumal)
Subject: RE:=20 [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt


Hi,

>1) whether 3GPP DTMF Info package is in = the=20 state to be accepted as IETF standards.

The Info Package registrat= ion=20 procedure requires an expert review, which purpose is to ensure that the = Info=20 Package does not break the SIP protocol etc. I assume such review will ta= ke=20 place when the package is registered with=20 IANA.

Regards,

Christer




________________= ________________

       =20 From: Christer Holmberg [mailto:christer.holmberg@e= ricsson.com]
       =20 Sent: Wed 8/25/2010 8:45 AM
       = To:=20 Parthasarathi R (partr); Paul Kyzivat=20 (pkyzivat)
        Cc:=20 dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal=20 (mperumal)
        Subject: RE:=20 [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt
&nb= sp;      
     &n= bsp; 


       =20 Hi,
       =20        
    &nb= sp;  =20 >In case IMS needs new INFO based DTMF relay mechanism, I agree that i= t is=20 the valid requirement and we need to evaluate it. Before concluding about= =20 new
        >INFO based mechanis= m in=20 IMS, Please throw the light for not selecting KPML in IMS. I'm comparing = KPML=20 vs INFO based mechanism as both are based on=20 SIP
        >signaling based=20 mechanism. KPML has limited deployment as mentioned in Hadriel Info draft= but=20 new INFO package is yet to be defined. It is better to=20 have
        >the single active = IETF=20 SIP signaling based dtmf-relay mechanism rather than producing more stand= ards=20 wherein implementers will completely confused=20 which
        >one to=20 select.
       =20 >
        >As Muthu mentioned= , I=20 also heard about KPML deployment issues but the legacy INFO based dtmf-re= lay=20 has lot more caveats. I guess that Info package=20 is
        >designed as generic = as=20 KPML, and then both KPML and INFO may look=20 heavyweight.
       
  = ;     =20 The 3GPP DTMF Info Package is very=20 simple.
       
  &nbs= p;    =20 Regards,
       
  &nb= sp;    =20 Christer
       
  &nb= sp;    
              =20       
     &nb= sp; =20 ________________________________
      &= nbsp;
       =20         From: dispatch-bounces@ietf.or= g on=20 behalf of Paul Kyzivat=20 (pkyzivat)
       =20         Sent: Wed 8/25/2010 12:17=20 AM
       =20         To: Christer=20 Holmberg
       =20         Cc: dispatch@ietf.org; Hadriel= =20 Kaplan
       =20         Subject: Re: [dispatch]I-D=20 Action:draft-kaplan-dispatch-info-dtmf-package-00.txt
  &nbs= p;    =20       
     &nb= sp; =20       
     &nb= sp; 
       
  &nbs= p;    
       =20         Christer Holmberg=20 wrote:
       =20         >=20 Hi,
       =20        =20 >
       =20         > I think it is strange to= =20 reject something based on a claim there already exists a number of legacy= ways=20 of there. Not everyone has implemented the same (if any) of them, and the= =20 whole purpose of the Info Package framework is to come up with a mechanis= m for=20 which the usage can be=20 negotiated.
       =20        =20 >
       =20         > And, as I said earlier, a= t=20 least in IMS an Info Package is being used for DTMF transport. It is curr= ently=20 defined in 3GPP specifications, but there shouldn't be anything IMS speci= fic=20 about the package itself.
       =20       
     &nb= sp; =20         I wasn't asserting a general=20 principle.
       =20         I was talking about this parti= cular=20 mechanism.
       =20       
     &nb= sp; =20         If there is yet another dtmf=20 package, then I guess we can consider=20 the
       =20         pros/cons of it. Those are pro= bably=20 best assessed by those who use=20 the
       =20         existing one and/or might use= =20 whatever info package you might propose=20 to
       =20         replace=20 it.
       =20       
     &nb= sp; =20         We clearly suffer from a surpl= us of=20 ways to convey dtmf.
       =20         While its not impossible to ar= gue=20 than another one would improve=20 the
       =20         situation, it is going to be a= hard=20 sell.
       =20       
     &nb= sp; =20         OTOH, the more there are the m= ore=20 case it makes for having an SBC in=20 the
       =20         path to "fix" the interoperabi= lity.=20 We sell them, so maybe I should=20 be
       =20         cheering on every new one as a= way=20 to boost sales.
       =20       
     &nb= sp; =20             &= nbsp;  =20 Thanks,
       =20             &= nbsp;  =20 Paul
       =20       
     &nb= sp; =20         >=20 Regards,
       =20        =20 >
       =20         >=20 Christer
       =20        =20 >
       =20        =20 >
       =20        =20 >
       =20         >> -----Original=20 Message-----
       =20         >> From:=20 dispatch-bounces@ietf.org
       =20         >> [mailto:dispatch-bounces@ietf.or= g]=20 On Behalf Of Paul Kyzivat
       =20         >> Sent: 24. elokuuta 20= 10=20 18:51
       =20         >> To: Hadriel=20 Kaplan
       =20         >> Cc:=20 dispatch@ietf.org
       =20         >> Subject: Re: [dispatc= h]=20 I-D
       =20         >>=20 Action:draft-kaplan-dispatch-info-dtmf-package-00.txt
  &nbs= p;    =20        =20 >>
       =20         >> Maybe we should ask o= ur=20 ADs if they have an opinion about=20 this.
       =20        =20 >>
       =20        =20 >>     =20 Thanks,
       =20        =20 >>     =20 Paul
       =20        =20 >>
       =20         >> Hadriel Kaplan=20 wrote:
       =20         >>>> -----Original= =20 Message-----
       =20         >>>> From: Paul Ky= zivat=20 [mailto:pkyzivat@cisco.com]
&nbs= p;      =20         >>>> Sent: Monday,= =20 August 23, 2010 6:02 PM
       =20         >>>> To: Hadriel=20 Kaplan
       =20        =20 >>>>
       =20         >>>> That reduces= =20 things somewhat. But if everybody that supports=20 the
       =20         >>>> package also= =20 supports the legacy approach, what is the=20 win?
       =20         >>> The legacy mode h= as no=20 published standards document
       = ;=20         >> defining it.  I= =20 thought when the info-packages work=20 was
       =20         >> started, DTMF-in-info= was=20 one of the main drivers.  But=20 I
       =20         >> take your point - if= =20 people would prefer to just document=20 it
       =20         >> as it is today (sans= =20 info-packages), I can change the=20 draft
       =20         >> to just be that. = ; I'm=20 cool with either way (defining=20 the
       =20         >> current dtmf-relay as= a=20 legacy mode was Option-2).
       = =20         >>>=20 -hadriel
       =20        =20 >>>
       =20         >>=20 _______________________________________________
   &nbs= p;   =20         >> dispatch mailing=20 list
       =20         >>=20 dispatch@ietf.org
       =20         >> https://www.ietf.= org/mailman/listinfo/dispatch
      &n= bsp;=20        =20 >>
       =20        =20 _______________________________________________
   &nbs= p;   =20         dispatch mailing=20 list
       =20        =20 dispatch@ietf.org
       =20         https://www.ietf.= org/mailman/listinfo/dispatch
      &n= bsp;=20       
     &nb= sp; 
       

<= /DIV>
--_000_EDC0A1AE77C57744B664A310A0B23AE21732174DFRMRSSXCHMBSC3d_-- From adam@nostrum.com Wed Sep 22 15:46:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24D63A6918 for ; Wed, 22 Sep 2010 15:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz5YQIJV1GWz for ; Wed, 22 Sep 2010 15:46:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 647843A67FA for ; Wed, 22 Sep 2010 15:46:34 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o8MMktoM003206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 17:46:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C9A875F.9060506@nostrum.com> Date: Wed, 22 Sep 2010 17:46:55 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080803080003090004030403" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 22:46:35 -0000 This is a multi-part message in MIME format. --------------080803080003090004030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/22/10 5:22 PM, DRAGE, Keith (Keith) wrote: > So if you have a DTMF usage that you want to register as a INFO > package, then register it. It will either be registered or not based > on the IANA rules provided in info-events. If you need a published > specification using the IETF route to do that, then the route is > surely RFC individual submission, rather than pushing it through and > trying to get consensus on it. > +1 /a --------------080803080003090004030403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/22/10 5:22 PM, DRAGE, Keith (Keith) wrote:
RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt
 
So if you have a DTMF usage that you want to register as a INFO package, then register it. It will either be registered or not based on the IANA rules provided in info-events. If you need a published specification using the IETF route to do that, then the route is surely RFC individual submission, rather than pushing it through and trying to get consensus on it.


+1

/a
--------------080803080003090004030403-- From Even.roni@huawei.com Wed Sep 22 17:29:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909493A687D for ; Wed, 22 Sep 2010 17:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.278 X-Spam-Level: X-Spam-Status: No, score=-100.278 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDODruDGjH7g for ; Wed, 22 Sep 2010 17:29:46 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id EB5CE3A686B for ; Wed, 22 Sep 2010 17:29:45 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L96002KOC238J@szxga01-in.huawei.com> for dispatch@ietf.org; Thu, 23 Sep 2010 08:30:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9600EKXC23YM@szxga01-in.huawei.com> for dispatch@ietf.org; Thu, 23 Sep 2010 08:30:03 +0800 (CST) Received: from windows8d787f9 ([109.67.31.173]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L96009MSC1U2A@szxml02-in.huawei.com>; Thu, 23 Sep 2010 08:30:03 +0800 (CST) Date: Thu, 23 Sep 2010 02:28:20 +0200 From: Roni Even In-reply-to: <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> To: 'Christer Holmberg' , "'Allyn Romanow (allyn)'" , "'Elwell, John'" , 'DISPATCH list' Message-id: <001f01cb5ab6$3ec3acf0$bc4b06d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoACEabhg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 00:29:47 -0000 Hi Christer The label attribute helps with marking the stream but it does not describe what the stream carries (semantics). RFC 4796 has the content attribute that defines the semantics of the streams but does not cover the requirements for the multiple streams case Roni > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Monday, September 20, 2010 11:18 AM > To: 'Allyn Romanow (allyn)'; Elwell, John; DISPATCH list > Subject: Re: [dispatch] Telepresence charter version 5 > > > Hi, > > One question for clarification. The text says: > > "In addition, there is no standardized way to exchange semantic > information about what each media stream represents." > > Isn't that something RFC 4574 could be used for? > > Regards, > > Christer > > > > > > > > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Allyn Romanow (allyn) > Sent: 15. syyskuuta 2010 20:42 > To: Elwell, John; DISPATCH list > Subject: [dispatch] Telepresence charter version 5 > > In keeping with John's good catch, the reference to BFCP has been > removed. > This was the only suggested change to the charter. > > > Thanks, > Allyn > > > > > > > MALT - Multi-stream Attributes for Lifelike Telepresence COCKTAIL - > Communication and Correlation of Key Telepresence Attributes for > Interoperable Links MAITAI - Multi-stream Attributes for Improving > Telepresence Application Interoperability TEQUILA - Telepresence > Encoding of QUalifiers for Interoperable Lifelike Applications MOJITO - > Multi-stream Orientation for Joining of Interoperable Telepresence > Operations > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience. One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders, microphones > and loudspeakers. > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor > in the inability of telepresence systems to interwork is that there is > no standardized way to describe and negotiate the use of the multiple > streams of audio and video that comprise the media flows. In addition, > there is no standardized way to exchange semantic information about > what each media stream represents. > > The WG will create specifications for SIP-based conferencing systems to > enable communication of enough information about each media stream so > that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience. > > This working group is chartered to specify the information about media > streams from one entity to another entity: > > * Spatial relationships of cameras, displays, microphones, and > Speakers - in relation to each other and to likely positions of > participants > > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker - so that senders and > > middleboxes can understand how best to compose streams for > receivers, and the receivers will know the characteristics of its > received streams > > *Usage of the stream, for example whether the stream is presentation, > or document camera output > > * Aspect ratio of cameras and displays > > * Which sources a receiver wants to receive. For example, it might > want the source for the left camera, or might want the source chosen by > VAD (Voice Activity Detection). > > > Information between sources and sinks about media stream capabilities > will be exchanged. > > The working group will define the semantics, syntax, and transport > mechanism necessary for communicating the necessary information. It > will consider whether the existing signaling mechanisms (e. g., SDP) > can be extended, or another messaging method should be used. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream > semantics. > > The focus of this work is on multiple audio and video streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. > > Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing non-standards > compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. > > Reuse of existing protocols and backwards compatibility with SIP- > compliant audio/video endpoints are important factors for the working > group to consider. The work will closely coordinate with the > appropriate areas and working groups including OPS Area, AVT, MMUSIC, > MEDIACTRL, XCON, and SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and > requirements > > Nov 2011 Submit standards track specification to IESG indicating > spatial relationships of screens cameras (including variable field of > view and orientation), speakers and microphones; and the "usage" of a > stream as defined in the charter. Semantics, language and transport > mechanism will be specified. > > > > ----------------------------------------------------------------------- > - > -------- > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, September 09, 2010 12:31 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence charter version 4 > > Allyn, > > Can you explain the following: > "It will consider whether the existing signaling mechanisms (e. g., > .... > BFCP) can be extended, or another messaging method should be used" > > and > > "This working group is not currently chartered to work on > issues of continuous conference control including: .... floor > control..." > > It is unclear to me how BFCP can be within scope yet floor control is > out of scope. > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From hannes.tschofenig@gmx.net Thu Sep 23 08:49:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273EB3A6ADA for ; Thu, 23 Sep 2010 08:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.913 X-Spam-Level: X-Spam-Status: No, score=-100.913 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QEgg81g+n+k for ; Thu, 23 Sep 2010 08:49:19 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 673913A6A10 for ; Thu, 23 Sep 2010 08:49:02 -0700 (PDT) Received: (qmail invoked by alias); 23 Sep 2010 15:49:31 -0000 Received: from unknown (EHLO [10.254.0.174]) [192.100.123.77] by mail.gmx.net (mp052) with SMTP; 23 Sep 2010 17:49:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+6yJAfpma6nJOeKq+GJd0yuEBzQ0s4YLzhtZ99Qb JGnQ05NpoQU2Dk Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Thu, 23 Sep 2010 18:49:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2B5B7DA2-FF26-4572-B227-813A77090912@gmx.net> References: <20100920210002.96EF53A6876@core3.amsl.com> To: dispatch list mailing X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [dispatch] Fwd: Internet Privacy Workshop: 8 and 9 December 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 15:49:23 -0000 Hi all,=20 it would be interesting to hear whether this group has an opinion about = the privacy topic.=20 Please think about joining the workshop! Ciao Hannes Begin forwarded message: > From: IETF Secretariat > Date: September 21, 2010 12:00:02 AM GMT+03:00 > To: ietf-announce@ietf.org > Subject: Internet Privacy Workshop: 8 and 9 December 2010=20 >=20 > The Internet Architecture Board (IAB), World Wide Web Consortium = (W3C), > Internet Society (ISOC) and Massachusetts Institute of Technology = (MIT) > will hold a joint Internet privacy workshop on 8 and 9 December 2010 = at > MIT, Cambridge, Massachusetts on the question: >=20 > "How Can Technology Help to Improve Privacy on the Internet?" >=20 > Information about who we are, what we own, what we have experienced, = how > we behave, where we are located, and how we can be reached are among = the > most personal pieces of information about us. This information is > increasingly being made more easily available electronically via the > Internet, often without the consent of the subject. >=20 > The question for the workshop therefore is: How can we ensure that > architectures and technologies for the Internet, including the World > Wide Web, are developed in ways that respects users=82 intentions = about > their privacy? >=20 > This workshop aims to explore the experience and approaches taken by > developers of Internet including Web technology, when designing = privacy > into these protocols and architectures. Engineers know that many = design > considerations need to be taken into account when developing = solutions. > Balancing between the conflicting goals of openness, privacy, = economics, > and security is often difficult, as illustrated by Clark, et al. in > "Tussle in Cyberspace: Defining Tomorrow's Internet", see > http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > As a member of the technical community, we invite you to share your > experiences by participating in this important workshop. Workshop > participants will focus on the core privacy challenges, the approaches > taken to deal with them, and the status of the work in the field. The > objective is to draw a relationship with other application areas and > other privacy work in an effort to discuss how specific approaches can > be generalized. >=20 > Interested parties must submit a brief contribution describing their > work or approach as it relates to the workshop theme. We welcome > visionary ideas for how to tackle Internet privacy problems, as well = as > write-ups of existing concepts, deployed technologies, and > lessons-learned from successful or failed attempts at deploying = privacy > technologies. Contributions are not required to be original in = content. >=20 > Submitters of accepted position papers will be invited to the = workshop. > The workshop will be structured as a series of working sessions, > punctuated by invited speakers, who will present relevant background > information or controversial ideas that will motivate participants to > reach a deeper understanding of the subject. The organizing committee > may ask submitters of particularly topical papers to present their = ideas > and experiences to the workshop. >=20 > We will publish submitted position papers and slides together with a > summary report of the workshop. >=20 > There are no plans for any remote participation in this workshop. >=20 > To be invited to the workshop, please submit position papers to > privacy@iab.org by November, 5th 2010. >=20 > More detailed information about the workshop, including further = details > about the position paper requirements, is available at: > http://www.iab.org/about/workshops/privacy/ >=20 > We look forward to your input, > Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), = Karen > O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen > Sollins (MIT), Hannes Tschofenig (IAB) > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From sunseawq@huawei.com Fri Sep 24 20:56:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0844A3A68BB; Fri, 24 Sep 2010 20:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.903 X-Spam-Level: ** X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[AWL=-2.854, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ikt21VlZRjc; Fri, 24 Sep 2010 20:55:59 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D72603A6886; Fri, 24 Sep 2010 20:55:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9A009RJAY2GO@szxga05-in.huawei.com>; Sat, 25 Sep 2010 11:56:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9A00BWDAY1CE@szxga05-in.huawei.com>; Sat, 25 Sep 2010 11:56:26 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9A001HTAY1A3@szxml04-in.huawei.com>; Sat, 25 Sep 2010 11:56:25 +0800 (CST) Date: Sat, 25 Sep 2010 11:56:24 +0800 From: Qin Wu To: httpstreaming@ietf.org Message-id: <02ed01cb5c65$a003d890$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_yssMswj13iWO0rUw1Lckkg)" X-Priority: 3 X-MSMail-priority: Normal References: <000601cb59e8$f27af420$ff5afea9@C863D63E94E7457> Cc: dispatch@ietf.org Subject: [dispatch] Discussion summarization in Dispatch on HTTP Streaming X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 03:56:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yssMswj13iWO0rUw1Lckkg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, folks: Glad to see this discussion list has been created with the support of all of you. Summarized what we discussed in the DISPATCH mailing list on HTTP Streaming, couples of things were well discussed: 1. Does this work worth being done? Most of people speaked up on the list answer Yes since HTTP streaming is becoming more prevalent, large part of Internet Traffic today has been possessed by HTTP Streaming, CDN and Direct Download. 2. Is there any existing related work ongoing in IETF and other SDO? This questions haven't been explicitly discussed. But I think it is necessary to bring out on the table since we need more input from these existing work and coordination between different group on the same topic is requried. So,Yes, we have lots of related work listed as follows: (a).IETF: HTTP Streaming Problem Statement discuss the issues when delivering high quality contents to browser users. The related draft is available at: http://tools.ietf.org/html/draft-wu-http-streaming-optimization-ps-00 Apples' HTTP live streaming: well known for quite some time and implemented in the iPhone. It makes use of a M3U playlist file which serves as manifest and each media file must be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio elementary stream. Movstreaming: is already deployed but also highly proprietary. However, it works with common media players. The related work is avaiable at: http://tools.ietf.org/html/draft-pantos-http-live-streaming-04 (b). IETF: Websocket protocol Focus on browsing acceleration, devloped by Hybi WG,As one complementary work, W3C standardize websocket API (c).W3C' focus on client implentation bulit into browser,e.g., video playback support using script and html, push notification support using API, video support using Media fragments URI. (d).3GPPs' Adaptive HTTP Streaming (AHS): introduced recently which defines a Media Presentation Description (MDP) and extensions to the well known ISO Base Media File Format. (e).Open IPTV Forum (OIPF): has been published on Sep 7th, 2010 including "HTTP Adaptive Streaming" which adopts 3GPP AHS and adds support for MPEG-2 Transport Stream. The related work is available at: (f).MPEG' HTTP Streaming of MPEG Media : MPEG has published Uses Cases for HTTP Streaming of MPEG Media and Requirements on HTTP Streaming of MPEG Media. The next stpe is to standardize a solution that addresses the need on how to employ HTTP Streaming to support MPEG MEdia.Therefore MPGE issued a call for proposals on HTTP streaming of MPEG media. Therefore Standardiztion related to this work needs to be carried out joint by IETF/W3C/3GPP . Overlapping work and efforts will be contributed to and synchronized with these other relevant groups. 3. Given various onging work in other SDOs than IETF and vairous different implementations developed by industries (e.g.,Apple, Microsoft, Adobe, RealNetwork), what contribution IETF could make?What's the potential work item? what kind of problem do we need to solve? Yes, it is clear IETF folks has expertise to do this work. The potential problems and issues the IETF folks are interested to look at and discuss are: (a). Issues involving real-time considerations and interoperability with other streaming techniques (b). Consideration of transportissues (fairness, delay, etc.) (c). Tweaking HTTP to improve streaming performance (d).Guidance on how to use HTTP in a network-friendly way. (e). Coordination with other protocols developed by IETF. (f). Offer better transport better than TCP (like SCTP), better tailored for the needs for streaming over http. (g). how to work in environments that may use a combination of RTP multicast and HTTP unicast. (h). How to deliver streaming contents to the client on any device with the same TV Quality of Experience. As for playlist format and streaming file format, these works have been specified by 3GPP, followed by MPEG/OIPF,probably not the interesting piece for the IETFers If I miss something or you have any further inputs and suggestions/comments, please speak up on the list. Based on these inputs and proposals, I would like to share our thoughts thus far on what a new charter might look like and will post in a separate email to this discussion list. The feedback would be highly useful at this point. BTW: Since we have created separated mailing list for this topic, if you have any comments/ideas/proposals to share, please post them to the new discussion list. Regards! -Qin --Boundary_(ID_yssMswj13iWO0rUw1Lckkg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTI4Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgDQpmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjwvRk9OVD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9O VD4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5IaSwgZm9sa3M6PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkdsYWQgdG8gc2VlIHRoaXMg ZGlzY3Vzc2lvbiBsaXN0Jm5ic3A7aGFzIA0KYmVlbiZuYnNwO2NyZWF0ZWQgd2l0aCB0aGUgc3Vw cG9ydCBvZiBhbGwgb2YgeW91LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5TdW1tYXJpemVkIHdoYXQgd2UgZGlzY3Vzc2VkIGluIHRoZSBESVNQQVRDSCAN Cm1haWxpbmcgbGlzdCBvbiBIVFRQIFN0cmVhbWluZywgY291cGxlcyBvZiB0aGluZ3MmbmJzcDt3 ZXJlIHdlbGwgDQpkaXNjdXNzZWQ6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjEuIERvZXMgdGhpcyB3b3JrIHdvcnRoIGJlaW5nIA0KZG9uZT88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+TW9zdCBvZiBwZW9wbGUg c3BlYWtlZCB1cCBvbiB0aGUgbGlzdCBhbnN3ZXIgDQpZZXMgc2luY2UgSFRUUCBzdHJlYW1pbmcg aXMgYmVjb21pbmcgbW9yZSBwcmV2YWxlbnQsIGxhcmdlIHBhcnQgb2YgSW50ZXJuZXQgDQpUcmFm ZmljIHRvZGF5IGhhcyBiZWVuJm5ic3A7IHBvc3Nlc3NlZCBieSBIVFRQIFN0cmVhbWluZywgQ0RO IGFuZCBEaXJlY3QgDQpEb3dubG9hZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjIuIElzIHRoZXJlIGFueSBleGlzdGluZyByZWxhdGVkIHdvcmsgb25nb2lu ZyANCmluIElFVEYgYW5kIG90aGVyIFNETz8gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPlRoaXMgcXVlc3Rpb25zIGhhdmVuJ3QgYmVlbiBleHBsaWNpdGx5 IA0KZGlzY3Vzc2VkLiBCdXQgSSB0aGluayBpdCBpcyBuZWNlc3NhcnkgdG8gYnJpbmcgb3V0IG9u IHRoZSB0YWJsZSBzaW5jZSB3ZSBuZWVkIA0KbW9yZSBpbnB1dCBmcm9tIHRoZXNlIGV4aXN0aW5n IHdvcms8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+YW5k IGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCBncm91cCBvbiANCnRoZSBzYW1lIHRvcGlj IGlzIHJlcXVyaWVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+U28sWWVzLCB3ZSBoYXZlIGxvdHMgb2YgcmVsYXRlZCB3b3JrIGxpc3RlZCBhcyANCmZvbGxv d3M6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxESVY+ PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4oYSkuSUVURjogPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhUVFAgU3Ry ZWFtaW5nIFByb2JsZW0gDQpTdGF0ZW1lbnQ8L0RJVj48L0ZPTlQ+DQo8RElWPjxGT05UIHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmRpc2N1c3MgdGhlIGlzc3VlcyB3aGVuIGRlbGl2ZXJp bmcgaGlnaCANCnF1YWxpdHkgY29udGVudHMgdG8gYnJvd3NlciB1c2Vycy48QlI+VGhlIHJlbGF0 ZWQgZHJhZnQgaXMgYXZhaWxhYmxlIA0KYXQ6PEJSPjwvRk9OVD48QSANCmhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LWh0dHAtc3RyZWFtaW5nLW9wdGltaXphdGlvbi1w cy0wMCI+PEZPTlQgDQpzaXplPTMgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LWh0dHAtc3RyZWFtaW5nLW9wdGltaXphdGlvbi1wcy0w MDwvRk9OVD48L0E+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+QXBwbGVzJyBIVFRQIGxpdmUgc3RyZWFtaW5nOiA8QlI+d2VsbCANCmtub3duIGZv ciBxdWl0ZSBzb21lIHRpbWUgYW5kIGltcGxlbWVudGVkIGluIHRoZSBpUGhvbmUuIEl0IG1ha2Vz IHVzZSBvZiBhIE0zVSANCnBsYXlsaXN0IGZpbGUgd2hpY2ggc2VydmVzIGFzIG1hbmlmZXN0IGFu ZCBlYWNoIG1lZGlhIGZpbGUgbXVzdCBiZSBmb3JtYXR0ZWQgYXMgDQphbiBNUEVHLTIgVHJhbnNw b3J0IFN0cmVhbSBvciBhbiBNUEVHLTIgYXVkaW8gZWxlbWVudGFyeSBzdHJlYW0uIA0KPEJSPk1v dnN0cmVhbWluZzogaXMgYWxyZWFkeSBkZXBsb3llZCBidXQgYWxzbyBoaWdobHkgcHJvcHJpZXRh cnkuIEhvd2V2ZXIsIGl0IA0Kd29ya3Mgd2l0aCBjb21tb24gbWVkaWEgcGxheWVycy4gPEJSPlRo ZSByZWxhdGVkIHdvcmsgaXMgYXZhaWFibGUgDQphdDo8QlI+PC9GT05UPjxBIA0KaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFudG9zLWh0dHAtbGl2ZS1zdHJlYW1pbmct MDQiPjxGT05UIA0Kc2l6ZT0zIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wYW50b3MtaHR0cC1saXZlLXN0cmVhbWluZy0wNDwvRk9OVD48 L0E+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KGIpLiBJRVRGOiBXZWJzb2NrZXQgcHJvdG9jb2wg DQo8RElWPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZvY3VzIG9uIGJyb3dz aW5nIGFjY2VsZXJhdGlvbiwgDQpkZXZsb3BlZCBieSBIeWJpIFdHLEFzIG9uZSBjb21wbGVtZW50 YXJ5IHdvcmssIFczQyBzdGFuZGFyZGl6ZSB3ZWJzb2NrZXQgDQpBUEk8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9MiBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElWPjwvRElWPg0KPERJ Vj4oYykuVzNDJyBmb2N1cyBvbiBjbGllbnQgaW1wbGVudGF0aW9uIGJ1bGl0IGludG8gYnJvd3Nl cixlLmcuLCB2aWRlbyANCnBsYXliYWNrIHN1cHBvcnQgdXNpbmcgc2NyaXB0IGFuZCBodG1sLCBw dXNoIG5vdGlmaWNhdGlvbiBzdXBwb3J0IHVzaW5nIEFQSSwgDQp2aWRlbyBzdXBwb3J0IHVzaW5n IE1lZGlhIGZyYWdtZW50cyBVUkkuPC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPcvOzOU+ PC9GT05UPiZuYnNwOzwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4oZCkuM0dQUHMnIEFkYXB0aXZlIEhUVFAgU3RyZWFtaW5nIChBSFMpOiANCjxC Uj5pbnRyb2R1Y2VkIHJlY2VudGx5IHdoaWNoIGRlZmluZXMgYSBNZWRpYSBQcmVzZW50YXRpb24g RGVzY3JpcHRpb24gKE1EUCkgDQo8QlI+YW5kIGV4dGVuc2lvbnMgdG8gdGhlIHdlbGwga25vd24g SVNPIEJhc2UgTWVkaWEgRmlsZSBGb3JtYXQuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+KGUpLk9wZW4gSVBUViBGb3J1bSAoT0lQRik6IDxCUj5oYXMgYmVl biANCnB1Ymxpc2hlZCBvbiBTZXAgN3RoLCAyMDEwIGluY2x1ZGluZyAiSFRUUCBBZGFwdGl2ZSBT dHJlYW1pbmciIHdoaWNoIGFkb3B0cyAzR1BQIA0KQUhTIGFuZCBhZGRzIHN1cHBvcnQgZm9yIE1Q RUctMiBUcmFuc3BvcnQgU3RyZWFtLiBUaGUgcmVsYXRlZCB3b3JrIGlzIGF2YWlsYWJsZSANCmF0 OjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+KGYpLk1QRUcn IEhUVFAgU3RyZWFtaW5nIG9mIE1QRUcgTWVkaWEgOiANCjxCUj5NUEVHIGhhcyBwdWJsaXNoZWQg VXNlcyBDYXNlcyBmb3IgSFRUUCBTdHJlYW1pbmcgb2YgTVBFRyBNZWRpYSBhbmQgDQpSZXF1aXJl bWVudHMgb24gSFRUUCBTdHJlYW1pbmcgb2YgTVBFRyBNZWRpYS4gVGhlIG5leHQgc3RwZSBpcyB0 byBzdGFuZGFyZGl6ZSBhIA0Kc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlIG5lZWQgb24gaG93 IHRvIGVtcGxveSBIVFRQIFN0cmVhbWluZyB0byBzdXBwb3J0IE1QRUcgDQpNRWRpYS5UaGVyZWZv cmUgTVBHRSBpc3N1ZWQgYSBjYWxsIGZvciBwcm9wb3NhbHMgb24gSFRUUCBzdHJlYW1pbmcgb2Yg TVBFRyANCm1lZGlhLjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+VGhlcmVmb3JlIFN0YW5kYXJkaXp0aW9uIHJlbGF0ZWQgdG8gdGhpcyANCndvcmsm bmJzcDtuZWVkcyB0byBiZSZuYnNwO2NhcnJpZWQgb3V0IGpvaW50IGJ5IElFVEYvVzNDLzNHUFAg LiBPdmVybGFwcGluZyB3b3JrIA0KYW5kIGVmZm9ydHMgd2lsbCBiZSBjb250cmlidXRlZCB0byBh bmQgc3luY2hyb25pemVkIDxCUj53aXRoIHRoZXNlIG90aGVyIA0KcmVsZXZhbnQgZ3JvdXBzLjwv Rk9OVD48Rk9OVCBzaXplPTI+PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtd3UtaHR0cC1zdHJlYW1pbmctb3B0aW1pemF0aW9uLXBzLTAwIj48 L0E+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4z LiBHaXZlbiB2YXJpb3VzIG9uZ2luZyB3b3JrIGluIG90aGVyIFNET3MgDQp0aGFuIElFVEYmbmJz cDthbmQgdmFpcm91cyBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIGRldmVsb3BlZCBieSBpbmR1 c3RyaWVzIA0KKGUuZy4sQXBwbGUsIE1pY3Jvc29mdCwgQWRvYmUsIFJlYWxOZXR3b3JrKSwgd2hh dCBjb250cmlidXRpb24gSUVURiBjb3VsZCANCm1ha2U/PC9GT05UPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+V2hhdCdzIHRoZSBwb3RlbnRpYWwgd29yayBpdGVtPyB3aGF0IA0Ka2luZCBv ZiBwcm9ibGVtIGRvIHdlIG5lZWQgdG8gc29sdmU/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj5ZZXMsIGl0IGlzIGNsZWFyIElFVEYgZm9sa3MgaGFzIGV4cGVy dGlzZSB0byANCmRvIHRoaXMgd29yay4gVGhlIHBvdGVudGlhbCBwcm9ibGVtcyBhbmQgaXNzdWVz Jm5ic3A7dGhlIElFVEYgZm9sa3MgYXJlIA0KaW50ZXJlc3RlZCB0byBsb29rIGF0IGFuZCBkaXNj dXNzIGFyZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ KGEpLiBJc3N1ZXMgaW52b2x2aW5nIHJlYWwtdGltZSBjb25zaWRlcmF0aW9ucyANCmFuZCBpbnRl cm9wZXJhYmlsaXR5IHdpdGggb3RoZXIgc3RyZWFtaW5nIHRlY2huaXF1ZXM8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+KGIpLiBDb25zaWRlcmF0aW9uIG9m IHRyYW5zcG9ydGlzc3VlcyANCihmYWlybmVzcywgZGVsYXksIGV0Yy4pPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPihjKS4gVHdlYWtpbmcgSFRUUCB0byBp bXByb3ZlIHN0cmVhbWluZyANCnBlcmZvcm1hbmNlPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPihkKS5HdWlkYW5jZSBvbiBob3cgdG8gdXNlIEhUVFAgaW4g YSANCm5ldHdvcmstZnJpZW5kbHkgd2F5LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4oZSkuIENvb3JkaW5hdGlvbiB3aXRoIG90aGVyIHByb3RvY29scyAN CmRldmVsb3BlZCBieSBJRVRGLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4oZikuIE9mZmVyIGJldHRlciB0cmFuc3BvcnQgYmV0dGVyIHRoYW4gVENQIA0K KGxpa2UgU0NUUCksIGJldHRlciB0YWlsb3JlZCBmb3IgdGhlIG5lZWRzIGZvciBzdHJlYW1pbmcg b3ZlciBodHRwLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4oZykuIGhvdyB0byB3b3JrIGluIGVudmlyb25tZW50cyB0aGF0IG1heSB1c2UgDQphIGNvbWJp bmF0aW9uIG9mIFJUUCBtdWx0aWNhc3QgYW5kIEhUVFAgdW5pY2FzdC48QlI+KGgpLiBIb3cgdG8g ZGVsaXZlciANCnN0cmVhbWluZyBjb250ZW50cyB0byB0aGUgY2xpZW50IG9uIGFueSBkZXZpY2Ug d2l0aCB0aGUgc2FtZSBUViBRdWFsaXR5IG9mIA0KRXhwZXJpZW5jZS48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+QXMgZm9yIHBsYXlsaXN0IGZvcm1hdCBh bmQgc3RyZWFtaW5nIGZpbGUgDQpmb3JtYXQsIHRoZXNlIHdvcmtzIGhhdmUgYmVlbiBzcGVjaWZp ZWQgYnkgM0dQUCwgZm9sbG93ZWQgYnkgTVBFRy9PSVBGLHByb2JhYmx5IA0Kbm90IHRoZSBpbnRl cmVzdGluZyBwaWVjZSBmb3IgdGhlIElFVEZlcnM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPklmIEkgbWlzcyBzb21ldGhpbmcgb3IgeW91IGhhdmUgYW55IGZ1 cnRoZXIgDQppbnB1dHMgYW5kIHN1Z2dlc3Rpb25zL2NvbW1lbnRzLCBwbGVhc2Ugc3BlYWsgdXAg b24gdGhlIGxpc3QuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPkJhc2VkIG9uIHRoZXNlIGlucHV0cyBhbmQgcHJvcG9zYWxzLCBJIHdvdWxkIA0KbGlrZSB0 byBzaGFyZSBvdXIgdGhvdWdodHMgdGh1cyBmYXIgb24gd2hhdCZuYnNwOyBhIG5ldyBjaGFydGVy IA0KbWlnaHQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ bG9vayBsaWtlIGFuZCB3aWxsIHBvc3QgaW4gYSBzZXBhcmF0ZSBlbWFpbCB0byANCnRoaXMgZGlz Y3Vzc2lvbiBsaXN0LiBUaGUgZmVlZGJhY2sgd291bGQgYmUgaGlnaGx5IHVzZWZ1bCBhdCB0aGlz IA0KcG9pbnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5C VFc6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlNpbmNl IHdlIGhhdmUgY3JlYXRlZCBzZXBhcmF0ZWQgbWFpbGluZyBsaXN0IA0KZm9yIHRoaXMgdG9waWMs IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy9pZGVhcy9wcm9wb3NhbHMgdG8gc2hhcmUsIHBsZWFz ZSANCnBvc3Q8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ dGhlbSB0byB0aGUgbmV3IGRpc2N1c3Npb24mbmJzcDsgDQpsaXN0LjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+UmVnYXJkcyE8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+LVFpbjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_yssMswj13iWO0rUw1Lckkg)-- From allyn@cisco.com Fri Sep 24 21:56:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCF63A68BB; Fri, 24 Sep 2010 21:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.088 X-Spam-Level: X-Spam-Status: No, score=-10.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEDpwvSDjv2B; Fri, 24 Sep 2010 21:56:35 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 25BA73A67D4; Fri, 24 Sep 2010 21:56:35 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMkdnUyrR7Ht/2dsb2JhbACiRnGnYpwahUMEhFCIbg X-IronPort-AV: E=Sophos;i="4.57,233,1283731200"; d="scan'208";a="191799086" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 25 Sep 2010 04:57:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8P4v8Qj012566; Sat, 25 Sep 2010 04:57:08 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Sep 2010 21:57:08 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Sep 2010 21:57:06 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02849736@xmb-sjc-221.amer.cisco.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <440B4A6C-69BE-499B-8ADB-F52BF590D559@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Displaying side by side video streamsdraft-jennings-mmusic-adjacent-grouping Thread-Index: ActZxipv3Q/7inppRTmCYx5B3iRIZgCRzIAg References: <20100921194157.369A93A672F@core3.amsl.com> <440B4A6C-69BE-499B-8ADB-F52BF590D559@cisco.com> From: "Allyn Romanow (allyn)" To: "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 25 Sep 2010 04:57:08.0538 (UTC) FILETIME=[1B5C41A0:01CB5C6E] Cc: DISPATCH list , mmusic@ietf.org Subject: Re: [dispatch] [MMUSIC] Displaying side by side video streamsdraft-jennings-mmusic-adjacent-grouping X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 04:56:36 -0000 Hi Cullen, Your suggested approach seems promising - to use grouping, but the problem you are focused on seems to me to be just one aspect of what is necessary to address if you want to handle multiple streams in a Telepresence conference. I wonder how you see this proposal in relation to the proposed Telepresence work currently under charter discussion in DISPATCH?=20 Given your example application is multiple screen Telepresence systems, it seems like there is considerable overlap.=20 I'm cc'ing the DISPATCH list as some folks there who might be interested may not follow mmusic. Best- Allyn -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Tuesday, September 21, 2010 12:49 PM To: MMUSIC WG Subject: [MMUSIC] Displaying side by side video streamsdraft-jennings-mmusic-adjacent-grouping I just submitted a draft on using the SDP grouping framework to indicate when multiple media streams should be rendered side by side. It a pretty trivial draft but I'd love to get some comments on it.=20 http://www.ietf.org/id/draft-jennings-mmusic-adjacent-grouping-00.txt Thanks, Cullen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From paulej@packetizer.com Mon Sep 27 07:22:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD953A6BAF; Mon, 27 Sep 2010 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPpm3lIhe4pq; Mon, 27 Sep 2010 07:22:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 5558E3A6AFF; Mon, 27 Sep 2010 07:22:50 -0700 (PDT) Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o8REMX55015490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Sep 2010 10:22:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1285597361; bh=EAIgOvR9OHDtYz+v9rQ5qVsYDEM+38OhUHpSis12zU8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=DHpHLOynSeTRvWq3GVX3L9rHPL6ccNk8IPtcdsHvXZLKx1DiDWvLzmpepebqJDgPm kUp3TS/elWzDfiuMkFkMBKgitSZ6EHe0qGbSPBcGzMHTn4Bu0il1A7X2odR60O0xKi Sl5NSGHOG+dhmt4ChUPuTXtFhIiCg73FakSp862Y= From: "Paul E. Jones" To: "'Cullen Jennings'" , Date: Mon, 27 Sep 2010 10:22:30 -0400 Message-ID: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: ActeT2qZakrYB/OQSKO2MbpTvRC4zw== Content-Language: en-us Cc: sip-ops@ietf.org, 'Hadriel Kaplan' Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 14:22:57 -0000 Folks, I just wanted to bring this draft to everyone's attention again. What should we do with it? Should we modify this to be informational or pursue a standards track draft? Several have expressed an interest in seeing this go forward in some form to help ensure better interoperability, but the list has been fairly silent. Here's the draft: http://tools.ietf.org/html/draft-jones-sip-options-ping Thanks, Paul > -----Original Message----- > From: sip-ops-bounces@ietf.org [mailto:sip-ops-bounces@ietf.org] On Behalf > Of Paul E. Jones > Sent: Friday, August 13, 2010 12:37 AM > To: 'Cullen Jennings'; dispatch@ietf.org > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > Cullen, > > Thanks for the suggestion. > > All, > > Please see the note below. We're seeking advice on how to proceed with > the subject draft. > > Paul > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Thursday, August 12, 2010 11:44 PM > > To: Paul E. Jones > > Cc: sip-ops@ietf.org; Hadriel Kaplan > > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > > > > I think you discuss how to move forward with this draft on dispatch > > mailing list given that's the point of that list is help with problems > > like this. > > > > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > > > > > Folks, > > > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring > > > some > > consistency to the way in which SIP user agents implement an OPTIONS > > "ping" procedure. It seems that a very large number of vendors do > > this, but unfortunately, there seems to be little consistency. > > > > > > Initially, we positioned the document as a standards track RFC, > > > since > > this essentially builds on RFC 3261. However, there was some pushback > > from folks in the IETF for a variety of reasons, not the least of > > which is the fact that there is no working group chartered to do the > > work. We don't feel this one draft warrants the creation of a working > group. > > > > > > So, we've got three options we can consider: > > > 1) Forge ahead outside of a working group > > > 2) Change the status of the draft to Informational > > > 3) Forget about the draft and let every SIP device do it the way > > they want, throwing hope of consistency out the window > > > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > > > In any case, I'd like to get feedback from the on the SIP operators > > > and > > SIP implementers lists. Do you think it's worth trying to address > > this issue? If so, which option do you think we should pursue? > > > > > > Note that we're certainly open to feedback on the draft. I'd prefer > > > it > > to have a few more "MUST" statements in the text, rather than "SHOULD". > > But, we need to find that right balance: > > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > > > Paul > > > > > > _______________________________________________ > > > sip-ops mailing list > > > sip-ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-ops > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > _______________________________________________ > sip-ops mailing list > sip-ops@ietf.org > https://www.ietf.org/mailman/listinfo/sip-ops From Marius.Zbihlei@1and1.ro Mon Sep 27 08:27:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581403A6D5E; Mon, 27 Sep 2010 08:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjZDij44Bwbf; Mon, 27 Sep 2010 08:27:24 -0700 (PDT) Received: from mxintern.schlund.de (mxintern.schlund.de [212.227.126.204]) by core3.amsl.com (Postfix) with ESMTP id B925D3A6D3A; Mon, 27 Sep 2010 08:27:24 -0700 (PDT) Received: from [10.2.3.44] (helo=exnlb02.webde.local) by mxintern.schlund.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1P0FcX-0006CX-Be; Mon, 27 Sep 2010 17:28:01 +0200 Received: from exchange03.webde.local ([169.254.1.28]) by exnlb02.webde.local ([10.2.3.44]) with mapi; Mon, 27 Sep 2010 17:27:55 +0200 From: Marius Zbihlei To: "Paul E. Jones" , 'Cullen Jennings' , "dispatch@ietf.org" Date: Mon, 27 Sep 2010 17:23:50 +0200 Thread-Topic: [dispatch] SIP OPTIONS "ping" Thread-Index: ActeT2qZakrYB/OQSKO2MbpTvRC4zwACJH0H Message-ID: References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> In-Reply-To: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-UI-Msg-Verification: 0919c18a577aa482f10f23c4a4bd0d2e Cc: "sip-ops@ietf.org" , 'Hadriel Kaplan' Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 15:27:26 -0000 Hello, I have some observations: 1.What happens if the sender never receives a reply (locally generated 408)= because the endpoint is down? Shouldn't this be treated as a 503?(I presum= e the OPTION is sent stateful ) 2.As a minimum time interval in section 7, I recommend 32 seconds (or 64*T1= ) as to ensure a transaction times out before a retry....=20 Marius ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul E. Jones [paulej@packetizer.com] Sent: Monday, September 27, 2010 4:22 PM To: 'Cullen Jennings'; dispatch@ietf.org Cc: sip-ops@ietf.org; 'Hadriel Kaplan' Subject: Re: [dispatch] SIP OPTIONS "ping" Folks, I just wanted to bring this draft to everyone's attention again. What should we do with it? Should we modify this to be informational or pursue = a standards track draft? Several have expressed an interest in seeing this g= o forward in some form to help ensure better interoperability, but the list has been fairly silent. Here's the draft: http://tools.ietf.org/html/draft-jones-sip-options-ping Thanks, Paul > -----Original Message----- > From: sip-ops-bounces@ietf.org [mailto:sip-ops-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: Friday, August 13, 2010 12:37 AM > To: 'Cullen Jennings'; dispatch@ietf.org > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > Cullen, > > Thanks for the suggestion. > > All, > > Please see the note below. We're seeking advice on how to proceed with > the subject draft. > > Paul > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Thursday, August 12, 2010 11:44 PM > > To: Paul E. Jones > > Cc: sip-ops@ietf.org; Hadriel Kaplan > > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > > > > I think you discuss how to move forward with this draft on dispatch > > mailing list given that's the point of that list is help with problems > > like this. > > > > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > > > > > Folks, > > > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring > > > some > > consistency to the way in which SIP user agents implement an OPTIONS > > "ping" procedure. It seems that a very large number of vendors do > > this, but unfortunately, there seems to be little consistency. > > > > > > Initially, we positioned the document as a standards track RFC, > > > since > > this essentially builds on RFC 3261. However, there was some pushback > > from folks in the IETF for a variety of reasons, not the least of > > which is the fact that there is no working group chartered to do the > > work. We don't feel this one draft warrants the creation of a working > group. > > > > > > So, we've got three options we can consider: > > > 1) Forge ahead outside of a working group > > > 2) Change the status of the draft to Informational > > > 3) Forget about the draft and let every SIP device do it the way > > they want, throwing hope of consistency out the window > > > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > > > In any case, I'd like to get feedback from the on the SIP operators > > > and > > SIP implementers lists. Do you think it's worth trying to address > > this issue? If so, which option do you think we should pursue? > > > > > > Note that we're certainly open to feedback on the draft. I'd prefer > > > it > > to have a few more "MUST" statements in the text, rather than "SHOULD". > > But, we need to find that right balance: > > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > > > Paul > > > > > > _______________________________________________ > > > sip-ops mailing list > > > sip-ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-ops > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > _______________________________________________ > sip-ops mailing list > sip-ops@ietf.org > https://www.ietf.org/mailman/listinfo/sip-ops _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Tue Sep 28 19:31:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7603A6BBD for ; Tue, 28 Sep 2010 19:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXV6E7sOpgbL for ; Tue, 28 Sep 2010 19:30:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 472D33A6A21 for ; Tue, 28 Sep 2010 19:30:59 -0700 (PDT) Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o8T2VRPB018512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Sep 2010 22:31:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1285727494; bh=BlDXPPv48Pc/DyHBRoLrgBtFMj6Dpz9fkCIM8mjJNgo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Wi0KbheV2WZbqwmN2ADUK+vYOF4ShfTvYZ6zoAUYiSadXiSCkX26XdEjZPUt4Naw7 z8mmhR93293DCE+V6d82Mo0FALh8IwjlER59fnqiSnuB4yLChU/3lyo1v6LUrx8uLv elm7bfZ1OmvjqrYNFGqHIwOF89kjo3sFAX7J5cmA= From: "Paul E. Jones" To: "'Marius Zbihlei'" , References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> In-Reply-To: Date: Tue, 28 Sep 2010 22:31:22 -0400 Message-ID: <061301cb5f7e$6c07a730$4416f590$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJaSZUE8HG75aFNC/W7CpF1Fy1R6AIk9fFCkfk+/cA= Content-Language: en-us Cc: 'Hadriel Kaplan' Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 02:31:04 -0000 Marius, To answer your questions: 1) Yes, I believe that's a reasonable thing to do. As for state, since this is a simple next-hop message, why introduce state? 2) Retry times are tough to prescribe, since different networks have very different requirements. Some of the timers in SIP are out of this world, really: a normal user would hang up the phone well before the time the timers are expire. The use of OPTIONS as prescribed in this document may need to have faster response times than 32s. Personally, I'd rather leave this one open for the administrator to specify, but if the group would like to nail down a recommended default, I can do that. I'm collecting a number of comments on this draft, but what I really would like to know right away is "what shall we do with it"? Do we want to pursue publishing this as an informational document or a standards track RFC? Paul > -----Original Message----- > From: Marius Zbihlei [mailto:Marius.Zbihlei@1and1.ro] > Sent: Monday, September 27, 2010 11:24 AM > To: Paul E. Jones; 'Cullen Jennings'; dispatch@ietf.org > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > Subject: RE: [dispatch] SIP OPTIONS "ping" > > Hello, > > I have some observations: > > 1.What happens if the sender never receives a reply (locally generated > 408) because the endpoint is down? Shouldn't this be treated as a 503?(I > presume the OPTION is sent stateful ) 2.As a minimum time interval in > section 7, I recommend 32 seconds (or 64*T1) as to ensure a transaction > times out before a retry.... > > > Marius > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of > Paul E. Jones [paulej@packetizer.com] > Sent: Monday, September 27, 2010 4:22 PM > To: 'Cullen Jennings'; dispatch@ietf.org > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > Subject: Re: [dispatch] SIP OPTIONS "ping" > > Folks, > > I just wanted to bring this draft to everyone's attention again. What > should we do with it? Should we modify this to be informational or pursue > a standards track draft? Several have expressed an interest in seeing > this go forward in some form to help ensure better interoperability, but > the list has been fairly silent. > > Here's the draft: > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > Thanks, > Paul > > > -----Original Message----- > > From: sip-ops-bounces@ietf.org [mailto:sip-ops-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Friday, August 13, 2010 12:37 AM > > To: 'Cullen Jennings'; dispatch@ietf.org > > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > > Cullen, > > > > Thanks for the suggestion. > > > > All, > > > > Please see the note below. We're seeking advice on how to proceed > > with the subject draft. > > > > Paul > > > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > Sent: Thursday, August 12, 2010 11:44 PM > > > To: Paul E. Jones > > > Cc: sip-ops@ietf.org; Hadriel Kaplan > > > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > > > > > > > I think you discuss how to move forward with this draft on dispatch > > > mailing list given that's the point of that list is help with > > > problems like this. > > > > > > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > > > > > > > Folks, > > > > > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring > > > > some > > > consistency to the way in which SIP user agents implement an OPTIONS > > > "ping" procedure. It seems that a very large number of vendors do > > > this, but unfortunately, there seems to be little consistency. > > > > > > > > Initially, we positioned the document as a standards track RFC, > > > > since > > > this essentially builds on RFC 3261. However, there was some > > > pushback from folks in the IETF for a variety of reasons, not the > > > least of which is the fact that there is no working group chartered > > > to do the work. We don't feel this one draft warrants the creation > > > of a working > > group. > > > > > > > > So, we've got three options we can consider: > > > > 1) Forge ahead outside of a working group > > > > 2) Change the status of the draft to Informational > > > > 3) Forget about the draft and let every SIP device do it the > way > > > they want, throwing hope of consistency out the window > > > > > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > > > > > In any case, I'd like to get feedback from the on the SIP > > > > operators and > > > SIP implementers lists. Do you think it's worth trying to address > > > this issue? If so, which option do you think we should pursue? > > > > > > > > Note that we're certainly open to feedback on the draft. I'd > > > > prefer it > > > to have a few more "MUST" statements in the text, rather than > "SHOULD". > > > But, we need to find that right balance: > > > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > > > > > Paul > > > > > > > > _______________________________________________ > > > > sip-ops mailing list > > > > sip-ops@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sip-ops > > > > > > > > > Cullen Jennings > > > For corporate legal information go to: > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > _______________________________________________ > > sip-ops mailing list > > sip-ops@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-ops > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Wed Sep 29 05:28:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9B13A6C17 for ; Wed, 29 Sep 2010 05:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE1280udGEFd for ; Wed, 29 Sep 2010 05:28:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 403F33A6A6B for ; Wed, 29 Sep 2010 05:28:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAK/NokxAZnwM/2dsb2JhbACUHI4Dcak+nHKFRASKOoJ/ X-IronPort-AV: E=Sophos;i="4.57,253,1283731200"; d="scan'208";a="164759401" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2010 12:29:04 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8TCT45s026474 for ; Wed, 29 Sep 2010 12:29:04 GMT Message-ID: <4CA33110.3020807@cisco.com> Date: Wed, 29 Sep 2010 08:29:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 12:28:22 -0000 On 9/27/2010 11:23 AM, Marius Zbihlei wrote: > Hello, > > I have some observations: > > 1.What happens if the sender never receives a reply (locally generated 408) because the endpoint is down? Shouldn't this be treated as a 503?(I presume the OPTION is sent stateful ) I don't understand what you are asking. If you send a request (any request, not just OPTIONS), and no reply is received, your stack is expected to give you an indication comparable to a 408 response. Are you asking what you should do if your stack doesn't do that? And in any case, a 408 is a 408, not a 503. Timeouts can happen for many reasons unrelated to overload of the UAS. Thanks, Paul From Marius.Zbihlei@1and1.ro Wed Sep 29 06:59:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1913A6EC8 for ; Wed, 29 Sep 2010 06:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zo3xDiDvt0s for ; Wed, 29 Sep 2010 06:59:26 -0700 (PDT) Received: from mxintern.schlund.de (mxintern.schlund.de [212.227.126.205]) by core3.amsl.com (Postfix) with ESMTP id C8B0E3A6EC2 for ; Wed, 29 Sep 2010 06:59:25 -0700 (PDT) Received: from [10.2.3.44] (helo=exnlb02.webde.local) by mxintern.schlund.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1P0xCa-0003xi-Cm; Wed, 29 Sep 2010 16:00:08 +0200 Received: from exchange03.webde.local ([169.254.1.28]) by exnlb02.webde.local ([10.2.3.44]) with mapi; Wed, 29 Sep 2010 16:00:08 +0200 From: Marius Zbihlei To: Paul Kyzivat , "dispatch@ietf.org" Date: Wed, 29 Sep 2010 15:57:41 +0200 Thread-Topic: [dispatch] SIP OPTIONS "ping" Thread-Index: Actf0etAUCwlb8yNR8Wn2N5OBtRF/wADFzje Message-ID: References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> , <4CA33110.3020807@cisco.com> In-Reply-To: <4CA33110.3020807@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-UI-Msg-Verification: b9ca216573099576ff663a972c613856 Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:59:27 -0000 Hello, To put it simply, what happens if the OPTION request is responded with a 40= 8(generated locally)... In my opinion we should treat it as a 503, but I se= e that you think it should be treated differently. Marius ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] Sent: Wednesday, September 29, 2010 2:29 PM To: dispatch@ietf.org Subject: Re: [dispatch] SIP OPTIONS "ping" On 9/27/2010 11:23 AM, Marius Zbihlei wrote: > Hello, > > I have some observations: > > 1.What happens if the sender never receives a reply (locally generated 40= 8) because the endpoint is down? Shouldn't this be treated as a 503?(I pres= ume the OPTION is sent stateful ) I don't understand what you are asking. If you send a request (any request, not just OPTIONS), and no reply is received, your stack is expected to give you an indication comparable to a 408 response. Are you asking what you should do if your stack doesn't do that? And in any case, a 408 is a 408, not a 503. Timeouts can happen for many reasons unrelated to overload of the UAS. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Wed Sep 29 08:50:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9A83A6C36 for ; Wed, 29 Sep 2010 08:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvbS5enVjN2Y for ; Wed, 29 Sep 2010 08:50:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2F3C53A6B38 for ; Wed, 29 Sep 2010 08:50:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAf9okxAZnwN/2dsb2JhbACiFnGqVZxuhUQEijqCfw X-IronPort-AV: E=Sophos;i="4.57,253,1283731200"; d="scan'208";a="165045851" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2010 15:50:49 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8TFomjx027609; Wed, 29 Sep 2010 15:50:49 GMT Message-ID: <4CA36058.5040809@cisco.com> Date: Wed, 29 Sep 2010 11:50:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Marius Zbihlei References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> , <4CA33110.3020807@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 15:50:10 -0000 On 9/29/2010 9:57 AM, Marius Zbihlei wrote: > Hello, > > To put it simply, what happens if the OPTION request is responded with a 408(generated locally)... In my opinion we should treat it as a 503, but I see that you think it should be treated differently. I am not an expert on the sip protocol state machines, timers, etc. For that you want Robert Sparks. But I'm quite sure 3261 has different rules for handling 408 and 503, so saying "treat 408 like 503" raises a red flag to me. If you are talking about doing something differently for 408 than 3261 says, then you are proposing a real revision to 3261. If you are talking about what tactics to use within the specs, that is fair game. Thanks, Paul > Marius > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Wednesday, September 29, 2010 2:29 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] SIP OPTIONS "ping" > > On 9/27/2010 11:23 AM, Marius Zbihlei wrote: >> Hello, >> >> I have some observations: >> >> 1.What happens if the sender never receives a reply (locally generated 408) because the endpoint is down? Shouldn't this be treated as a 503?(I presume the OPTION is sent stateful ) > > I don't understand what you are asking. > > If you send a request (any request, not just OPTIONS), and no reply is > received, your stack is expected to give you an indication comparable to > a 408 response. Are you asking what you should do if your stack doesn't > do that? > > And in any case, a 408 is a 408, not a 503. Timeouts can happen for many > reasons unrelated to overload of the UAS. > > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From bruno.chatras@orange-ftgroup.com Wed Sep 29 09:06:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FACA3A6CF5 for ; Wed, 29 Sep 2010 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXCh6FhCiLRh for ; Wed, 29 Sep 2010 09:06:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 8966A3A6B3D for ; Wed, 29 Sep 2010 09:06:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 14A31858003; Wed, 29 Sep 2010 18:10:27 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0C5BF858002; Wed, 29 Sep 2010 18:10:27 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Sep 2010 18:06:54 +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: Wed, 29 Sep 2010 18:06:56 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101E80F09@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <061301cb5f7e$6c07a730$4416f590$@packetizer.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP OPTIONS "ping" Thread-Index: AQJaSZUE8HG75aFNC/W7CpF1Fy1R6AIk9fFCkfk+/cCAAOWSgA== References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> <061301cb5f7e$6c07a730$4416f590$@packetizer.com> From: To: , , X-OriginalArrivalTime: 29 Sep 2010 16:06:54.0794 (UTC) FILETIME=[55E34AA0:01CB5FF0] Cc: HKaplan@acmepacket.com Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:06:16 -0000 Paul, To answer your inital question, yes! We should pursue publishing this = document, preferably as a standards track one. There are too many = proprietary variants of this in the field today... Bruno > -----Message d'origine----- > De : dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] De la part de Paul E. Jones > Envoy=E9 : mercredi 29 septembre 2010 04:31 > =C0 : 'Marius Zbihlei'; dispatch@ietf.org > Cc : 'Hadriel Kaplan' > Objet : Re: [dispatch] SIP OPTIONS "ping" >=20 > Marius, >=20 > To answer your questions: >=20 > 1) Yes, I believe that's a reasonable thing to do. As for=20 > state, since this is a simple next-hop message, why introduce state? > 2) Retry times are tough to prescribe, since different=20 > networks have very different requirements. Some of the=20 > timers in SIP are out of this world, > really: a normal user would hang up the phone well before the=20 > time the timers are expire. The use of OPTIONS as prescribed=20 > in this document may need to have faster response times than=20 > 32s. Personally, I'd rather leave this one open for the=20 > administrator to specify, but if the group would like to nail=20 > down a recommended default, I can do that. >=20 > I'm collecting a number of comments on this draft, but what I=20 > really would like to know right away is "what shall we do=20 > with it"? Do we want to pursue publishing this as an=20 > informational document or a standards track RFC? >=20 > Paul >=20 > > -----Original Message----- > > From: Marius Zbihlei [mailto:Marius.Zbihlei@1and1.ro] > > Sent: Monday, September 27, 2010 11:24 AM > > To: Paul E. Jones; 'Cullen Jennings'; dispatch@ietf.org > > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > > Subject: RE: [dispatch] SIP OPTIONS "ping" > >=20 > > Hello, > >=20 > > I have some observations: > >=20 > > 1.What happens if the sender never receives a reply=20 > (locally generated > > 408) because the endpoint is down? Shouldn't this be treated as a=20 > > 503?(I presume the OPTION is sent stateful ) 2.As a minimum time=20 > > interval in section 7, I recommend 32 seconds (or 64*T1) as=20 > to ensure=20 > > a transaction times out before a retry.... > >=20 > >=20 > > Marius > > ________________________________________ > > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org]=20 > On Behalf=20 > > Of Paul E. Jones [paulej@packetizer.com] > > Sent: Monday, September 27, 2010 4:22 PM > > To: 'Cullen Jennings'; dispatch@ietf.org > > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > > Subject: Re: [dispatch] SIP OPTIONS "ping" > >=20 > > Folks, > >=20 > > I just wanted to bring this draft to everyone's attention=20 > again. What=20 > > should we do with it? Should we modify this to be informational or=20 > > pursue a standards track draft? Several have expressed an=20 > interest in=20 > > seeing this go forward in some form to help ensure better=20 > > interoperability, but the list has been fairly silent. > >=20 > > Here's the draft: > > http://tools.ietf.org/html/draft-jones-sip-options-ping > >=20 > >=20 > > Thanks, > > Paul > >=20 > > > -----Original Message----- > > > From: sip-ops-bounces@ietf.org=20 > [mailto:sip-ops-bounces@ietf.org] On=20 > > > Behalf Of Paul E. Jones > > > Sent: Friday, August 13, 2010 12:37 AM > > > To: 'Cullen Jennings'; dispatch@ietf.org > > > Cc: sip-ops@ietf.org; 'Hadriel Kaplan' > > > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > > > > Cullen, > > > > > > Thanks for the suggestion. > > > > > > All, > > > > > > Please see the note below. We're seeking advice on how=20 > to proceed=20 > > > with the subject draft. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > > Sent: Thursday, August 12, 2010 11:44 PM > > > > To: Paul E. Jones > > > > Cc: sip-ops@ietf.org; Hadriel Kaplan > > > > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > > > > > > > > > > I think you discuss how to move forward with this draft on=20 > > > > dispatch mailing list given that's the point of that=20 > list is help=20 > > > > with problems like this. > > > > > > > > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > > > > > > > > > Folks, > > > > > > > > > > Gonzalo and I produced an Internet Draft aiming at trying to=20 > > > > > bring some > > > > consistency to the way in which SIP user agents implement an=20 > > > > OPTIONS "ping" procedure. It seems that a very large number of=20 > > > > vendors do this, but unfortunately, there seems to be=20 > little consistency. > > > > > > > > > > Initially, we positioned the document as a standards=20 > track RFC,=20 > > > > > since > > > > this essentially builds on RFC 3261. However, there was some=20 > > > > pushback from folks in the IETF for a variety of=20 > reasons, not the=20 > > > > least of which is the fact that there is no working group=20 > > > > chartered to do the work. We don't feel this one draft=20 > warrants=20 > > > > the creation of a working > > > group. > > > > > > > > > > So, we've got three options we can consider: > > > > > 1) Forge ahead outside of a working group > > > > > 2) Change the status of the draft to Informational > > > > > 3) Forget about the draft and let every SIP=20 > device do it the > > way > > > > they want, throwing hope of consistency out the window > > > > > > > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > > > > > > > In any case, I'd like to get feedback from the on the SIP=20 > > > > > operators and > > > > SIP implementers lists. Do you think it's worth trying=20 > to address=20 > > > > this issue? If so, which option do you think we should pursue? > > > > > > > > > > Note that we're certainly open to feedback on the draft. I'd=20 > > > > > prefer it > > > > to have a few more "MUST" statements in the text, rather than > > "SHOULD". > > > > But, we need to find that right balance: > > > > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > > > > > > > Paul > > > > > > > > > > _______________________________________________ > > > > > sip-ops mailing list > > > > > sip-ops@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sip-ops > > > > > > > > > > > > Cullen Jennings > > > > For corporate legal information go to: > > > >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > > > > > _______________________________________________ > > > sip-ops mailing list > > > sip-ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-ops > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From fluffy@cisco.com Wed Sep 29 13:17:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E093A6DEB for ; Wed, 29 Sep 2010 13:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjAz54lsgMB5 for ; Wed, 29 Sep 2010 13:17:16 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A6F4C3A6D68 for ; Wed, 29 Sep 2010 13:17:16 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,255,1283731200"; d="scan'208";a="262406347" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2010 20:18:01 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8TKGR1B002804; Wed, 29 Sep 2010 20:18:00 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02849736@xmb-sjc-221.amer.cisco.com> Date: Wed, 29 Sep 2010 14:18:00 -0600 Content-Transfer-Encoding: 7bit Message-Id: <7639F57E-C79F-4FD3-86D8-79E294ED0B0E@cisco.com> References: <20100921194157.369A93A672F@core3.amsl.com> <440B4A6C-69BE-499B-8ADB-F52BF590D559@cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02849736@xmb-sjc-221.amer.cisco.com> To: Allyn Romanow (allyn) X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] [MMUSIC] Displaying side by side video streamsdraft-jennings-mmusic-adjacent-grouping X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 20:17:17 -0000 Sent reply on MMUSIC list ... On Sep 24, 2010, at 10:57 PM, Allyn Romanow (allyn) wrote: > Hi Cullen, > > Your suggested approach seems promising - to use grouping, but the > problem you are focused on seems to me to be just one aspect of what is > necessary to address if you want to handle multiple streams in a > Telepresence conference. I wonder how you see this proposal in relation > to the proposed Telepresence work currently under charter discussion in > DISPATCH? > Given your example application is multiple screen Telepresence systems, > it seems like there is considerable overlap. > > I'm cc'ing the DISPATCH list as some folks there who might be interested > may not follow mmusic. > > Best- > Allyn > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Cullen Jennings (fluffy) > Sent: Tuesday, September 21, 2010 12:49 PM > To: MMUSIC WG > Subject: [MMUSIC] Displaying side by side video > streamsdraft-jennings-mmusic-adjacent-grouping > > > I just submitted a draft on using the SDP grouping framework to indicate > when multiple media streams should be rendered side by side. It a pretty > trivial draft but I'd love to get some comments on it. > > http://www.ietf.org/id/draft-jennings-mmusic-adjacent-grouping-00.txt > > Thanks, Cullen > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partr@cisco.com Wed Sep 29 17:36:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF053A6A6C for ; Wed, 29 Sep 2010 17:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=-3.948, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2oYh-J8vtar for ; Wed, 29 Sep 2010 17:36:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5A3413A6A0C for ; Wed, 29 Sep 2010 17:36:28 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloEAE94o0yQ/khNgWdsb2JhbAChQ2IVAQELCyIirVucToVEBIROiHI X-IronPort-AV: E=Sophos;i="4.57,257,1283731200"; d="scan'208,217";a="10374255" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 Sep 2010 00:37:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o8U0bBwk016112; Thu, 30 Sep 2010 00:37:11 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Sep 2010 06:07:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6037.9E45249A" Date: Thu, 30 Sep 2010 06:07:10 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP OPTIONS "ping" Thread-Index: Actf7iD5paP8psM5QbqKciJPi03etAAQ6Nct References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> , <4CA33110.3020807@cisco.com> <4CA36058.5040809@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Marius Zbihlei" X-OriginalArrivalTime: 30 Sep 2010 00:37:10.0915 (UTC) FILETIME=[9E849D30:01CB6037] Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 00:36:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6037.9E45249A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marius, =20 Adding to Paul comments, I'm looking for the reason why the next hop = (proxy) will respond with 408 in case Max forward is set to 1 in OPTIONS = as mentioned in Sec 5.1 of this draft. =20 Thanks Partha ________________________________ From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) Sent: Wed 9/29/2010 9:20 PM To: Marius Zbihlei Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP OPTIONS "ping" On 9/29/2010 9:57 AM, Marius Zbihlei wrote: > Hello, > > To put it simply, what happens if the OPTION request is responded with = a 408(generated locally)... In my opinion we should treat it as a 503, = but I see that you think it should be treated differently. I am not an expert on the sip protocol state machines, timers, etc. For that you want Robert Sparks. But I'm quite sure 3261 has different rules for handling 408 and 503, so saying "treat 408 like 503" raises a red flag to me. If you are talking about doing something differently for 408 than 3261 says, then you are proposing a real revision to 3261. If you are talking about what tactics to use within the specs, that is fair game. Thanks, Paul > Marius > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf = Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Wednesday, September 29, 2010 2:29 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] SIP OPTIONS "ping" > > On 9/27/2010 11:23 AM, Marius Zbihlei wrote: >> Hello, >> >> I have some observations: >> >> 1.What happens if the sender never receives a reply (locally = generated 408) because the endpoint is down? Shouldn't this be treated = as a 503?(I presume the OPTION is sent stateful ) > > I don't understand what you are asking. > > If you send a request (any request, not just OPTIONS), and no reply is > received, your stack is expected to give you an indication comparable = to > a 408 response. Are you asking what you should do if your stack = doesn't > do that? > > And in any case, a 408 is a 408, not a 503. Timeouts can happen for = many > reasons unrelated to overload of the UAS. > > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_001_01CB6037.9E45249A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] SIP OPTIONS "ping"=0A= =0A= =0A= =0A=
=0A=
Marius,
=0A=
 
=0A=
Adding to Paul comments, I'm = looking for the reason why the next hop (proxy) will respond = with 408 in case Max forward is set to 1 in OPTIONS as mentioned in Sec = 5.1 of this draft.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: dispatch-bounces@ietf.org on = behalf of Paul Kyzivat (pkyzivat)
Sent: Wed 9/29/2010 9:20 = PM
To: Marius Zbihlei
Cc: = dispatch@ietf.org
Subject: Re: [dispatch] SIP OPTIONS = "ping"

=0A=


=0A=

On 9/29/2010 9:57 AM, Marius Zbihlei wrote:
> = Hello,
>
> To put it simply, what happens if the OPTION = request is responded with a 408(generated locally)... In my opinion we = should treat it as a 503, but I see that you think it should be treated = differently.

I am not an expert on the sip protocol state = machines, timers, etc.
For that you want Robert Sparks.

But = I'm quite sure 3261 has different rules for handling 408 and 503, = so
saying "treat 408 like 503" raises a red flag to me. If you are = talking
about doing something differently for 408 than 3261 says, = then you are
proposing a real revision to 3261.

If you are = talking about what tactics to use within the specs, that is
fair = game.

        = Thanks,
        Paul

> = Marius
> ________________________________________
> From: = dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat [pkyzivat@cisco.com]
> Sent: Wednesday, September 29, 2010 = 2:29 PM
> To: dispatch@ietf.org
> Subject: Re: [dispatch] = SIP OPTIONS "ping"
>
> On 9/27/2010 11:23 AM, Marius Zbihlei = wrote:
>> Hello,
>>
>> I have some = observations:
>>
>> 1.What happens if the sender never = receives a reply (locally generated 408) because the endpoint is down? = Shouldn't this be treated as a 503?(I presume the OPTION is sent = stateful )
>
> I don't understand what you are = asking.
>
> If you send a request (any request, not just = OPTIONS), and no reply is
> received, your stack is expected to = give you an indication comparable to
> a 408 response. Are you = asking what you should do if your stack doesn't
> do = that?
>
> And in any case, a 408 is a 408, not a 503. = Timeouts can happen for many
> reasons unrelated to overload of = the = UAS.
>
>         = ; Thanks,
>          = Paul
> _______________________________________________
> = dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.= org/mailman/listinfo/dispatch
>
____________________________= ___________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------_=_NextPart_001_01CB6037.9E45249A-- From Marius.Zbihlei@1and1.ro Thu Sep 30 05:46:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83CE3A6C2C for ; Thu, 30 Sep 2010 05:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.584 X-Spam-Level: X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[AWL=1.664, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVK9yyNUU4ue for ; Thu, 30 Sep 2010 05:46:23 -0700 (PDT) Received: from mxintern.schlund.de (mxintern.schlund.de [212.227.126.204]) by core3.amsl.com (Postfix) with ESMTP id 142853A6918 for ; Thu, 30 Sep 2010 05:46:22 -0700 (PDT) Received: from [10.2.3.44] (helo=exnlb02.webde.local) by mxintern.schlund.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1P1IXT-0002Fq-Mt; Thu, 30 Sep 2010 14:47:07 +0200 Received: from exnlb12.webde.local (172.19.74.13) by exnlb02.webde.local (10.2.3.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Sep 2010 14:46:42 +0200 Received: from [172.28.124.38] (80.97.4.34) by smtp.extranet.1and1.com (217.72.200.71) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Sep 2010 14:46:41 +0200 Message-ID: <4CA48679.3060906@1and1.ro> Date: Thu, 30 Sep 2010 15:45:45 +0300 From: marius zbihlei User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100913 Icedove/3.0.7 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> , <4CA33110.3020807@cisco.com> <4CA36058.5040809@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070400090003010509060306" X-Virus-Scanned: Symantec AntiVirus Scan Engine X-UI-Msg-Verification: d74626f69007f16ac09549cd47bfbe6c Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 12:46:24 -0000 --------------070400090003010509060306 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 09/30/2010 03:37 AM, Parthasarathi R (partr) wrote: > Marius, > Adding to Paul comments, I'm looking for the reason why the next hop > (proxy) will respond with 408 in case Max forward is set to 1 in > OPTIONS as mentioned in Sec 5.1 of this draft. > Thanks > Partha > Hello, I was referring to a locally generated 408 (by the TM layer of the originating SIP Entity). This will mean that a answer from the queried entity was not received in 64*T1. For someone implementing a setup as described in this memo, I think the local 408 or the 503 can have the same meaning i.e. the endpoint is not able to respond to sip requests. Marius > ------------------------------------------------------------------------ > *From:* dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) > *Sent:* Wed 9/29/2010 9:20 PM > *To:* Marius Zbihlei > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] SIP OPTIONS "ping" > > > > On 9/29/2010 9:57 AM, Marius Zbihlei wrote: > > Hello, > > > > To put it simply, what happens if the OPTION request is responded > with a 408(generated locally)... In my opinion we should treat it as a > 503, but I see that you think it should be treated differently. > > I am not an expert on the sip protocol state machines, timers, etc. > For that you want Robert Sparks. > > But I'm quite sure 3261 has different rules for handling 408 and 503, so > saying "treat 408 like 503" raises a red flag to me. If you are talking > about doing something differently for 408 than 3261 says, then you are > proposing a real revision to 3261. > > If you are talking about what tactics to use within the specs, that is > fair game. > > Thanks, > Paul > > > Marius > > ________________________________________ > > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > > Sent: Wednesday, September 29, 2010 2:29 PM > > To: dispatch@ietf.org > > Subject: Re: [dispatch] SIP OPTIONS "ping" > > > > On 9/27/2010 11:23 AM, Marius Zbihlei wrote: > >> Hello, > >> > >> I have some observations: > >> > >> 1.What happens if the sender never receives a reply (locally > generated 408) because the endpoint is down? Shouldn't this be treated > as a 503?(I presume the OPTION is sent stateful ) > > > > I don't understand what you are asking. > > > > If you send a request (any request, not just OPTIONS), and no reply is > > received, your stack is expected to give you an indication comparable to > > a 408 response. Are you asking what you should do if your stack doesn't > > do that? > > > > And in any case, a 408 is a 408, not a 503. Timeouts can happen for many > > reasons unrelated to overload of the UAS. > > > > Thanks, > > Paul > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------070400090003010509060306 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 09/30/2010 03:37 AM, Parthasarathi R (partr) wrote:
Re: [dispatch] SIP OPTIONS "ping"
Marius,
 
Adding to Paul comments, I'm looking for the reason why the next hop (proxy) will respond with 408 in case Max forward is set to 1 in OPTIONS as mentioned in Sec 5.1 of this draft.
 
Thanks
Partha


Hello,

I was referring to a locally generated 408 (by the TM layer of the originating SIP Entity). This will mean that a answer from the queried entity was not received in 64*T1. For someone implementing a setup as described in  this memo, I think the local 408 or the 503 can have the same meaning i.e. the endpoint is not able to respond to sip requests.

Marius
From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat)
Sent: Wed 9/29/2010 9:20 PM
To: Marius Zbihlei
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP OPTIONS "ping"



On 9/29/2010 9:57 AM, Marius Zbihlei wrote:
> Hello,
>
> To put it simply, what happens if the OPTION request is responded with a 408(generated locally)... In my opinion we should treat it as a 503, but I see that you think it should be treated differently.

I am not an expert on the sip protocol state machines, timers, etc.
For that you want Robert Sparks.

But I'm quite sure 3261 has different rules for handling 408 and 503, so
saying "treat 408 like 503" raises a red flag to me. If you are talking
about doing something differently for 408 than 3261 says, then you are
proposing a real revision to 3261.

If you are talking about what tactics to use within the specs, that is
fair game.

        Thanks,
        Paul

> Marius
> ________________________________________
> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com]
> Sent: Wednesday, September 29, 2010 2:29 PM
> To: dispatch@ietf.org
> Subject: Re: [dispatch] SIP OPTIONS "ping"
>
> On 9/27/2010 11:23 AM, Marius Zbihlei wrote:
>> Hello,
>>
>> I have some observations:
>>
>> 1.What happens if the sender never receives a reply (locally generated 408) because the endpoint is down? Shouldn't this be treated as a 503?(I presume the OPTION is sent stateful )
>
> I don't understand what you are asking.
>
> If you send a request (any request, not just OPTIONS), and no reply is
> received, your stack is expected to give you an indication comparable to
> a 408 response. Are you asking what you should do if your stack doesn't
> do that?
>
> And in any case, a 408 is a 408, not a 503. Timeouts can happen for many
> reasons unrelated to overload of the UAS.
>
>          Thanks,
>          Paul
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--------------070400090003010509060306-- From pkyzivat@cisco.com Thu Sep 30 08:19:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4853A6C19 for ; Thu, 30 Sep 2010 08:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcNn+CR2pAZe for ; Thu, 30 Sep 2010 08:19:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3D8153A6C5A for ; Thu, 30 Sep 2010 08:19:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,259,1283731200"; d="scan'208";a="165263305" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Sep 2010 15:20:24 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8UFKN9R018560; Thu, 30 Sep 2010 15:20:24 GMT Message-ID: <4CA4AAB7.4030200@cisco.com> Date: Thu, 30 Sep 2010 11:20:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: marius zbihlei References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> , <4CA33110.3020807@cisco.com> <4CA36058.5040809@cisco.com> <4CA48679.3060906@1and1.ro> In-Reply-To: <4CA48679.3060906@1and1.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 15:19:42 -0000 On 9/30/2010 8:45 AM, marius zbihlei wrote: > On 09/30/2010 03:37 AM, Parthasarathi R (partr) wrote: >> Marius, >> Adding to Paul comments, I'm looking for the reason why the next hop >> (proxy) will respond with 408 in case Max forward is set to 1 in >> OPTIONS as mentioned in Sec 5.1 of this draft. >> Thanks >> Partha >> > > Hello, > > I was referring to a locally generated 408 (by the TM layer of the > originating SIP Entity). This will mean that a answer from the queried > entity was not received in 64*T1. For someone implementing a setup as > described in this memo, I think the local 408 or the 503 can have the > same meaning i.e. the endpoint is not able to respond to sip requests. If you get a 503, then you know that the message reached as far as the sender of the 503. If you infer a 408, then you know very little. There might have been a temporary glitch in the network, while the target system itself is fine. You may use similar tactics for these things, but they are not the *same*. Thanks, Paul > Marius >> ------------------------------------------------------------------------ >> *From:* dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) >> *Sent:* Wed 9/29/2010 9:20 PM >> *To:* Marius Zbihlei >> *Cc:* dispatch@ietf.org >> *Subject:* Re: [dispatch] SIP OPTIONS "ping" >> >> >> >> On 9/29/2010 9:57 AM, Marius Zbihlei wrote: >> > Hello, >> > >> > To put it simply, what happens if the OPTION request is responded >> with a 408(generated locally)... In my opinion we should treat it as a >> 503, but I see that you think it should be treated differently. >> >> I am not an expert on the sip protocol state machines, timers, etc. >> For that you want Robert Sparks. >> >> But I'm quite sure 3261 has different rules for handling 408 and 503, so >> saying "treat 408 like 503" raises a red flag to me. If you are talking >> about doing something differently for 408 than 3261 says, then you are >> proposing a real revision to 3261. >> >> If you are talking about what tactics to use within the specs, that is >> fair game. >> >> Thanks, >> Paul >> >> > Marius >> > ________________________________________ >> > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >> > Sent: Wednesday, September 29, 2010 2:29 PM >> > To: dispatch@ietf.org >> > Subject: Re: [dispatch] SIP OPTIONS "ping" >> > >> > On 9/27/2010 11:23 AM, Marius Zbihlei wrote: >> >> Hello, >> >> >> >> I have some observations: >> >> >> >> 1.What happens if the sender never receives a reply (locally >> generated 408) because the endpoint is down? Shouldn't this be treated >> as a 503?(I presume the OPTION is sent stateful ) >> > >> > I don't understand what you are asking. >> > >> > If you send a request (any request, not just OPTIONS), and no reply is >> > received, your stack is expected to give you an indication comparable to >> > a 408 response. Are you asking what you should do if your stack doesn't >> > do that? >> > >> > And in any case, a 408 is a 408, not a 503. Timeouts can happen for many >> > reasons unrelated to overload of the UAS. >> > >> > Thanks, >> > Paul >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From partr@cisco.com Thu Sep 30 12:21:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FEB3A6E0A for ; Thu, 30 Sep 2010 12:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.022 X-Spam-Level: X-Spam-Status: No, score=-9.022 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba8qArYpHxUA for ; Thu, 30 Sep 2010 12:21:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 45FE33A6E4E for ; Thu, 30 Sep 2010 12:21:25 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFADaApExAaMHG/2dsb2JhbAChTGNxqxOcNYVEBIRPiHM X-IronPort-AV: E=Sophos;i="4.57,261,1283731200"; d="scan'208,217";a="194273379" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 30 Sep 2010 19:22:11 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8UJM8rE004865; Thu, 30 Sep 2010 19:22:10 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 00:52:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB60D4.C64C140A" Date: Fri, 1 Oct 2010 00:52:08 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP OPTIONS "ping" Thread-Index: ActgswLE581tsbJiRjSJGtbz+9O8VgAIKJBV References: <020901cb5e4f$6fdb9540$4f92bfc0$@packetizer.com> , <4CA33110.3020807@cisco.com> <4CA36058.5040809@cisco.com> <4CA48679.3060906@1and1.ro> <4CA4AAB7.4030200@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "marius zbihlei" X-OriginalArrivalTime: 30 Sep 2010 19:22:09.0320 (UTC) FILETIME=[C6B3DA80:01CB60D4] Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 19:21:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB60D4.C64C140A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marius, =20 I agree with Paul for 408 behavior in the transaction layer. =20 I'm seeing OPTIONS Ping as an application on top of transaction layer. = In case of transaction timeout, this application infers that the next = hop is not reachable at this moment and start its other actions based on = the implemantation. For example: new INVITE will not be forwarded when = the transaction timeout for OPTIONS ping till the next OPTIONS ping is = suceeded. Having said that Transaction timeout has to be considered as = 408 in the transaction layer. Hope this clarifies.=20 =20 Thanks Partha ________________________________ From: Paul Kyzivat (pkyzivat) Sent: Thu 9/30/2010 8:50 PM To: marius zbihlei Cc: Parthasarathi R (partr); dispatch@ietf.org Subject: Re: [dispatch] SIP OPTIONS "ping" On 9/30/2010 8:45 AM, marius zbihlei wrote: > On 09/30/2010 03:37 AM, Parthasarathi R (partr) wrote: >> Marius, >> Adding to Paul comments, I'm looking for the reason why the next hop >> (proxy) will respond with 408 in case Max forward is set to 1 in >> OPTIONS as mentioned in Sec 5.1 of this draft. >> Thanks >> Partha >> > > Hello, > > I was referring to a locally generated 408 (by the TM layer of the > originating SIP Entity). This will mean that a answer from the queried > entity was not received in 64*T1. For someone implementing a setup as > described in this memo, I think the local 408 or the 503 can have the > same meaning i.e. the endpoint is not able to respond to sip requests. If you get a 503, then you know that the message reached as far as the sender of the 503. If you infer a 408, then you know very little. There might have been a temporary glitch in the network, while the target system itself is fine. You may use similar tactics for these things, but they are not the = *same*. Thanks, Paul > Marius >> = ------------------------------------------------------------------------ >> *From:* dispatch-bounces@ietf.org on behalf of Paul Kyzivat = (pkyzivat) >> *Sent:* Wed 9/29/2010 9:20 PM >> *To:* Marius Zbihlei >> *Cc:* dispatch@ietf.org >> *Subject:* Re: [dispatch] SIP OPTIONS "ping" >> >> >> >> On 9/29/2010 9:57 AM, Marius Zbihlei wrote: >> > Hello, >> > >> > To put it simply, what happens if the OPTION request is responded >> with a 408(generated locally)... In my opinion we should treat it as = a >> 503, but I see that you think it should be treated differently. >> >> I am not an expert on the sip protocol state machines, timers, etc. >> For that you want Robert Sparks. >> >> But I'm quite sure 3261 has different rules for handling 408 and 503, = so >> saying "treat 408 like 503" raises a red flag to me. If you are = talking >> about doing something differently for 408 than 3261 says, then you = are >> proposing a real revision to 3261. >> >> If you are talking about what tactics to use within the specs, that = is >> fair game. >> >> Thanks, >> Paul >> >> > Marius >> > ________________________________________ >> > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >> > Sent: Wednesday, September 29, 2010 2:29 PM >> > To: dispatch@ietf.org >> > Subject: Re: [dispatch] SIP OPTIONS "ping" >> > >> > On 9/27/2010 11:23 AM, Marius Zbihlei wrote: >> >> Hello, >> >> >> >> I have some observations: >> >> >> >> 1.What happens if the sender never receives a reply (locally >> generated 408) because the endpoint is down? Shouldn't this be = treated >> as a 503?(I presume the OPTION is sent stateful ) >> > >> > I don't understand what you are asking. >> > >> > If you send a request (any request, not just OPTIONS), and no reply = is >> > received, your stack is expected to give you an indication = comparable to >> > a 408 response. Are you asking what you should do if your stack = doesn't >> > do that? >> > >> > And in any case, a 408 is a 408, not a 503. Timeouts can happen for = many >> > reasons unrelated to overload of the UAS. >> > >> > Thanks, >> > Paul >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > ------_=_NextPart_001_01CB60D4.C64C140A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] SIP OPTIONS "ping"=0A= =0A= =0A= =0A=
=0A=
Marius,
=0A=
 
=0A=
I agree with Paul for 408 = behavior in the transaction layer.
=0A=
 
=0A=
=0A=
I'm seeing OPTIONS Ping as an = application on top of transaction layer. In case of transaction timeout, = this application infers that the next hop is not = reachable at this moment and start its other actions based on the = implemantation. For example: new INVITE will not be forwarded when the = transaction timeout for OPTIONS ping till the next OPTIONS ping is = suceeded. Having said that Transaction timeout has to be considered as 408 in the = transaction layer. Hope this clarifies. 
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Paul Kyzivat = (pkyzivat)
Sent: Thu 9/30/2010 8:50 PM
To: marius = zbihlei
Cc: Parthasarathi R (partr); = dispatch@ietf.org
Subject: Re: [dispatch] SIP OPTIONS = "ping"

=0A=


=0A=

On 9/30/2010 8:45 AM, marius zbihlei wrote:
> On = 09/30/2010 03:37 AM, Parthasarathi R (partr) wrote:
>> = Marius,
>> Adding to Paul comments, I'm looking for the reason = why the next hop
>> (proxy) will respond with 408 in case Max = forward is set to 1 in
>> OPTIONS as mentioned in Sec 5.1 of = this draft.
>> Thanks
>> = Partha
>>
>
> Hello,
>
> I was = referring to a locally generated 408 (by the TM layer of the
> = originating SIP Entity). This will mean that a answer from the = queried
> entity was not received in 64*T1. For someone = implementing a setup as
> described in this memo, I think the = local 408 or the 503 can have the
> same meaning i.e. the endpoint = is not able to respond to sip requests.

If you get a 503, then = you know that the message reached as far as the
sender of the = 503.

If you infer a 408, then you know very little. There might = have been a
temporary glitch in the network, while the target system = itself is fine.

You may use similar tactics for these things, but = they are not the = *same*.

        = Thanks,
        Paul

> = Marius
>> = ------------------------------------------------------------------------<= BR>>> *From:* dispatch-bounces@ietf.org on behalf of Paul Kyzivat = (pkyzivat)
>> *Sent:* Wed 9/29/2010 9:20 PM
>> *To:* = Marius Zbihlei
>> *Cc:* dispatch@ietf.org
>> = *Subject:* Re: [dispatch] SIP OPTIONS = "ping"
>>
>>
>>
>> On 9/29/2010 9:57 = AM, Marius Zbihlei wrote:
>> > Hello,
>> = >
>> > To put it simply, what happens if the OPTION = request is responded
>> with a 408(generated locally)... In my = opinion we should treat it as a
>> 503, but I see that you = think it should be treated differently.
>>
>> I am not = an expert on the sip protocol state machines, timers, etc.
>> = For that you want Robert Sparks.
>>
>> But I'm quite = sure 3261 has different rules for handling 408 and 503, so
>> = saying "treat 408 like 503" raises a red flag to me. If you are = talking
>> about doing something differently for 408 than 3261 = says, then you are
>> proposing a real revision to = 3261.
>>
>> If you are talking about what tactics to = use within the specs, that is
>> fair = game.
>>
>> Thanks,
>> = Paul
>>
>> > Marius
>> > = ________________________________________
>> > From: = dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On
>> = Behalf Of Paul Kyzivat [pkyzivat@cisco.com]
>> > Sent: = Wednesday, September 29, 2010 2:29 PM
>> > To: = dispatch@ietf.org
>> > Subject: Re: [dispatch] SIP OPTIONS = "ping"
>> >
>> > On 9/27/2010 11:23 AM, Marius = Zbihlei wrote:
>> >> Hello,
>> = >>
>> >> I have some observations:
>> = >>
>> >> 1.What happens if the sender never = receives a reply (locally
>> generated 408) because the = endpoint is down? Shouldn't this be treated
>> as a 503?(I = presume the OPTION is sent stateful )
>> >
>> > = I don't understand what you are asking.
>> >
>> = > If you send a request (any request, not just OPTIONS), and no reply = is
>> > received, your stack is expected to give you an = indication comparable to
>> > a 408 response. Are you asking = what you should do if your stack doesn't
>> > do = that?
>> >
>> > And in any case, a 408 is a 408, = not a 503. Timeouts can happen for many
>> > reasons = unrelated to overload of the UAS.
>> >
>> > = Thanks,
>> > Paul
>> > = _______________________________________________
>> > = dispatch mailing list
>> > dispatch@ietf.org
>> = > https://www.ietf.= org/mailman/listinfo/dispatch
>> >
>> = _______________________________________________
>> dispatch = mailing list
>> dispatch@ietf.org
>> https://www.ietf.= org/mailman/listinfo/dispatch
>>
>

------_=_NextPart_001_01CB60D4.C64C140A--