From jonathan@vidyo.com Thu Feb 2 15:40:55 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781AF21F86BB; Thu, 2 Feb 2012 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4h9kC1YfG7p; Thu, 2 Feb 2012 15:40:54 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id C75D521F86B9; Thu, 2 Feb 2012 15:40:53 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E8F6F7E3D38; Thu, 2 Feb 2012 18:40:52 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0CF597E3976; Thu, 2 Feb 2012 18:40:48 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 2 Feb 2012 18:40:33 -0500 From: Jonathan Lennox To: Justin Uberti Date: Thu, 2 Feb 2012 18:40:46 -0500 Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AcziBBaVWV6DXGQ8R5eNZLT6plxFJw== Message-ID: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> References: 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_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 23:40:55 -0000 --_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this should be an issue for the mmusic group, not rtcweb -- it appl= ies to anything that's doing ICE candidates in SDP. I suggest replies just= go to the mmusic mailing list. On Feb 1, 2012, at 3:42 PM, Justin Uberti wrote: http://tools.ietf.org/html/rfc5245, section 15.1: and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive, and relayed candidates. If a candidate is server or peer reflexive, and are equal to the base for that server or peer reflexive candidate. If the candidate is relayed, and is equal to the mapped address in the Allocate response that provided the client with that relayed candidate (see Appendix B.3 for a discussion of its purpose). If the candidate is a host candidate, and MUST be omitted. Clearly we don't want to send out the base address when doing TURN-only, bu= t according to the spec, rel-addr/rel-port must be supplied. What's the rig= ht way to handle this? For clarity (since the followups on the RTCWeb mailing list indicated some = confusion): the use case is an endpoint which, for location privacy reasons= , wants to offer only TURN candidates in its set of ICE candidates, so the = remote ICE peer doesn't know its actual network location. (The standard ex= ample is the woman calling from the battered women's shelter.) The problem is that RFC 5245 says you MUST include your mapped (server-refl= exive) address when encoding relayed (TURN) candidates in SDP. If you do th= is, however, it completely breaks location privacy -- the mapped address is= exactly what you're trying to hide. It wouldn't be too hard to pick a known-invalid IP and port -- 0.0.0.0 0, p= resumably -- to encode in this situation (so as not to break strict parsers= ). The question is whether this would break any endpoints that are trying t= o follow the behavior in Appendix B.3 of RFC 5245, i.e. trying to apply QoS= rules for the path between the endpoint and the TURN server. -- Jonathan Lennox jonathan@vidyo.com --_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think this should b= e an issue for the mmusic group, not rtcweb -- it applies to anything that'= s doing ICE candidates in SDP.  I suggest replies just go to the mmusi= c mailing list.

On Feb 1, 2012, at 3:42 PM, Justin= Uberti wrote:

http://tools.ietf.org/html/rfc5245=
, section 15.1:      
      <rel-addr> and=
 <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>=
;
      and <rel-port> MUST be present for server reflexive, peer
      reflexive, and relayed candidates.  If a candidate is server or
      peer reflexive, <rel-addr> and <rel-port> are equal to th=
e base
      for that server or peer reflexive candidate.  If the candidate is
      relayed, <rel-addr> and <rel-port> is equal to the mapped=
 address
      in the Allocate response that provided the client with that
      relayed candidate (see Appendix B.3 for a discussion of its
      purpose).  If the candidate is a host candidate, <rel-addr> and
      <rel-port> MUST be omitted.

Clearly we don't want to send o=
ut the base address when doing TURN-only, but according to the spec, rel-ad=
dr/rel-port must be supplied. What's the right way to handle this?


For clarity (since the =
followups on the RTCWeb mailing list indicated some confusion): the use cas=
e is an endpoint which, for location privacy reasons, wants to offer only T=
URN candidates in its set of ICE candidates, so the remote ICE peer doesn't=
 know its actual network location.  (The standard example is the woman=
 calling from the battered women's shelter.)

The p=
roblem is that RFC 5245 says you MUST include your mapped (server-reflexive=
) address when encoding relayed (TURN) candidates in SDP. If you do this, h=
owever, it completely breaks location privacy -- the mapped address is exac=
tly what you're trying to hide.

It wouldn't = be too hard to pick a known-invalid IP and port -- 0.0.0.0 0, presumably --= to encode in this situation (so as not to break strict parsers). The quest= ion is whether this would break any endpoints that are trying to follow the= behavior in Appendix B.3 of RFC 5245, i.e. trying to apply QoS rules for t= he path between the endpoint and the TURN server.

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_607A2845E8A64C66BA1A619E1B471B7Cvidyocom_-- From jonathan@vidyo.com Fri Feb 3 09:27:16 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1965F21F8533; Fri, 3 Feb 2012 09:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C27+YtSPjqjU; Fri, 3 Feb 2012 09:27:15 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5F521F84F7; Fri, 3 Feb 2012 09:27:15 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B89057E3C57; Fri, 3 Feb 2012 12:27:14 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4AC927E3D5C; Fri, 3 Feb 2012 12:27:14 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Fri, 3 Feb 2012 12:27:13 -0500 From: Jonathan Lennox To: Martin Thomson Date: Fri, 3 Feb 2012 12:27:13 -0500 Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AczimRFvWXdvOBLxTsKrh3eZuevSfQ== Message-ID: <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.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 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Justin Uberti Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:27:16 -0000 On Feb 3, 2012, at 11:36 AM, Martin Thomson wrote: > On 2 February 2012 15:40, Jonathan Lennox wrote: >> (The standard >> example is the woman calling from the battered women's shelter.) >=20 > The other way round, actually. The case is where someone knows how to > contact the woman (by webrtc) and simply by attempting to make the > call, they obtain her location. Right, good point. But *why* you want location privacy isn't really relevant to the discussion= here -- there are lots of use cases and reasons to want it. >> The problem is that RFC 5245 says you MUST include your mapped >> (server-reflexive) address when encoding relayed (TURN) candidates in SD= P. >=20 > I don't think that's true from reading the text more carefully. What > the text says is that if you include a server reflexive address, you > must include rel-addr and rel-port. Section 15.1 describes the > grammar, not the usage. There is no reason that you can't simply omit > all candidates other than the "relay" candidates. Read the next sentence -- if you include a relay candidate, you must includ= e "the mapped address in the Allocate response that provided the client wit= h that relayed candidate" as the rel-addr and rel-port. This is the same as= the server-reflexive address. =20 -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Fri Feb 3 08:37:02 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46C321F84EA; Fri, 3 Feb 2012 08:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cmUYC5+LNNa; Fri, 3 Feb 2012 08:36:49 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACE2821F84FB; Fri, 3 Feb 2012 08:36:48 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3562900bkb.31 for ; Fri, 03 Feb 2012 08:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UA24DPfoASDYD/lwjtWh+g3+VO/0CE/YpNTeBEZjZ2I=; b=sFALA87Ni6aaio+9Ikdw/5JEGxpeV2IIlyoQUmtC2BPY3lBX5Pqk/paxkvr2xqSstl HecpsSYqZkeOIk6v8+bQjPOIh+Gc0QrUzWNsEiO3nLVGfma51ToHPV742JTQqwogU8B0 l1XfKGM8CBRu1rXVbBZ8pcQo4J9vPySvClEKg= MIME-Version: 1.0 Received: by 10.204.130.129 with SMTP id t1mr3904804bks.33.1328287007746; Fri, 03 Feb 2012 08:36:47 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 08:36:47 -0800 (PST) In-Reply-To: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 08:36:47 -0800 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 03 Feb 2012 11:24:59 -0800 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Justin Uberti Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 16:37:03 -0000 On 2 February 2012 15:40, Jonathan Lennox wrote: > (The standard > example is the woman calling from the battered women's shelter.) The other way round, actually. The case is where someone knows how to contact the woman (by webrtc) and simply by attempting to make the call, they obtain her location. > The problem is that RFC 5245 says you MUST include your mapped > (server-reflexive) address when encoding relayed (TURN) candidates in SDP. I don't think that's true from reading the text more carefully. What the text says is that if you include a server reflexive address, you must include rel-addr and rel-port. Section 15.1 describes the grammar, not the usage. There is no reason that you can't simply omit all candidates other than the "relay" candidates. --Martin From martin.thomson@gmail.com Fri Feb 3 09:41:05 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A1821F8528; Fri, 3 Feb 2012 09:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPQOECzXBGNH; Fri, 3 Feb 2012 09:41:05 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC021F84D4; Fri, 3 Feb 2012 09:41:04 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3621123bkb.31 for ; Fri, 03 Feb 2012 09:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hnToKbFP4bH2zdYpCl+HSKJZgu/kx4udT2tbWNB7i/Y=; b=x2dUxhvi+CdLJNltffW8QEB7jSyPDq91ZihPekYrY3jYU/eD0BKxAB64eV5ZSM6sND Q6VBr2XNE6Kzwi9z8zGoC7p7Er0oXkuvkTdETCY5+ZMit8td42vV51GTJ/CCab1HBEoW Lep43D6IoQqpU7lCVZk7/BukqYeUnIWbXuQKI= MIME-Version: 1.0 Received: by 10.204.130.129 with SMTP id t1mr4030404bks.33.1328290863784; Fri, 03 Feb 2012 09:41:03 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 09:41:03 -0800 (PST) In-Reply-To: <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> Date: Fri, 3 Feb 2012 09:41:03 -0800 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 03 Feb 2012 11:24:59 -0800 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Justin Uberti Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:41:05 -0000 On 3 February 2012 09:27, Jonathan Lennox wrote: > Read the next sentence -- if you include a relay candidate, you must incl= ude "the mapped address in the Allocate response that provided the client w= ith that relayed candidate" as the rel-addr and rel-port. This is the same = as the server-reflexive address. My bad. Your suggestion of ":: 0" should do to satisfy syntax checkers. From matthew.kaufman@skype.net Fri Feb 3 11:21:51 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC97021F85EA; Fri, 3 Feb 2012 11:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwvXmNJU6xzh; Fri, 3 Feb 2012 11:21:47 -0800 (PST) Received: from AM1EHSOBE006.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6B59E21F8505; Fri, 3 Feb 2012 11:21:46 -0800 (PST) Received: from mail39-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Feb 2012 19:21:42 +0000 Received: from mail39-am1 (localhost [127.0.0.1]) by mail39-am1-R.bigfish.com (Postfix) with ESMTP id 9D926E0598; Fri, 3 Feb 2012 19:21:45 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail39-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 1328296903293595_22713; Fri, 3 Feb 2012 19:21:43 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.242]) by mail39-am1.bigfish.com (Postfix) with ESMTP id 4107B400045; Fri, 3 Feb 2012 19:21:43 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Feb 2012 19:21:40 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.210]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Fri, 3 Feb 2012 11:21:28 -0800 From: Matthew Kaufman To: Martin Thomson , Jonathan Lennox Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AQHM4pIZRQ4Lrz8npESGkc635yvt2pYrjA6w Date: Fri, 3 Feb 2012 19:21:28 +0000 Message-ID: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Fri, 03 Feb 2012 11:24:59 -0800 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 19:21:51 -0000 Martin Thomson: > other way round, actually. The case is where someone knows how to contac= t the woman (by webrtc) and simply by attempting to make the call, they > obtain her location. Exactly. So the woman must use a webrtc provider who 1) doesn't reveal her = IP address to bad people itself and 2) doesn't set the parameters such that= her local or STUN address is sent prior to answer. Requiring the browser t= o *never* be able to provide the STUN or local address before answering is = overkill (and providers who want faster connections will circumvent by buil= ding a brief null call and figuring it out that way). >> The problem is that RFC 5245 says you MUST include your mapped >> (server-reflexive) address when encoding relayed (TURN) candidates in SD= P. >I don't think that's true from reading the text more carefully. What the = text says is that if you include a server reflexive address, you must inclu= de rel-addr > and rel-port. Section 15.1 describes the grammar, not the usage. There = is no reason that you can't simply omit all candidates other than the "rela= y" > candidates. That's how I read it too. Pretty clear you could return *no* candidates, if that's appropriate. Matthew Kaufman From ted.ietf@gmail.com Fri Feb 3 14:53:59 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C1E21F8621; Fri, 3 Feb 2012 14:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, FRT_SOMA=1.664, FRT_SOMA2=2.199, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7l+tvxVtsJ7; Fri, 3 Feb 2012 14:53:59 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8E21F8620; Fri, 3 Feb 2012 14:53:59 -0800 (PST) Received: by ggnq2 with SMTP id q2so2528453ggn.31 for ; Fri, 03 Feb 2012 14:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ktjgEg1Sm2KQiyAmEch7K0hHnwIZP2XDeRs5nuYA8wo=; b=cP5mM0ffUn4yZriiZNHdKTkg3S2RlFnz4RxfmXtnt7wNnb1fAlCrzA+g+jhwaUbnyN O83kt5ISbvD27BqAzf5Qauxz8cAkfj/xWfHROaaK6gzNQald/Q2E6V4SCX7wQdbuzMdk Og2ZWTSpoT0ZJ892pHykZvYSB6APe5a6qe+IU= MIME-Version: 1.0 Received: by 10.101.131.20 with SMTP id i20mr4423244ann.29.1328309638715; Fri, 03 Feb 2012 14:53:58 -0800 (PST) Received: by 10.236.103.232 with HTTP; Fri, 3 Feb 2012 14:53:58 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 14:53:58 -0800 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: Jonathan Lennox , Martin Thomson , "mmusic@ietf.org" , "rtcweb@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 22:53:59 -0000 On Fri, Feb 3, 2012 at 11:21 AM, Matthew Kaufman wrote: > > Requiring the browser to *never* be able to provide the STUN or local address before answering is overkill (and providers who want faster connections will circumvent by >building a brief null call and figuring it out that way). > Obviously we can disagree about "overkill" when it comes to the balance between latency and privacy, but before we go there, I want to make sure I understand what you mean by a null call. If I understand the optimization, you're proposing having the downloaded javascript instantiate a session to the server ("call home on download"), so that the server can collect the addresses it uses and then hand them out to any other user who wishes to make a call to the user. If that is the proposal, I have to say that I think it runs directly counter to the privacy imperative we just identified. Let's imagine our vampire friends at deadjournal decide to do this. If I want to find out where the holder of sparklyvamp@deadjournal.com is, er, living, I can set up a script that attempts to autocall them every N minutes and then lookup. Whenever they sign in, deadjournal will collect their IPs and send them over to me for use in my call. sparklyvamp may very well know I am staker, and decide not to answer. In the mean time, however, I'm on my way with holy water, garlic, and a sharpened stick. In order to avoid this fate, sparklyvamp must know whether or not any particular service they use which *might* embed audio and video in some parts of the applications they provide or host will or will not use this. This includes the services deadjournal hosts for Zomga, the well-known undead games maker. Have I misunderstood your optimization? Ted From martin.thomson@gmail.com Fri Feb 3 15:39:53 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8384D21F84FB; Fri, 3 Feb 2012 15:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EJDQ0JN+BiX; Fri, 3 Feb 2012 15:39:52 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D82A221F84D9; Fri, 3 Feb 2012 15:39:51 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3860214bkb.31 for ; Fri, 03 Feb 2012 15:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5H6r6H/RuVAxYbILh9F1cg6vhIQgaZrLgcY2ZH8A9H0=; b=ideSvCcHd+JjfqobSVq3UVvpMXqwZBRApDN2Xb8VfNNvzWx/1aVVOKxx8tGtShs0F+ qzjl9WZ4YlSH2IjSx6PNTNJesZN6xHfO+Xcg9xReZboElyUQ77Vx1mWqLc4VaTEoZOyx s3f95bVCOpFxFve5npPUeJU6Dru3hGwZ+Tkfw= MIME-Version: 1.0 Received: by 10.204.152.26 with SMTP id e26mr4326722bkw.87.1328312390971; Fri, 03 Feb 2012 15:39:50 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 3 Feb 2012 15:39:50 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 15:39:50 -0800 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox , Matthew Kaufman , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 23:39:53 -0000 On 3 February 2012 14:53, Ted Hardie wrote: > Obviously we can disagree about "overkill" when it comes to the > balance between latency and privacy, but before we go there, I want to > make sure I understand what you mean by a null call. =C2=A0If I understan= d > the optimization, you're proposing having the downloaded javascript > instantiate a session to the server ("call home on download"), so that > the server can collect the addresses it uses and then hand them out to > any other user who wishes to make a call to the user. The point is that, at some level, the user has to trust the site they are visiting before they grant the site access to PeerConnection. It _is_ possible to keep the server ignorant with a little trickery. You use this new data bearer to exchange candidates and keep all but relay candidates from the server, or always use your own TURN server and always relay. The exchange of candidates would have to be standardized though. Keep in mind that you also need to proxy your HTTP traffic to the server as well. That's the trade-off, and maybe that's an option that should remain on the table, but you can see where "overkill" comes from. --Martin From juberti@google.com Fri Feb 3 12:45:54 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AAD21F85AD for ; Fri, 3 Feb 2012 12:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeWYiUW9BIb4 for ; Fri, 3 Feb 2012 12:45:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7A1121F854C for ; Fri, 3 Feb 2012 12:45:53 -0800 (PST) Received: by iagf6 with SMTP id f6so6339812iag.31 for ; Fri, 03 Feb 2012 12:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=gNBqz+EgT/hmkSZqfYJdm+4oEqKOoK6otqwUUCtZAgo=; b=jhncuUZm3iuV4hn2of5/5ltjbNzm/FDD5Kff5CIAXpEOZSmgfgQj4uZCQ8OcDULXO8 lrQMD/iTzMZA4JVDSP/hgWSWO6xuBBrIOBDZFXRMHkfq3zcxQHVpmXTnB+843cXo+RHG p/DCXZkSDbssh2beKTJPYxN5AQSR4wjiyytnE= Received: by 10.50.89.196 with SMTP id bq4mr10214774igb.26.1328301953382; Fri, 03 Feb 2012 12:45:53 -0800 (PST) Received: by 10.50.89.196 with SMTP id bq4mr10214763igb.26.1328301953292; Fri, 03 Feb 2012 12:45:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 3 Feb 2012 12:45:33 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> <9173BA4F-51E7-4F27-958F-6E4DAD0C17F9@vidyo.com> From: Justin Uberti Date: Fri, 3 Feb 2012 12:45:33 -0800 Message-ID: To: Martin Thomson X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f3ba68114992604b8156609 X-Mailman-Approved-At: Sun, 05 Feb 2012 09:58:38 -0800 Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:45:54 -0000 --e89a8f3ba68114992604b8156609 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2012 at 9:41 AM, Martin Thomson wrote: > On 3 February 2012 09:27, Jonathan Lennox wrote: > > Read the next sentence -- if you include a relay candidate, you must > include "the mapped address in the Allocate response that provided the > client with that relayed candidate" as the rel-addr and rel-port. This is > the same as the server-reflexive address. > > My bad. Your suggestion of ":: 0" should do to satisfy syntax checkers. > Thanks for the replies. Since the text in Appendix B.3 that Jonathan referred to indicates that rel-addr/port is not critical to ICE operation, 0.0.0.0:0 sounds good to me. --e89a8f3ba68114992604b8156609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2012 at 9:41 AM, Martin Thomson <= span dir=3D"ltr"><martin.tho= mson@gmail.com> wrote:
On 3 February 2012 09:27, Jonathan Lennox <jonathan@vidyo.com> wrote:
> Read the next sentence -- if you include a relay candidate, you must i= nclude "the mapped address in the Allocate response that provided the = client with that relayed candidate" as the rel-addr and rel-port. This= is the same as the server-reflexive address.

My bad. =C2=A0Your suggestion of ":: 0" should do to satisf= y syntax checkers.

Thanks for the replies. Since the text in Appen= dix B.3 that Jonathan referred to indicates that rel-addr/port is not criti= cal to ICE operation, 0.0.0.0:0 sounds goo= d to me.
--e89a8f3ba68114992604b8156609-- From roman@telurix.com Fri Feb 3 15:55:45 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCBB21F8534; Fri, 3 Feb 2012 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kMS1OnlO7QO; Fri, 3 Feb 2012 15:55:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 983F421F851A; Fri, 3 Feb 2012 15:55:44 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so244742pbc.31 for ; Fri, 03 Feb 2012 15:55:44 -0800 (PST) Received: by 10.68.239.41 with SMTP id vp9mr22345498pbc.17.1328313344294; Fri, 03 Feb 2012 15:55:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id i10sm16502713pbg.10.2012.02.03.15.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 15:55:42 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so244699pbc.31 for ; Fri, 03 Feb 2012 15:55:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.209.39 with SMTP id mj7mr21682918pbc.25.1328313340575; Fri, 03 Feb 2012 15:55:40 -0800 (PST) Received: by 10.68.40.232 with HTTP; Fri, 3 Feb 2012 15:55:40 -0800 (PST) In-Reply-To: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> Date: Fri, 3 Feb 2012 18:55:40 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=14dae9c09e06d0bfa204b8180c16 X-Mailman-Approved-At: Sun, 05 Feb 2012 09:58:38 -0800 Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 23:55:45 -0000 --14dae9c09e06d0bfa204b8180c16 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 3, 2012 at 6:39 PM, Martin Thomson wrote: > The point is that, at some level, the user has to trust the site they > are visiting before they grant the site access to PeerConnection. > > It _is_ possible to keep the server ignorant with a little trickery. > You use this new data bearer to exchange candidates and keep all but > relay candidates from the server, or always use your own TURN server > and always relay. The exchange of candidates would have to be > standardized though. Keep in mind that you also need to proxy your > HTTP traffic to the server as well. That's the trade-off, and maybe > that's an option that should remain on the table, but you can see > where "overkill" comes from. > > I thought that TURN servers would be provisioned by the java script (web site) and not the end user, or do we plan to provide an interface in web browser settings that allows the overwrite for this? One more thing that an end user can do to ensure privacy, is to always require to use a proxy. I am not sure if the decision have been made, if proxy is required to be used, if specified by the end user. One option is that if proxy is specified, the only candidate used would be a TURN address obtained via a TCP or TLS connection established through proxy. Unfortunately, this exactly the opposite of what you would want to do, if you were trying to optimize the media for best performance, since in this case you would try to connect to the TURN server directly even if proxy is specified (and to use reflective or local IP if possible). Final consideration is that even if such options are provided in a web browser, very few users would be educated enough to use them properly. _____________ Roman Shpount --14dae9c09e06d0bfa204b8180c16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2012 at 6:39 PM= , Martin Thomson <martin.thomson@gmail.com> wrote:
The point is that, at some level, the user has to trust the site they
are visiting before they grant the site access to PeerConnection.

It _is_ possible to keep the server ignorant with a little trickery.
You use this new data bearer to exchange candidates and keep all but
relay candidates from the server, or always use your own TURN server
and always relay. =A0The exchange of candidates would have to be
standardized though. =A0Keep in mind that you also need to proxy your
HTTP traffic to the server as well. =A0That's the trade-off, and maybe<= br> that's an option that should remain on the table, but you can see
where "overkill" comes from.


I thought that TURN servers would be provisioned= by the java script (web site) and not the end user, or do we plan to provi= de an interface in web browser settings that allows the overwrite for this?=

One more thing that an end user can do to ensure privacy, is to always = require to use a proxy. I am not sure if the decision have been made, if pr= oxy is required to be used, if specified by the end user. One option is tha= t if proxy is specified, the only candidate used would be a TURN address ob= tained via a TCP or TLS connection established through proxy. Unfortunately= , this exactly the opposite of what you would want to do, if you were tryin= g to optimize the media for best performance, since in this case you would = try to connect to the TURN server directly even if proxy is specified (and = to use reflective or local IP if possible).

Final consideration is that even if such options are provided in a web = browser, very few users would be educated enough to use them properly.
_= ____________
Roman Shpount


--14dae9c09e06d0bfa204b8180c16-- From Bert.Greevenbosch@huawei.com Sun Feb 5 16:31:55 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06D621F858E for ; Sun, 5 Feb 2012 16:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOCOIPZwFs5f for ; Sun, 5 Feb 2012 16:31:55 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F210721F8585 for ; Sun, 5 Feb 2012 16:31:54 -0800 (PST) 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 <0LYY0000B4547D@szxga03-in.huawei.com> for mmusic@ietf.org; Mon, 06 Feb 2012 08:31:52 +0800 (CST) Received: from szxrg02-dlp.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 <0LYY00DN2454PL@szxga03-in.huawei.com> for mmusic@ietf.org; Mon, 06 Feb 2012 08:31:52 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGV44049; Mon, 06 Feb 2012 08:31:45 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 08:31:08 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.186]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Mon, 06 Feb 2012 08:32:28 +0800 Date: Mon, 06 Feb 2012 00:31:37 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.135] To: IETF - MMUSIC Message-id: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_A2BZd+3uDFurUrk0jVShhw)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: The 3D drafts Thread-index: AczkZrAV0ElkOsHfT6KQFeCWDlQX8Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 00:31:55 -0000 --Boundary_(ID_A2BZd+3uDFurUrk0jVShhw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I was wondering, if everybody is happy with the current versions of the 3D drafts, or are there still open issues? I look forward to your comments. Best regards, Bert http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ --Boundary_(ID_A2BZd+3uDFurUrk0jVShhw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

I was wondering, if everybody is happy with the current versions of the 3D drafts, or are there still open issues?

I look forward to your comments.

 

Best regards,

Bert

 

http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/

http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/

--Boundary_(ID_A2BZd+3uDFurUrk0jVShhw)-- From zhou.sujing@zte.com.cn Sun Feb 5 17:14:07 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CDE21F858E for ; Sun, 5 Feb 2012 17:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.098 X-Spam-Level: X-Spam-Status: No, score=-96.098 tagged_above=-999 required=5 tests=[AWL=-3.308, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofjfy5-Uy2T3 for ; Sun, 5 Feb 2012 17:14:06 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4021F8588 for ; Sun, 5 Feb 2012 17:14:06 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690978252052; Mon, 6 Feb 2012 08:47:44 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.978252052; Mon, 6 Feb 2012 09:13:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q161DpRL037228 for ; Mon, 6 Feb 2012 09:13:51 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <20120201002154.8125.74007.idtracker@ietfa.amsl.com> To: mmusic@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 6 Feb 2012 09:13:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-06 09:13:52, Serialize complete at 2012-02-06 09:13:52 Content-Type: multipart/alternative; boundary="=_alternative 0006C3174825799C_=" X-MAIL: mse01.zte.com.cn q161DpRL037228 Subject: [MMUSIC] =?gb2312?b?SXMgTU1VU0lDIHRoZSByaWdodCBXRyBmb3IgdGhpcyBk?= =?gb2312?b?cmFmdD+08Li0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0?= =?gb2312?b?LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAwLnR4dA==?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 01:14:07 -0000 This is a multipart message in MIME format. --=_alternative 0006C3174825799C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC0 09ogMjAxMi0wMi0wMSAwODoyMTo1NDoNCg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt emhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDAudHh0IGhhcyBiZWVuIA0KPiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFN1amluZyBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCj4gDQo+IEZpbGVuYW1lOiAgICBkcmFmdC16aG91LW1tdXNpYy1zZGVzLWtleW1vZA0KPiBS ZXZpc2lvbjogICAgMDANCj4gVGl0bGU6ICAgICAgIFNlY3VyaXR5IERlc2NyaXB0aW9ucyBFeHRl bnNpb24gZm9yIE1lZGlhIFN0cmVhbXMNCj4gQ3JlYXRpb24gZGF0ZTogICAgMjAxMi0wMS0zMQ0K PiBXRyBJRDogICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczog MTINCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIGV4dGVu c2lvbiB0byB0aGUgY3J5cHRvZ3JhcGhpYyBhdHRyaWJ1dGUNCj4gICAgKFJGQyA0NTY4KSBkZWZp bmVkIGZvciBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChSRkMgNDU2NikgdG8NCj4gICAg ZW5oYW5jZSBlbmQtdG8tZW5kIGNvbW11bmljYXRpb24gc2VjdXJpdHkgaW4gc2NlbmFyaW9zLCBl LmcuLCBmb3JraW5nDQo+ICAgIGFuZCByZS10YXJnZXRpbmcuICBUaGUgdXNhZ2Ugb2YgdGhlIHBy b3ZpZGVkIGV4dGVuc2lvbiBpbiBTZWN1cmUNCj4gICAgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90 b2NvbCAoU1JUUCwgUkZDMzcxMSkgaXMgYWxzbyBkZWZpbmVkIGluIHRoaXMNCj4gICAgZG9jdW1l bnQuDQo+IA0KPiAgDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCg== --=_alternative 0006C3174825799C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcg0LTT2iAyMDEyLTAyLTAxIDA4OjIxOjU0Ojxicj4NCjxicj4NCiZn dDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAw LnR4dCBoYXMgYmVlbg0KPGJyPg0KJmd0OyBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN1amlu ZyBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQomZ3Q7IDxicj4N CiZndDsgRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDtkcmFmdC16aG91LW1tdXNpYy1zZGVzLWtleW1v ZDxicj4NCiZndDsgUmV2aXNpb246ICZuYnNwOyAmbmJzcDswMDxicj4NCiZndDsgVGl0bGU6ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFNlY3VyaXR5IERlc2NyaXB0aW9ucyBFeHRlbnNpb24gZm9yIE1l ZGlhDQpTdHJlYW1zPGJyPg0KJmd0OyBDcmVhdGlvbiBkYXRlOiAmbmJzcDsgJm5ic3A7MjAxMi0w MS0zMTxicj4NCiZndDsgV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3Vi bWlzc2lvbjxicj4NCiZndDsgTnVtYmVyIG9mIHBhZ2VzOiAxMjxicj4NCiZndDsgPGJyPg0KJmd0 OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3ZpZGVz IGFuIGV4dGVuc2lvbiB0byB0aGUgY3J5cHRvZ3JhcGhpYw0KYXR0cmlidXRlPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7KFJGQyA0NTY4KSBkZWZpbmVkIGZvciBTZXNzaW9uIERlc2NyaXB0aW9uIFBy b3RvY29sIChSRkMNCjQ1NjYpIHRvPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZW5oYW5jZSBlbmQt dG8tZW5kIGNvbW11bmljYXRpb24gc2VjdXJpdHkgaW4gc2NlbmFyaW9zLA0KZS5nLiwgZm9ya2lu Zzxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FuZCByZS10YXJnZXRpbmcuICZuYnNwO1RoZSB1c2Fn ZSBvZiB0aGUgcHJvdmlkZWQgZXh0ZW5zaW9uDQppbiBTZWN1cmU8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDtSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChTUlRQLCBSRkMzNzExKSBpcyBhbHNv DQpkZWZpbmVkIGluIHRoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtkb2N1bWVudC48YnI+DQom Z3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRhcmlh dDxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 0006C3174825799C_=-- From christer.holmberg@ericsson.com Sun Feb 5 20:06:20 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15621F852B; Sun, 5 Feb 2012 20:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.281 X-Spam-Level: X-Spam-Status: No, score=-7.281 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FRT_SOMA=1.664, FRT_SOMA2=2.199, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UnUvGECKxiM; Sun, 5 Feb 2012 20:06:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4618321F8547; Sun, 5 Feb 2012 20:06:19 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-fb-4f2f51b7d960 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.7D.27041.7B15F2F4; Mon, 6 Feb 2012 05:06:15 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 6 Feb 2012 05:06:15 +0100 From: Christer Holmberg To: Ted Hardie , Matthew Kaufman Date: Mon, 6 Feb 2012 05:06:14 +0100 Thread-Topic: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? Thread-Index: AczixrkVOwmmReELS7KZWQyrTe5CnwBvIo9M Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9D7@ESESSCMS0356.eemea.ericsson.se> References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.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== Cc: Jonathan Lennox , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 04:06:20 -0000 Hi, For clarification, what do we exactly mean by "answering the call"? Do we mean: a) that the called party has accepted the call, and actually "lifted the ho= ok", or=20 b) that the called party has been made aware (alterted) about the incoming = call, but has not yet accepted it, and may or may not accept it? We also have to remember that ICE is not the only way to reveal IP addresse= s. The signalling protocol (depending on which one we use) can also reveal = IP addresses/ports in other protocol elements.=20 And, taking SIP as an example: if we don't allow revealing of IP addresses = before the call has been answered, it would prevent a SIP app from sending = provisional responses with Contact header fields. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ted Ha= rdie [ted.ietf@gmail.com] Sent: Saturday, February 04, 2012 12:53 AM To: Matthew Kaufman Cc: Jonathan Lennox; mmusic@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/r= el-port be? On Fri, Feb 3, 2012 at 11:21 AM, Matthew Kaufman wrote: > > Requiring the browser to *never* be able to provide the STUN or local add= ress before answering is overkill (and providers who want faster connection= s will circumvent by >building a brief null call and figuring it out that w= ay). > Obviously we can disagree about "overkill" when it comes to the balance between latency and privacy, but before we go there, I want to make sure I understand what you mean by a null call. If I understand the optimization, you're proposing having the downloaded javascript instantiate a session to the server ("call home on download"), so that the server can collect the addresses it uses and then hand them out to any other user who wishes to make a call to the user. If that is the proposal, I have to say that I think it runs directly counter to the privacy imperative we just identified. Let's imagine our vampire friends at deadjournal decide to do this. If I want to find out where the holder of sparklyvamp@deadjournal.com is, er, living, I can set up a script that attempts to autocall them every N minutes and then lookup. Whenever they sign in, deadjournal will collect their IPs and send them over to me for use in my call. sparklyvamp may very well know I am staker, and decide not to answer. In the mean time, however, I'm on my way with holy water, garlic, and a sharpened stick. In order to avoid this fate, sparklyvamp must know whether or not any particular service they use which *might* embed audio and video in some parts of the applications they provide or host will or will not use this. This includes the services deadjournal hosts for Zomga, the well-known undead games maker. Have I misunderstood your optimization? Ted _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From wwwrun@rfc-editor.org Sun Feb 5 21:20:08 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8221F8453 for ; Sun, 5 Feb 2012 21:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCcRuNYcYb7W for ; Sun, 5 Feb 2012 21:20:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7786F21F844D for ; Sun, 5 Feb 2012 21:20:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 83B2E62176; Sun, 5 Feb 2012 21:15:55 -0800 (PST) To: jdrosen@jdrosen.net, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, miguel.a.garcia@ericsson.com, fandreas@cisco.com From: RFC Errata System Message-Id: <20120206051555.83B2E62176@rfc-editor.org> Date: Sun, 5 Feb 2012 21:15:55 -0800 (PST) Cc: rfc-editor@rfc-editor.org, shankarkaushik@gmail.com, mmusic@ietf.org Subject: [MMUSIC] [Technical Errata Reported] RFC5245 (3107) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 05:20:08 -0000 The following errata report has been submitted for RFC5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3107 -------------------------------------- Type: Technical Reported by: N V S Kaushik Section: Appendix B.6 Original Text ------------- However, the check from agent R has not yet generated a response, and agent R receives the updated offer (message 7) before getting the response (message 9). Corrected Text -------------- However, the check from agent R has not yet received a response, and agent R receives the updated offer (message 7) before getting the response (message 9). Notes ----- Here Agent R(ideally Agent B as per the figure 11) has generated the request, so it must receive the response. The original text may give a meaning that Agent R has to generate a response. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5245 (draft-ietf-mmusic-ice-19) -------------------------------------- Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Publication Date : April 2010 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From abegen@cisco.com Mon Feb 6 13:42:28 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110F011E80A2 for ; Mon, 6 Feb 2012 13:42:28 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cvhu47JEd+I for ; Mon, 6 Feb 2012 13:42:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C93D111E809D for ; Mon, 6 Feb 2012 13:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1745; q=dns/txt; s=iport; t=1328564547; x=1329774147; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=T/9eIIBf/kCf+l1/JunZVT1Pjtmv2d4atjPNYu+pjWA=; b=Ytc2XheOxpKHlyPnXrCCwloYoYFNub8GFnBmJ8jpFXn+J/TrbsVSqVjk WLN8wDY/UnESR9Op4qBlcw/ZdBAm1TG3u1qHKdmCuuYCfwFXVIRG3oEuw zZgEt/vOUL0c/sj1M0mNajpcPQIVohAEQ1memyzj+PjUUO+fhHiLosu1g k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABFIME+tJV2d/2dsb2JhbABDr0WBBYF0AQQSAXgBKlYmAQQbEwegJoEnAZ8Eiy0EAQUCAhYGAgYBNRKEJgwBAwMCAQEBAQIBglljBIgRn3I X-IronPort-AV: E=Sophos;i="4.73,372,1325462400"; d="scan'208";a="56783400" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 06 Feb 2012 21:42:26 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q16LgQ1v022310 for ; Mon, 6 Feb 2012 21:42:26 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.213]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0247.003; Mon, 6 Feb 2012 13:42:26 -0800 From: "Ali C. Begen (abegen)" To: "mmusic (E-mail)" Thread-Topic: Proposed change in 4566bis for private addresses Thread-Index: AczlF5gIcH2WlaMjSw+JMlxLRToQmg== Date: Mon, 6 Feb 2012 21:42:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18694.001 x-tm-as-result: No--30.481800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Proposed change in 4566bis for private addresses X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 21:42:28 -0000 Currently, RFC 4566 section 5.2 states the following: is the address of the machine from which the session was created. For an address type of IP4, this is either the fully qualified domain name of the machine or the dotted- decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully qualified domain name of the machine or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful (for example, a local address MUST NOT be included in an application-level referral that might leave the scope). The last portion contradicts with what ICE-like solutions have. So, we sugg= est to change the last portion as: Unless an SDP extension for NAT traversal is used (e.g., ICE [RFC 5245], ICE TCP [draft-ietf-mmusic-ice-tcp]) a local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful (for example, a local address MUST NOT be included in an application-level referral that might leave the scope). And the referred RFC/draft will be added to the informative reference list. Please comment on this change. A new revision will be posted well before th= e next meeting. Thanks, -acbegen From ietf-ipr@ietf.org Mon Feb 6 14:00:51 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BAB11E8093; Mon, 6 Feb 2012 14:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIzTCZff1Jin; Mon, 6 Feb 2012 14:00:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241E511E8076; Mon, 6 Feb 2012 14:00:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: bert.greevenbosch@huawei.com, huiyu@huawei.com X-Test-IDTracker: no Message-ID: <20120206220051.29099.41064.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 14:00:51 -0800 X-Mailman-Approved-At: Mon, 06 Feb 2012 14:16:30 -0800 Cc: mmusic@ietf.org, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, ipr-announce@ietf.org Subject: [MMUSIC] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mmusic-signal-3d-format-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 22:00:51 -0000 Dear Bert Greevenbosch, Hui Yu: An IPR disclosure that pertains to your Internet-Draft entitled "Signal 3D format" (draft-ietf-mmusic-signal-3d-format) was submitted to the IETF Secretariat on 2012-02-06 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1673/). The = title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mmusic-signal-3d-format-00.""); The IETF Secretariat From ietf-ipr@ietf.org Mon Feb 6 14:03:33 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFDF21F859E; Mon, 6 Feb 2012 14:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3dtxFcJtnsk; Mon, 6 Feb 2012 14:03:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CCF11E8076; Mon, 6 Feb 2012 14:03:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: bert.greevenbosch@huawei.com, huiyu@huawei.com X-Test-IDTracker: no Message-ID: <20120206220332.30640.56271.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 14:03:32 -0800 X-Mailman-Approved-At: Mon, 06 Feb 2012 14:16:30 -0800 Cc: mmusic@ietf.org, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, ipr-announce@ietf.org Subject: [MMUSIC] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mmusic-parallax-attribute-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 22:03:33 -0000 Dear Bert Greevenbosch, Hui Yu: An IPR disclosure that pertains to your Internet-Draft entitled "SDP attri= bute to signal parallax" (draft-ietf-mmusic-parallax-attribute) was submitted to= the IETF Secretariat on 2012-02-06 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1674/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mm= usic- parallax-attribute-00.""); The IETF Secretariat From fluffy@fluffy.im Tue Feb 7 05:16:00 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2737A21F87D8 for ; Tue, 7 Feb 2012 05:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX11tOpxM8T6 for ; Tue, 7 Feb 2012 05:15:59 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADE521F87DA for ; Tue, 7 Feb 2012 05:15:59 -0800 (PST) Received: by ggnq2 with SMTP id q2so3946145ggn.31 for ; Tue, 07 Feb 2012 05:15:58 -0800 (PST) Received: by 10.50.6.138 with SMTP id b10mr26825967iga.21.1328620558678; Tue, 07 Feb 2012 05:15:58 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id l28sm33493250ibc.3.2012.02.07.05.15.56 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:15:57 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D392387@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Feb 2012 06:15:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D47230B-CCE9-498F-AFB4-9B4BDDE5432F@iii.ca> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D392387@ESESSCMS0356.eemea.ericsson.se> To: MMUSIC WG X-Mailer: Apple Mail (2.1084) Cc: Christer Holmberg Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:16:00 -0000 I think this draft is very good and solves an important problem. We have = been discussing this a long time, there is lots of consensus that this = is basically the right way to go, I really hope the WG adopts it soon.=20= Cullen On Jan 31, 2012, at 9:30 AM, Christer Holmberg wrote: >=20 > FYI, >=20 > Christer >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Christer Holmberg > Sent: 31. tammikuuta 2012 15:09 > To: mmusic@ietf.org > Subject: [MMUSIC] Suggestion to moving ahead with BUNDLE >=20 > Hi, >=20 > At the Taipei IETF I presented the BUNDLE draft, written by myself and = Harald, which extends the SDP grouping framework in order to allow the = usage of identical port values in multiple m- lines in an SDP = offer/answer. >=20 >=20 >=20 > = http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-0= 0.txt >=20 > It can be used when negotiating the usage of multiplexing of multiple = media streams. Such mechanism is very likely going to be needed e.g. in = the work being done in RTCWEB. >=20 > When presented, some people indicated that they may want to look at = other alternatives. >=20 > However, as no alternative solutions have been brought forward since = then, my question is whether people now would be interested in moving = ahead with the BUNDLE mechanism, and adopt the above draft as a starting = point? >=20 > Best regards, >=20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@fluffy.im Tue Feb 7 05:22:57 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5A821F8605; Tue, 7 Feb 2012 05:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBZfAov4-FGi; Tue, 7 Feb 2012 05:22:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7421F8562; Tue, 7 Feb 2012 05:22:55 -0800 (PST) Received: by iagf6 with SMTP id f6so12135624iag.31 for ; Tue, 07 Feb 2012 05:22:55 -0800 (PST) Received: by 10.43.53.1 with SMTP id vo1mr26301255icb.2.1328620975131; Tue, 07 Feb 2012 05:22:55 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ub10sm21057577igb.7.2012.02.07.05.22.53 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:22:54 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 7 Feb 2012 06:22:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <607A2845-E8A6-4C66-BA1A-619E1B471B7C@vidyo.com> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Jonathan Lennox , Martin Thomson , "mmusic@ietf.org" , "rtcweb@ietf.org" Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:22:57 -0000 On Feb 3, 2012, at 4:55 PM, Roman Shpount wrote: > I thought that TURN servers would be provisioned by the java script = (web site) and not the end user, or do we plan to provide an interface = in web browser settings that allows the overwrite for this? Yes, both - in the previous conversations we have agreed to be able to = provide TURN servers both of these ways. We have not yet nailed down = which one takes precedence if both the browser has one configured and = the JS provides one but it seems to me that we need the one the browser = provided TURN server to be higher priority than the JS provided one.=20 From miguel.a.garcia@ericsson.com Tue Feb 7 05:49:06 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408FF21F87C5 for ; Tue, 7 Feb 2012 05:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.006 X-Spam-Level: X-Spam-Status: No, score=-10.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT-8GgG0Jw86 for ; Tue, 7 Feb 2012 05:49:05 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3BA21F87A0 for ; Tue, 7 Feb 2012 05:49:05 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-3f-4f312bd03946 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.3B.27041.0DB213F4; Tue, 7 Feb 2012 14:49:04 +0100 (CET) Received: from [159.107.25.10] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 7 Feb 2012 14:49:04 +0100 Message-ID: <4F312BCF.9090506@ericsson.com> Date: Tue, 7 Feb 2012 14:49:03 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Proposed change in 4566bis for private addresses X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:49:06 -0000 I do agree with the proposal. /Miguel On 06/02/2012 22:42, Ali C. Begen (abegen) wrote: > Currently, RFC 4566 section 5.2 states the following: > > is the address of the machine from which the > session was created. For an address type of IP4, this is either > the fully qualified domain name of the machine or the dotted- > decimal representation of the IP version 4 address of the machine. > For an address type of IP6, this is either the fully qualified > domain name of the machine or the compressed textual > representation of the IP version 6 address of the machine. For > both IP4 and IP6, the fully qualified domain name is the form that > SHOULD be given unless this is unavailable, in which case the > globally unique address MAY be substituted. A local IP address > MUST NOT be used in any context where the SDP description might > leave the scope in which the address is meaningful (for example, a > local address MUST NOT be included in an application-level > referral that might leave the scope). > > The last portion contradicts with what ICE-like solutions have. So, we suggest to change the last portion as: > > > Unless an SDP extension for NAT traversal is used (e.g., ICE [RFC > 5245], ICE TCP [draft-ietf-mmusic-ice-tcp]) a local IP address > MUST NOT be used in any context where the SDP description might > leave the scope in which the address is meaningful (for example, a > local address MUST NOT be included in an application-level > referral that might leave the scope). > > > And the referred RFC/draft will be added to the informative reference list. > > Please comment on this change. A new revision will be posted well before the next meeting. > > Thanks, > -acbegen > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gonzalo.camarillo@ericsson.com Tue Feb 7 12:32:27 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC321F861F for ; Tue, 7 Feb 2012 12:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.895 X-Spam-Level: X-Spam-Status: No, score=-109.895 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no553zOwiIBh for ; Tue, 7 Feb 2012 12:32:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B021F8498 for ; Tue, 7 Feb 2012 12:32:26 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-12-4f318a59c5a7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 02.2A.27041.95A813F4; Tue, 7 Feb 2012 21:32:26 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 7 Feb 2012 21:32:25 +0100 Message-ID: <4F318A59.5020700@ericsson.com> Date: Tue, 7 Feb 2012 22:32:25 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP directorate created X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:32:27 -0000 Folks, per our discussions regarding SDP extension coordination, we have created an SDP directorate, which includes SDP experts that will review proposals for SDP extensions when needed. http://www.ietf.org/iesg/directorate/sdp.html Cheers, Gonzalo From juberti@google.com Tue Feb 7 18:39:52 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64D011E80A3 for ; Tue, 7 Feb 2012 18:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.758 X-Spam-Level: X-Spam-Status: No, score=-102.758 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUjASDanmuN1 for ; Tue, 7 Feb 2012 18:39:52 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6611E8080 for ; Tue, 7 Feb 2012 18:39:51 -0800 (PST) Received: by qcsg13 with SMTP id g13so53963qcs.31 for ; Tue, 07 Feb 2012 18:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-system-of-record:content-type; bh=BOR7nw7sMWxbLXf8PIgd+YERADyDx0oPO/AVQDAELTI=; b=SkrrAH8JGt/x4r0pHlZszbpBvRGV/iSCsEq6Hahk4+G8EAh8Jz1sIRdruL58c2iTxr BtxPiizgqDuI9PnbQD/EYQukTgAPdPQ1xB49R1oTVzM5KWSc36h1OFzl4NMMHvv54A4e NmxjpQH6UIy/pbHgCp8RZjT2Kng8ds9ZeSy90= Received: by 10.224.117.1 with SMTP id o1mr25156034qaq.4.1328668791363; Tue, 07 Feb 2012 18:39:51 -0800 (PST) Received: by 10.224.117.1 with SMTP id o1mr25156029qaq.4.1328668791282; Tue, 07 Feb 2012 18:39:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.133.131 with HTTP; Tue, 7 Feb 2012 18:39:31 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9F0@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D392387@ESESSCMS0356.eemea.ericsson.se> <0D47230B-CCE9-498F-AFB4-9B4BDDE5432F@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9F0@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Tue, 7 Feb 2012 18:39:31 -0800 Message-ID: To: mmusic@ietf.org, Christer Holmberg X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf3074d7f6541c7004b86acfc7 Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:39:52 -0000 --20cf3074d7f6541c7004b86acfc7 Content-Type: text/plain; charset=UTF-8 I agree this is an important problem to solve, and I like the clean approach proposed in this document. We have implemented an initial version of this functionality without much difficulty and would like to see this proposal move forward. --justin > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > > Sent: 31. tammikuuta 2012 15:09 > > To: mmusic@ietf.org > > Subject: [MMUSIC] Suggestion to moving ahead with BUNDLE > > > > Hi, > > > > At the Taipei IETF I presented the BUNDLE draft, written by myself and > Harald, which extends the SDP grouping framework in order to allow the > usage of identical port values in multiple m- lines in an SDP offer/answer. > > > > > > > > > http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > > > It can be used when negotiating the usage of multiplexing of multiple > media streams. Such mechanism is very likely going to be needed e.g. in the > work being done in RTCWEB. > > > > When presented, some people indicated that they may want to look at > other alternatives. > > > > However, as no alternative solutions have been brought forward since > then, my question is whether people now would be interested in moving ahead > with the BUNDLE mechanism, and adopt the above draft as a starting point? > > > > Best regards, > > > > Christer > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic --20cf3074d7f6541c7004b86acfc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree this is an important problem to sol= ve, and I like the clean approach proposed in this document.

=
We have implemented an initial version of this functionality wit= hout much difficulty and would like to see this proposal move forward.

--justin
=C2=A0
> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Christer Holmberg
> Sent: 31. tammikuuta 2012 15:09
> To: mmusic@ietf.org
> Subject: [MMUSIC] Suggestion to moving ahead with BUNDLE
>
> Hi,
>
> At the Taipei IETF I presented the BUNDLE draft, written by myself and= Harald, which extends the SDP grouping framework in order to allow the usa= ge of identical port values in multiple m- lines in an SDP offer/answer. >
>
>
> http://tools.ietf.org/id/draft-holm= berg-mmusic-sdp-multiplex-negotiation-00.txt
>
> It can be used when negotiating the usage of multiplexing of multiple = media streams. Such mechanism is very likely going to be needed e.g. in the= work being done in RTCWEB.
>
> When presented, some people indicated that they may want to look at ot= her alternatives.
>
> However, as no alternative solutions have been brought forward since t= hen, my question is whether people now would be interested in moving ahead = with the BUNDLE mechanism, and adopt the above draft as a starting point? >
> Best regards,
>
> Christer
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
=C2= =A0

--20cf3074d7f6541c7004b86acfc7-- From stefan.lk.hakansson@ericsson.com Wed Feb 8 03:03:30 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1221F869C for ; Wed, 8 Feb 2012 03:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.509 X-Spam-Level: X-Spam-Status: No, score=-9.509 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2JgsnOft7LO for ; Wed, 8 Feb 2012 03:03:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5865021F869A for ; Wed, 8 Feb 2012 03:03:29 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-7d-4f325680f036 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0A.8B.27041.086523F4; Wed, 8 Feb 2012 12:03:28 +0100 (CET) Received: from [150.132.142.235] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 8 Feb 2012 12:03:28 +0100 Message-ID: <4F32567F.8030401@ericsson.com> Date: Wed, 8 Feb 2012 12:03:27 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F3255C1.8050300@ericsson.com> In-Reply-To: <4F3255C1.8050300@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 08 Feb 2012 03:09:33 -0800 Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:03:30 -0000 Being involved in the rtcweb/webrtc work, I would like this proposal to move forward (as it solves an important problem in that context). Stefan On 02/08/2012 12:00 PM, Stefan Håkansson LK wrote: > Hi, > > At the Taipei IETF I presented the BUNDLE draft, written by myself > and Harald, which extends the SDP grouping framework in order to > allow the usage of identical port values in multiple m- lines in an > SDP offer/answer. > > > > http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > It can be used when negotiating the usage of multiplexing of > multiple media streams. Such mechanism is very likely going to be > needed e.g. in the work being done in RTCWEB. > > When presented, some people indicated that they may want to look at > other alternatives. > > However, as no alternative solutions have been brought forward since > then, my question is whether people now would be interested in > moving ahead with the BUNDLE mechanism, and adopt the above draft as > a starting point? > > Best regards, > > Christer From pravindran@sonusnet.com Wed Feb 8 03:59:02 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D5321F8607 for ; Wed, 8 Feb 2012 03:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi8ACmXmRK72 for ; Wed, 8 Feb 2012 03:59:02 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 39F2821F8591 for ; Wed, 8 Feb 2012 03:58:53 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q18Bxafe030819; Wed, 8 Feb 2012 06:59:36 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 06:58:49 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 17:28:53 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 17:28:53 +0530 From: "Ravindran, Parthasarathi" To: Stefan Hakansson LK , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Suggestion to moving ahead with BUNDLE Thread-Index: AQHM5lFIE0wfr663ykuiPT4d68pRbZYy5WeA Date: Wed, 8 Feb 2012 11:58:52 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03E003@inba-mail01.sonusnet.com> References: <4F3255C1.8050300@ericsson.com> <4F32567F.8030401@ericsson.com> In-Reply-To: <4F32567F.8030401@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.65] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 11:58:53.0420 (UTC) FILETIME=[073392C0:01CCE659] Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:59:02 -0000 +1 >-----Original Message----- >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >Of Stefan Hakansson LK >Sent: Wednesday, February 08, 2012 4:33 PM >To: mmusic@ietf.org >Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE > >Being involved in the rtcweb/webrtc work, I would like this proposal to >move forward (as it solves an important problem in that context). > >Stefan > >On 02/08/2012 12:00 PM, Stefan H=E5kansson LK wrote: >> Hi, >> >> At the Taipei IETF I presented the BUNDLE draft, written by myself and >> Harald, which extends the SDP grouping framework in order to allow the >> usage of identical port values in multiple m- lines in an SDP >> offer/answer. >> >> >> >> http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiati >> on-00.txt >> >> It can be used when negotiating the usage of multiplexing of multiple >> media streams. Such mechanism is very likely going to be needed e.g. >> in the work being done in RTCWEB. >> >> When presented, some people indicated that they may want to look at >> other alternatives. >> >> However, as no alternative solutions have been brought forward since >> then, my question is whether people now would be interested in moving >> ahead with the BUNDLE mechanism, and adopt the above draft as a >> starting point? >> >> Best regards, >> >> Christer > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From md3135@att.com Wed Feb 8 17:44:57 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370AB21F8496 for ; Wed, 8 Feb 2012 17:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahd7V7HK+YV6 for ; Wed, 8 Feb 2012 17:44:56 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8005721F848A for ; Wed, 8 Feb 2012 17:44:56 -0800 (PST) X-Env-Sender: md3135@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1328751895!63496232!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9740 invoked from network); 9 Feb 2012 01:44:55 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2012 01:44:55 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q191jPW8031566; Wed, 8 Feb 2012 20:45:25 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q191jJ54031476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 20:45:21 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 8 Feb 2012 20:44:37 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.140]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 20:44:37 -0500 From: "DOLLY, MARTIN C" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Suggestion to moving ahead with BUNDLE Thread-Index: AQHM4BlkoRrWUt69ykuo5ZFipVGDNJYz2DkA Date: Thu, 9 Feb 2012 01:44:35 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9B3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9B3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.45.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 01:44:57 -0000 +1, move forward with the BUNDLE mechanism. Useful for rich communications -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Tuesday, January 31, 2012 8:09 AM To: mmusic@ietf.org Subject: [MMUSIC] Suggestion to moving ahead with BUNDLE Hi, At the Taipei IETF I presented the BUNDLE draft, written by myself and Hara= ld, which extends the SDP grouping framework in order to allow the usage of= identical port values in multiple m- lines in an SDP offer/answer. http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-00= .txt It can be used when negotiating the usage of multiplexing of multiple media= streams. Such mechanism is very likely going to be needed e.g. in the work= being done in RTCWEB. When presented, some people indicated that they may want to look at other a= lternatives. However, as no alternative solutions have been brought forward since then, = my question is whether people now would be interested in moving ahead with = the BUNDLE mechanism, and adopt the above draft as a starting point? Best regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From R.Jesske@telekom.de Wed Feb 8 18:32:55 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE3011E8093 for ; Wed, 8 Feb 2012 18:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrWpAJJGvPMe for ; Wed, 8 Feb 2012 18:32:55 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8263111E8073 for ; Wed, 8 Feb 2012 18:32:54 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 09 Feb 2012 03:32:43 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.157]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Thu, 9 Feb 2012 03:32:43 +0100 From: To: , , Date: Thu, 9 Feb 2012 03:32:41 +0100 Thread-Topic: Suggestion to moving ahead with BUNDLE Thread-Index: AQHM4BlkoRrWUt69ykuo5ZFipVGDNJYz2DkAgAANvMA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D135DB7893D@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9B3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 02:32:55 -0000 +1 -----Urspr=FCngliche Nachricht----- Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im Auftrag vo= n DOLLY, MARTIN C Gesendet: Donnerstag, 9. Februar 2012 02:45 An: Christer Holmberg; mmusic@ietf.org Betreff: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE +1, move forward with the BUNDLE mechanism. Useful for rich +communications -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Tuesday, January 31, 2012 8:09 AM To: mmusic@ietf.org Subject: [MMUSIC] Suggestion to moving ahead with BUNDLE Hi, At the Taipei IETF I presented the BUNDLE draft, written by myself and Hara= ld, which extends the SDP grouping framework in order to allow the usage of= identical port values in multiple m- lines in an SDP offer/answer. http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-00= .txt It can be used when negotiating the usage of multiplexing of multiple media= streams. Such mechanism is very likely going to be needed e.g. in the work= being done in RTCWEB. When presented, some people indicated that they may want to look at other a= lternatives. However, as no alternative solutions have been brought forward since then, = my question is whether people now would be interested in moving ahead with = the BUNDLE mechanism, and adopt the above draft as a starting point? Best regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Thu Feb 9 00:08:59 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FAE21F8546 for ; Thu, 9 Feb 2012 00:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPBCEb37O7b2 for ; Thu, 9 Feb 2012 00:08:58 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5121F84BF for ; Thu, 9 Feb 2012 00:08:55 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-87-4f337f15b913 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 66.A6.02613.51F733F4; Thu, 9 Feb 2012 09:08:54 +0100 (CET) Received: from [159.107.24.225] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 9 Feb 2012 09:08:53 +0100 Message-ID: <4F337F14.4060902@ericsson.com> Date: Thu, 9 Feb 2012 09:08:52 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , Christer Holmberg Subject: [MMUSIC] BUNDLE: Milestone and WG item X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:08:59 -0000 As a co-chair: With respect to the BUNDLE draft: http://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/ The chairs believe that the BUNDLE draft has got quite attraction to the group, and we have seen quite a few signals that the group wants to adopt this document as a WG item back from our meeting in Taipei and lately in the mailing list. We believe we have reached consensus to request our ADs to add a milestone for negotiating the usage of multiplexing of multiple media streams, so we will proceed to ask for this new milestone. In parallel, we ought to be looking at a document that fits that milestone. At the moment, the only document that we can think of, is the mentioned BUNDLE draft. There are no other options on the table. We have seen this draft getting strong support from the community, so we believe it can be adopted as WG item as soon as we have a milestone for it. If you think the WG should not adopt draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt as a WG item, please speak now and indicate the reason. BR, Flemming and Miguel (co-chairs) -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Christian.Groves@nteczone.com Thu Feb 9 01:45:39 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1277821F86CF for ; Thu, 9 Feb 2012 01:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WriKK2eUO7au for ; Thu, 9 Feb 2012 01:45:38 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD521F86CE for ; Thu, 9 Feb 2012 01:45:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBANiTM0920feW/2dsb2JhbAAMOLIcAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBF4dquS6LTCcBAgIJDQEFBAMEBAcOBgEDCAEBJYNkIAkCAQciJoMdBKgm Received: from ppp118-209-247-150.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.247.150]) by ipmail06.adl2.internode.on.net with ESMTP; 09 Feb 2012 20:15:36 +1030 Message-ID: <4F3395B8.1030905@nteczone.com> Date: Thu, 09 Feb 2012 20:45:28 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9B3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9B3@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 09:45:39 -0000 There's a few nits but the draft is a good starting point. Regards, Christian On 1/02/2012 12:08 AM, Christer Holmberg wrote: > Hi, > > At the Taipei IETF I presented the BUNDLE draft, written by myself and Harald, which extends the SDP grouping framework in order to allow the usage of identical port values in multiple m- lines in an SDP offer/answer. > > > > http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > It can be used when negotiating the usage of multiplexing of multiple media streams. Such mechanism is very likely going to be needed e.g. in the work being done in RTCWEB. > > When presented, some people indicated that they may want to look at other alternatives. > > However, as no alternative solutions have been brought forward since then, my question is whether people now would be interested in moving ahead with the BUNDLE mechanism, and adopt the above draft as a starting point? > > Best regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From mike.severa@alcatel-lucent.com Thu Feb 9 09:57:12 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C415F21E8014 for ; Thu, 9 Feb 2012 09:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ1VYEHYy+GX for ; Thu, 9 Feb 2012 09:57:12 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F2DE821F857D for ; Thu, 9 Feb 2012 09:57:11 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q19Hv8vW028054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2012 11:57:08 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q19Hv7du007926 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Feb 2012 11:57:07 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 9 Feb 2012 11:57:07 -0600 From: "Severa, Michael J (Mike)" To: Stefan Hakansson LK , "mmusic@ietf.org" Date: Thu, 9 Feb 2012 11:57:04 -0600 Thread-Topic: [MMUSIC] Suggestion to moving ahead with BUNDLE Thread-Index: AczmUiar8hSJ9A7LRj6TUXzQeIrO/AA/uR+A Message-ID: References: <4F3255C1.8050300@ericsson.com> <4F32567F.8030401@ericsson.com> In-Reply-To: <4F32567F.8030401@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:57:12 -0000 Just out of curiosity, how does this relate/compare to RFC5888? Was there m= uch thought put into usage within RTSP environments?=20 Thanks, MIke -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Stefan Hakansson LK Sent: Wednesday, February 08, 2012 3:03 AM To: mmusic@ietf.org Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE Being involved in the rtcweb/webrtc work, I would like this proposal to mov= e forward (as it solves an important problem in that context). Stefan On 02/08/2012 12:00 PM, Stefan H=E5kansson LK wrote: > Hi, > > At the Taipei IETF I presented the BUNDLE draft, written by myself and=20 > Harald, which extends the SDP grouping framework in order to allow the=20 > usage of identical port values in multiple m- lines in an SDP=20 > offer/answer. > > > > http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiati > on-00.txt > > It can be used when negotiating the usage of multiplexing of multiple=20 > media streams. Such mechanism is very likely going to be needed e.g.=20 > in the work being done in RTCWEB. > > When presented, some people indicated that they may want to look at=20 > other alternatives. > > However, as no alternative solutions have been brought forward since=20 > then, my question is whether people now would be interested in moving=20 > ahead with the BUNDLE mechanism, and adopt the above draft as a=20 > starting point? > > Best regards, > > Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu Feb 9 12:53:54 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DA421E8011 for ; Thu, 9 Feb 2012 12:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk4LINCQip6x for ; Thu, 9 Feb 2012 12:53:51 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8751421E8019 for ; Thu, 9 Feb 2012 12:53:51 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id XsbD1i0041ap0As57wtrs3; Thu, 09 Feb 2012 20:53:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id Xwtr1i01v07duvL3iwtrVN; Thu, 09 Feb 2012 20:53:51 +0000 Message-ID: <4F34325E.1050402@alum.mit.edu> Date: Thu, 09 Feb 2012 15:53:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F3255C1.8050300@ericsson.com> <4F32567F.8030401@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 20:53:54 -0000 On 2/9/12 12:57 PM, Severa, Michael J (Mike) wrote: > Just out of curiosity, how does this relate/compare to RFC5888? From 5888: 8.5.3. Same IP Address and Port Number If media streams using several different codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in the same "m" line MUST be used. FID MUST NOT be used to group "m" lines with the same IP address/port. Thanks, Paul > Was there much thought put into usage within RTSP environments? > > Thanks, > > MIke > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > Sent: Wednesday, February 08, 2012 3:03 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE > > Being involved in the rtcweb/webrtc work, I would like this proposal to move forward (as it solves an important problem in that context). > > Stefan > > On 02/08/2012 12:00 PM, Stefan Håkansson LK wrote: >> Hi, >> >> At the Taipei IETF I presented the BUNDLE draft, written by myself and >> Harald, which extends the SDP grouping framework in order to allow the >> usage of identical port values in multiple m- lines in an SDP >> offer/answer. >> >> >> >> http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiati >> on-00.txt >> >> It can be used when negotiating the usage of multiplexing of multiple >> media streams. Such mechanism is very likely going to be needed e.g. >> in the work being done in RTCWEB. >> >> When presented, some people indicated that they may want to look at >> other alternatives. >> >> However, as no alternative solutions have been brought forward since >> then, my question is whether people now would be interested in moving >> ahead with the BUNDLE mechanism, and adopt the above draft as a >> starting point? >> >> Best regards, >> >> Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Thu Feb 9 14:57:09 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7D11E808F for ; Thu, 9 Feb 2012 14:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is5s6Uo7yKHN for ; Thu, 9 Feb 2012 14:57:08 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3764A11E8073 for ; Thu, 9 Feb 2012 14:57:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AC5D39E132; Thu, 9 Feb 2012 23:57:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdHAvdEV3DrF; Thu, 9 Feb 2012 23:57:06 +0100 (CET) Received: from [10.216.248.90] (unknown [65.91.55.132]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4DE5C39E0BC; Thu, 9 Feb 2012 23:57:05 +0100 (CET) Message-ID: <4F344F3D.2020909@alvestrand.no> Date: Thu, 09 Feb 2012 14:57:01 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Severa, Michael J (Mike)" References: <4F3255C1.8050300@ericsson.com> <4F32567F.8030401@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Stefan Hakansson LK , "mmusic@ietf.org" Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:57:09 -0000 On 02/09/2012 09:57 AM, Severa, Michael J (Mike) wrote: > Just out of curiosity, how does this relate/compare to RFC5888? It is a direct application of the mechanism that RFC 5888 provides. Note: It is completely independent of the FID specification in RFC 5888. > Was there much thought put into usage within RTSP environments? None at all as far as I know; the requirement that led to this being written came from a pure RTP environment. > Thanks, > > MIke > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > Sent: Wednesday, February 08, 2012 3:03 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Suggestion to moving ahead with BUNDLE > > Being involved in the rtcweb/webrtc work, I would like this proposal to move forward (as it solves an important problem in that context). > > Stefan > > On 02/08/2012 12:00 PM, Stefan Håkansson LK wrote: >> Hi, >> >> At the Taipei IETF I presented the BUNDLE draft, written by myself and >> Harald, which extends the SDP grouping framework in order to allow the >> usage of identical port values in multiple m- lines in an SDP >> offer/answer. >> >> >> >> http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiati >> on-00.txt >> >> It can be used when negotiating the usage of multiplexing of multiple >> media streams. Such mechanism is very likely going to be needed e.g. >> in the work being done in RTCWEB. >> >> When presented, some people indicated that they may want to look at >> other alternatives. >> >> However, as no alternative solutions have been brought forward since >> then, my question is whether people now would be interested in moving >> ahead with the BUNDLE mechanism, and adopt the above draft as a >> starting point? >> >> Best regards, >> >> Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From capelastegui@dit.upm.es Fri Feb 10 04:33:15 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE2421F8597 for ; Fri, 10 Feb 2012 04:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKS4QKDdm77Q for ; Fri, 10 Feb 2012 04:33:12 -0800 (PST) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id EBAD421F856A for ; Fri, 10 Feb 2012 04:33:11 -0800 (PST) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id q1ACWss5031631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2012 13:32:54 +0100 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1ACWf4f018165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Feb 2012 13:32:43 +0100 From: "Pedro Capelastegui" To: "'Bert Greevenbosch'" , "'IETF - MMUSIC'" References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> Date: Fri, 10 Feb 2012 13:32:55 +0100 Message-ID: <000001cce7f0$1e5e5e10$5b1b1a30$@dit.upm.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CCE7F8.8025D350" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRyta7TmVXwvE3HuLTDxRY731ujJcsSAKw Content-Language: es Subject: Re: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:33:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CCE7F8.8025D350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bert, =20 After taking another look at the =933d format=94 draft, I have found a = few additional issues. They are summarized below: =20 1) Encoding of auxiliary stream: In the =93video plus auxiliary = stream=94 schemes using a single stream (i.e. =93LD=94, =93LP=94, =93CD=94, and = =93CP=94), no encoding information is provided for the auxiliary stream.=20 2) Ambiguous negotiation for scenarios with multiple 3D streams: = There is no clear way for an offerer to indicate when multiple 3D streams = (e.g. to show in multiple displays) are offered, as opposed to a single 3D stream with several possible configurations. 3) Support for H264/MVC streams: The H264/MVC codec is very well = suited for 3d video applications. It uses some encoding formats that are not supported by the current draft but could be added without much effort. I=92ll cover each topic in a separate mail. Here is some discussion on = point 1), auxiliary stream encoding. =20 Auxiliary video streams such as depth maps or parallax can be encoded, = just like any other video stream. In the =93Signal 3d format=94 draft, the = encoding for these streams can be described and negotiated normally when they are transmitted as separate RTP streams. However, this is no longer true = when depth or parallax maps are encapsulated with a regular view as a single = RTP stream, as defined in ISO 23002-3. This corresponds to the formats = =932DA CD=94, =932DA CP=94 , =932DA LD=94 and =932DA LP=94 in the draft. =20 It could be assumed that, since no encoding information is provided for these streams, they can use the same encoding used for the video view = they are encapsulated with. As an example, consider the following stream: =20 m=3Dvideo 49170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:2DA CD =20 The above lines describe a video stream representing a central view, = with a depth map included in the same RTP stream as auxiliary data. The central view is encoded in H264, but the depth map encoding is undefined. We = could solve this by stating in the draft that, when no encoding is specified = for an auxiliary stream, it uses the same configuration as the same view. = Thus, the depth map in the example would also use H264. =20 I think this works well as a default assumption. However, it does not = cover all possible scenarios, as the auxiliary stream CAN use a different = format than the base view. In fact, that will likely be the best performing configuration, since depth maps have different properties than regular = video streams, and codecs like H264 don=92t perform particularly well with = them.=20 =20 To address this, we would need a way to express the media format for auxiliary streams. At the very least, this would involve including the information normally expressed in =93a=3Drtpmap=94 and =93a=3Dfmtp=94 = attributes. =20 One possible way to do this would be to add the values of these = attributes (for the auxiliary map) as optional parameters in the =93a=3D3dformat=94 attribute. In the previous example, this could look as follows:=20 =20 m=3Dvideo 49170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:2DA CD aux-map:H264/90000 aux-fmtp:(=85) =20 A limitation of this approach is that it just describes a single = encoding for the auxiliary map. Ideally, a solution should allow the offerer to suggest multiple configurations from which the answerer can choose one, = as with any media stream in the offer/answer model. For this, we could = define a new attribute, like =93a=3D3daux=94, and include in it a payload type = number, the value of =93a=3Drtpmap=94 for the auxiliary stream, and the value of = =93a=3Dfmtp=94 for that stream. It could look as follows: =20 m=3Dvideo 49170 RTP/AVP 99 100 a=3D3dFormat:2DA CD=20 a=3Drtpmap:99 H264/90000 a=3D3daux: 99 H263/90000 aux-fmtp:(=85) a=3Drtpmap:100 H264/90000 a=3D3daux: 100 H264/90000 aux-fmtp:(=85) =20 In this example, the offerer is providing two possible configurations: =20 - PT 99: Central view encoded in H.264, depth map encoded in = H.263 - PT 100: Central view and depth map encoded in H.264 =20 In addition, there may be other SDP fields or attributes that have to be taken into account while signalling these auxiliary streams.=20 =20 Best regards, Pedro =20 =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Bert Greevenbosch Sent: Monday, February 06, 2012 1:32 AM To: IETF - MMUSIC Subject: [MMUSIC] The 3D drafts =20 Hi all, =20 I was wondering, if everybody is happy with the current versions of the = 3D drafts, or are there still open issues? I look forward to your comments. =20 Best regards, Bert =20 http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ _____ =20 No se encontraron virus en este mensaje. Comprobado por AVG - www.avg.com Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de publicaci=F3n: 02/05/12 ------=_NextPart_000_0001_01CCE7F8.8025D350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Bert,

 

After taking another look at the “3d = format” draft, I have found a few additional issues. They are = summarized below:

 

1)      = Encoding of auxiliary stream: In the = “video plus auxiliary stream” schemes using a single stream = (i.e. “LD”, “LP”,=A0 “CD”, and=A0 = “CP”), no encoding information is provided for the auxiliary = stream.

2)      = Ambiguous negotiation for scenarios with = multiple 3D streams: There is no clear way for an offerer to indicate = when multiple 3D streams (e.g. to show in multiple displays) are = offered, as opposed to a single 3D stream with several possible = configurations.

3)      = Support for H264/MVC streams: The H264/MVC codec = is very well suited for 3d video applications. It uses some encoding = formats that are not supported by the current draft but could be added = without much effort.

I’ll cover = each topic in a separate mail. Here is some discussion on point 1), = auxiliary stream encoding.

 

Auxiliary = video streams such as depth maps or parallax can be encoded, just like = any other video stream. In the “Signal 3d format” draft, the = encoding for these streams can be described and negotiated normally when = they are transmitted as separate RTP streams. However, this is no longer = true when depth or parallax maps are encapsulated with a regular view as = a single RTP stream, as defined in ISO 23002-3. This corresponds to the = formats “2DA CD”, “2DA CP” , “2DA = LD” and “2DA LP” in the draft.

 

It could be = assumed that, since no encoding information is provided for these = streams, they can use the same encoding used for the video view they are = encapsulated with. As an example, consider the following = stream:

 

m=3Dvideo 49170 RTP/AVP = 99

a=3Drtpmap:99 H264/90000

a=3D3dFormat:2DA = CD

 

The above lines describe a video stream representing a = central view, with a depth map included in the same RTP stream as = auxiliary data. The central view is encoded in H264, but the depth map = encoding is undefined. We could solve this by stating in the draft that, = when no encoding is specified for an auxiliary stream, it uses the same = configuration as the same view. Thus, the depth map in the example would = also use H264.

 

I think this = works well as a default assumption. However, it does not cover all = possible scenarios, as the auxiliary stream CAN use a different format = than the base view. In fact, that will likely be the best performing = configuration, since depth maps have different properties than regular = video streams, and codecs like H264 don’t perform particularly = well with them.

 

To address = this, we would need a way to express the media format for auxiliary = streams. At the very least, this would involve including the information = normally expressed in “a=3Drtpmap” and = “a=3Dfmtp” attributes.

 

One possible = way to do this would be to add the values of these attributes (for the = auxiliary map) as optional parameters in the “a=3D3dformat” = attribute. In the previous example, this could look as follows: =

 

m=3Dvideo 49170 RTP/AVP = 99

a=3Drtpmap:99 H264/90000

a=3D3dFormat:2DA CD = aux-map:H264/90000 aux-fmtp:(…)

 

A limitation = of this approach is that it just describes a single encoding for the = auxiliary map. Ideally, a solution should allow the offerer to suggest = multiple configurations from which the answerer can choose one, as with = any media stream in the offer/answer model. For this, we could define a = new attribute, like “a=3D3daux”, and include in it a payload = type number, the value of “a=3Drtpmap” for the auxiliary = stream, and the value of “a=3Dfmtp” for that stream. It = could look as follows:

 

m=3Dvideo 49170 RTP/AVP 99 = 100

a=3D3dFormat:2DA CD

a=3Drtpmap:99 = H264/90000

a=3D3daux: 99 H263/90000 = aux-fmtp:(…)

a=3Drtpmap:100 H264/90000

a=3D3daux: 100 H264/90000 = aux-fmtp:(…)

 

In this example, the offerer is providing two possible = configurations:

 

-          = PT 99:=A0 Central view encoded in H.264, depth = map encoded in H.263

-          = PT 100: Central view and depth map encoded in = H.264

 

In addition, there may be other SDP fields or = attributes that have to be taken into account while signalling these = auxiliary streams.

 

Best = regards,

Pedro

 

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Bert Greevenbosch
Sent: Monday, February 06, 2012 1:32 = AM
To: IETF - MMUSIC
Subject: [MMUSIC] The 3D = drafts

 

Hi = all,

 

I was wondering, if everybody is happy with the = current versions of the 3D drafts, or are there still open = issues?

I look forward to your = comments.

 

Best regards,

Bert

 

http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribut= e/

http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/

No se encontraron virus = en este mensaje.
Comprobado por AVG - www.avg.com
Versi=F3n: 10.0.1424 / = Base de datos de virus: 2112/4791 - Fecha de publicaci=F3n: = 02/05/12

------=_NextPart_000_0001_01CCE7F8.8025D350-- From capelastegui@dit.upm.es Fri Feb 10 08:38:16 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C6821F85FF for ; Fri, 10 Feb 2012 08:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw3hubK4KrR3 for ; Fri, 10 Feb 2012 08:38:14 -0800 (PST) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id A780D21F8606 for ; Fri, 10 Feb 2012 08:38:13 -0800 (PST) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id q1AGbj2x004270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2012 17:37:45 +0100 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1AGbYLX032210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Feb 2012 17:37:34 +0100 From: "Pedro Capelastegui" To: "'Bert Greevenbosch'" , "'IETF - MMUSIC'" References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> Date: Fri, 10 Feb 2012 17:37:47 +0100 Message-ID: <000b01cce812$52af7e70$f80e7b50$@dit.upm.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CCE81A.B476F3B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRyta7TmVXwvE3HuLTDxRY731ujJcsjfpQ Content-Language: es Subject: Re: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:38:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000C_01CCE81A.B476F3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bert, =20 Another open issue for the =933d format=94 draft was the negotiation of = sessions with more than one 3D stream. I discuss it in this mail. In the current version of the draft, it is possible to set up a session = with multiple 3D streams. An offerer can include several 3D streams in its = SDP, and the answerer can select any number of them. There are rules that = prevent the answerer from selecting more streams than it can process. However, nothing stops an answerer from selecting more streams than _the offerer_ = can send or receive =96 in fact, the answerer has no way to know how many = streams can be handled by the offerer. This can come up even in very simple scenarios. Consider the following offer: =20 m=3Dvideo 1111 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:FP SbS m=3Dvideo 1112 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:FP TaB =20 This SDP is intended as an offer of a single 3D stream with 2 possible configurations: frame-packed side-by-side, and top-bottom. The UA = generating the offer expects the answerer to select only one 3D format. But the answerer doesn=92t know that, and it=92s perfectly legal for it to = respond by selecting both 3D formats:=20 =20 m=3Dvideo 2222 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:FP SbS m=3Dvideo 2223 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:FP TaB =20 At this point, the offerer is receiving media that it=92s not prepared = to handle (which goes against the offer/answer model), and should either re-invite, or close the session. =20 How to avoid this scenario? =20 The straightforward solution is to forbid answerers from selecting more = than one 3D format altogether. This is certainly effective, but too limiting, = as it rules out the possibility of multi-stream 3D sessions. =20 A better solution would be to create a new session level attribute (=93a=3Dmax3dstreams=94) for the offerer to indicate the maximum number = of 3D streams it wants for this session. The default value for this attribute would be =911=92, so that the attribute would only be needed for = sessions with multiple streams.=20 =20 This should cover most scenarios, but there are a few corner cases that = are left unsupported. Consider a user agent that wants to initiate a session with 2 3D streams, with the constraint that one of the streams needs to = have 2 views, and the other needs to have a view and a depth map. This is a = rare scenario, but it can happen if the UA has different 3D screens, one = taking left and right views as input, and the other using video+depth map: =20 a=3Dmax3dstreams:2 m=3Dvideo 1111 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:FP SbS m=3Dvideo 1112 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:FP TaB m=3Dvideo 1113 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:2DA CD =20 For this UA, an answer selecting =93FP SbS=94 and =932DA CD=94 as 3d = formats, or =93FP TaB=94 and =932DA CD=94 would be acceptable, but one with =93FP SbS=94 = and =93FP TaB=94 would not. =20 We could extend the signalling to cover this kind of scenario (e.g. by introducing a new type of grouping), but I think this would be too = complex, and not worth the effort. In these cases, the offerer can start by configuring the session with a single 3D stream, and add any additional = 3D streams in later offer/answer exchanges. =20 Best regards, Pedro =20 =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Bert Greevenbosch Sent: Monday, February 06, 2012 1:32 AM To: IETF - MMUSIC Subject: [MMUSIC] The 3D drafts =20 Hi all, =20 I was wondering, if everybody is happy with the current versions of the = 3D drafts, or are there still open issues? I look forward to your comments. =20 Best regards, Bert =20 http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ _____ =20 No se encontraron virus en este mensaje. Comprobado por AVG - www.avg.com Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de publicaci=F3n: 02/05/12 ------=_NextPart_000_000C_01CCE81A.B476F3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Bert,

 

Another open issue for the “3d format” = draft was the negotiation of sessions with more than one 3D stream. I = discuss it in this mail.

In the = current version of the draft, it is possible to set up a session with = multiple 3D streams. An offerer can include several 3D streams in its = SDP, and the answerer can select any number of them. There are rules = that prevent the answerer from selecting more streams than it can = process. However, nothing stops an answerer from selecting more streams = than _the offerer_ can send or receive – in fact, the answerer has = no way to know how many streams can be handled by the = offerer.

This can come up even in = very simple scenarios. Consider the following offer:

 

m=3Dvideo 1111 RTP/AVP 99

a=3Drtpmap:99 = H264/90000

a=3D3dFormat:FP SbS

m=3Dvideo 1112 RTP/AVP = 99

a=3Drtpmap:99 H264/90000

a=3D3dFormat:FP = TaB

 

This SDP is intended as an offer of a single 3D stream = with 2 possible configurations: frame-packed side-by-side, and = top-bottom. The UA generating the offer expects the answerer to select = only one 3D format. But the answerer doesn’t know that, and = it’s perfectly legal for it to respond by selecting both 3D = formats:

 

m=3Dvideo 2222 RTP/AVP = 99

a=3Drtpmap:99 H264/90000

a=3D3dFormat:FP = SbS

m=3Dvideo 2223 RTP/AVP 99

a=3Drtpmap:99 = H264/90000

a=3D3dFormat:FP TaB

 

At this = point, the offerer is receiving media that it’s not prepared to = handle (which goes against the offer/answer model), and should either = re-invite, or close the session.

 

How to avoid = this scenario?

 

The = straightforward solution is to forbid answerers from selecting more than = one 3D format altogether. This is certainly effective, but too limiting, = as it rules out the possibility of multi-stream 3D = sessions.

 

A better solution would be to create a new=A0 session = level attribute (“a=3Dmax3dstreams”) for the offerer to = indicate the maximum number of 3D streams it wants for this session. The = default value for this attribute would be ‘1’, so that the = attribute would only be needed for sessions with multiple streams. =

 

This should cover most scenarios, but there are a few = corner cases that are left unsupported. Consider a user agent that wants = to initiate a session with 2 3D streams, with the constraint that one of = the streams needs to have 2 views, and the other needs to have a view = and a depth map. This is a rare scenario, but it can happen if the UA = has different 3D screens, one taking left and right views as input, and = the other using video+depth map:

 

a=3Dmax3dstreams:2

m=3Dvideo 1111 RTP/AVP = 99

a=3Drtpmap:99 H264/90000

a=3D3dFormat:FP = SbS

m=3Dvideo 1112 RTP/AVP 99

a=3Drtpmap:99 = H264/90000

a=3D3dFormat:FP TaB

m=3Dvideo 1113 RTP/AVP = 99

a=3Drtpmap:99 H264/90000

a=3D3dFormat:2DA = CD

 

For this UA, an answer selecting “FP SbS” = and “2DA CD” as 3d formats, or “FP=A0 TaB” and = “2DA CD” would be acceptable, but one with “FP = SbS” and “FP=A0 TaB” would not.

 

We could = extend the signalling to cover this kind of scenario (e.g. by = introducing a new type of grouping), but I think this would be too = complex, and not worth the effort. In these cases, the offerer can start = by configuring the session with a single 3D stream, and add any = additional 3D streams in later offer/answer exchanges.

 

Best = regards,

Pedro

 

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Bert Greevenbosch
Sent: Monday, February 06, 2012 1:32 = AM
To: IETF - MMUSIC
Subject: [MMUSIC] The 3D = drafts

 

Hi = all,

 

I was wondering, if everybody is happy with the = current versions of the 3D drafts, or are there still open = issues?

I look forward to your = comments.

 

Best regards,

Bert

 

http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribut= e/

http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/

No se encontraron virus = en este mensaje.
Comprobado por AVG - www.avg.com
Versi=F3n: 10.0.1424 / = Base de datos de virus: 2112/4791 - Fecha de publicaci=F3n: = 02/05/12

------=_NextPart_000_000C_01CCE81A.B476F3B0-- From pkyzivat@alum.mit.edu Fri Feb 10 10:24:58 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271F521F87D0 for ; Fri, 10 Feb 2012 10:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CthlVu89oGJc for ; Fri, 10 Feb 2012 10:24:57 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9F121F86A5 for ; Fri, 10 Feb 2012 10:24:56 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id YJKD1i00716LCl055JQxrX; Fri, 10 Feb 2012 18:24:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id YJQx1i00N07duvL3SJQx6K; Fri, 10 Feb 2012 18:24:57 +0000 Message-ID: <4F3560F7.3080303@alum.mit.edu> Date: Fri, 10 Feb 2012 13:24:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> <000b01cce812$52af7e70$f80e7b50$@dit.upm.es> In-Reply-To: <000b01cce812$52af7e70$f80e7b50$@dit.upm.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:24:58 -0000 Pedro, The issue you raise here is not unique to 3D. It shows up in many forms: - an offer of multiple codecs on an m-line theoretically means the offerer can use them concurrently. But some implementations can only support one at a time. - offering seccure and insecure versions of a stream - offering ipv4 and ipv6 versions of a stream It is not desirable to come up with a 3D-specific solution to this problem. Rather you should look to what is available as a generic solution. The most obvious approach that comes to mind for me is to use the capability framework, to offer one form and describe the others as capabilities. Thanks, Paul On 2/10/12 11:37 AM, Pedro Capelastegui wrote: > Hi Bert, > > Another open issue for the “3d format” draft was the negotiation of > sessions with more than one 3D stream. I discuss it in this mail. > > In the current version of the draft, it is possible to set up a session > with multiple 3D streams. An offerer can include several 3D streams in > its SDP, and the answerer can select any number of them. There are rules > that prevent the answerer from selecting more streams than it can > process. However, nothing stops an answerer from selecting more streams > than _the offerer_ can send or receive – in fact, the answerer has no > way to know how many streams can be handled by the offerer. > > This can come up even in very simple scenarios. Consider the following > offer: > > m=video 1111 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:FP SbS > > m=video 1112 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:FP TaB > > This SDP is intended as an offer of a single 3D stream with 2 possible > configurations: frame-packed side-by-side, and top-bottom. The UA > generating the offer expects the answerer to select only one 3D format. > But the answerer doesn’t know that, and it’s perfectly legal for it to > respond by selecting both 3D formats: > > m=video 2222 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:FP SbS > > m=video 2223 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:FP TaB > > At this point, the offerer is receiving media that it’s not prepared to > handle (which goes against the offer/answer model), and should either > re-invite, or close the session. > > How to avoid this scenario? > > The straightforward solution is to forbid answerers from selecting more > than one 3D format altogether. This is certainly effective, but too > limiting, as it rules out the possibility of multi-stream 3D sessions. > > A better solution would be to create a new session level attribute > (“a=max3dstreams”) for the offerer to indicate the maximum number of 3D > streams it wants for this session. The default value for this attribute > would be ‘1’, so that the attribute would only be needed for sessions > with multiple streams. > > This should cover most scenarios, but there are a few corner cases that > are left unsupported. Consider a user agent that wants to initiate a > session with 2 3D streams, with the constraint that one of the streams > needs to have 2 views, and the other needs to have a view and a depth > map. This is a rare scenario, but it can happen if the UA has different > 3D screens, one taking left and right views as input, and the other > using video+depth map: > > a=max3dstreams:2 > > m=video 1111 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:FP SbS > > m=video 1112 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:FP TaB > > m=video 1113 RTP/AVP 99 > > a=rtpmap:99 H264/90000 > > a=3dFormat:2DA CD > > For this UA, an answer selecting “FP SbS” and “2DA CD” as 3d formats, or > “FP TaB” and “2DA CD” would be acceptable, but one with “FP SbS” and > “FP TaB” would not. > > We could extend the signalling to cover this kind of scenario (e.g. by > introducing a new type of grouping), but I think this would be too > complex, and not worth the effort. In these cases, the offerer can start > by configuring the session with a single 3D stream, and add any > additional 3D streams in later offer/answer exchanges. > > Best regards, > > Pedro > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Bert Greevenbosch > *Sent:* Monday, February 06, 2012 1:32 AM > *To:* IETF - MMUSIC > *Subject:* [MMUSIC] The 3D drafts > > Hi all, > > I was wondering, if everybody is happy with the current versions of the > 3D drafts, or are there still open issues? > > I look forward to your comments. > > Best regards, > > Bert > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ > > ------------------------------------------------------------------------ > > No se encontraron virus en este mensaje. > Comprobado por AVG - www.avg.com > Versión: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de > publicación: 02/05/12 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Bert.Greevenbosch@huawei.com Sun Feb 12 19:13:13 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32E821F8711 for ; Sun, 12 Feb 2012 19:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9LYnSzn1TTe for ; Sun, 12 Feb 2012 19:13:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 229AE21F86EB for ; Sun, 12 Feb 2012 19:13:09 -0800 (PST) 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 <0LZB0045YA873O@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 13 Feb 2012 11:12:07 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZB00IAOA8785@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 13 Feb 2012 11:12:07 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHB25907; Mon, 13 Feb 2012 11:12:05 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Feb 2012 11:12:02 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.226]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 13 Feb 2012 11:11:49 +0800 Date: Mon, 13 Feb 2012 03:11:49 +0000 From: Bert Greevenbosch In-reply-to: <4F3560F7.3080303@alum.mit.edu> X-Originating-IP: [10.70.109.135] To: Paul Kyzivat , "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB62327158E@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] The 3D drafts Thread-index: AczkZrAV0ElkOsHfT6KQFeCWDlQX8QDaJPOAAAO92IAAhyw2EA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> <000b01cce812$52af7e70$f80e7b50$@dit.upm.es> <4F3560F7.3080303@alum.mit.edu> Subject: Re: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 03:13:13 -0000 Hi Pedro, Thank you for your feedback. I will soon reply to your other e-mail, about = the simulcast case, too. As to the issue with multiple offered streams, this has been considered in = the draft. Especially, section 7 contains the following text: " The following statements apply for the answerer: ... o If the answerer selects multiple 3D formats, it MUST be prepared to send/receive (depending on whether it is a streaming server or client or both) associated streams simultaneously. The following statements apply for the offerer: ... o When multiple 3D formats are selected, the offerer MAY initiate all associated streams. Alternatively, it MAY update its offer with a reduced number of 3D formats. " As you wrote below, indeed the draft proposes re-negotiation if the offerer= doesn't like the choice of the answerer. Why do you think this should be avoided? Best regards, Bert -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 11 February 2012 02:25 To: mmusic@ietf.org Subject: Re: [MMUSIC] The 3D drafts Pedro, The issue you raise here is not unique to 3D. It shows up in many forms: - an offer of multiple codecs on an m-line theoretically means the offerer can use them concurrently. But some implementations can only support one at a time. - offering seccure and insecure versions of a stream - offering ipv4 and ipv6 versions of a stream It is not desirable to come up with a 3D-specific solution to this=20 problem. Rather you should look to what is available as a generic solution. The most obvious approach that comes to mind for me is to use the=20 capability framework, to offer one form and describe the others as=20 capabilities. Thanks, Paul On 2/10/12 11:37 AM, Pedro Capelastegui wrote: > Hi Bert, > > Another open issue for the "3d format" draft was the negotiation of > sessions with more than one 3D stream. I discuss it in this mail. > > In the current version of the draft, it is possible to set up a session > with multiple 3D streams. An offerer can include several 3D streams in > its SDP, and the answerer can select any number of them. There are rules > that prevent the answerer from selecting more streams than it can > process. However, nothing stops an answerer from selecting more streams > than _the offerer_ can send or receive - in fact, the answerer has no > way to know how many streams can be handled by the offerer. > > This can come up even in very simple scenarios. Consider the following > offer: > > m=3Dvideo 1111 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:FP SbS > > m=3Dvideo 1112 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:FP TaB > > This SDP is intended as an offer of a single 3D stream with 2 possible > configurations: frame-packed side-by-side, and top-bottom. The UA > generating the offer expects the answerer to select only one 3D format. > But the answerer doesn't know that, and it's perfectly legal for it to > respond by selecting both 3D formats: > > m=3Dvideo 2222 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:FP SbS > > m=3Dvideo 2223 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:FP TaB > > At this point, the offerer is receiving media that it's not prepared to > handle (which goes against the offer/answer model), and should either > re-invite, or close the session. > > How to avoid this scenario? > > The straightforward solution is to forbid answerers from selecting more > than one 3D format altogether. This is certainly effective, but too > limiting, as it rules out the possibility of multi-stream 3D sessions. > > A better solution would be to create a new session level attribute > ("a=3Dmax3dstreams") for the offerer to indicate the maximum number of 3D > streams it wants for this session. The default value for this attribute > would be '1', so that the attribute would only be needed for sessions > with multiple streams. > > This should cover most scenarios, but there are a few corner cases that > are left unsupported. Consider a user agent that wants to initiate a > session with 2 3D streams, with the constraint that one of the streams > needs to have 2 views, and the other needs to have a view and a depth > map. This is a rare scenario, but it can happen if the UA has different > 3D screens, one taking left and right views as input, and the other > using video+depth map: > > a=3Dmax3dstreams:2 > > m=3Dvideo 1111 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:FP SbS > > m=3Dvideo 1112 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:FP TaB > > m=3Dvideo 1113 RTP/AVP 99 > > a=3Drtpmap:99 H264/90000 > > a=3D3dFormat:2DA CD > > For this UA, an answer selecting "FP SbS" and "2DA CD" as 3d formats, or > "FP TaB" and "2DA CD" would be acceptable, but one with "FP SbS" and > "FP TaB" would not. > > We could extend the signalling to cover this kind of scenario (e.g. by > introducing a new type of grouping), but I think this would be too > complex, and not worth the effort. In these cases, the offerer can start > by configuring the session with a single 3D stream, and add any > additional 3D streams in later offer/answer exchanges. > > Best regards, > > Pedro > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Bert Greevenbosch > *Sent:* Monday, February 06, 2012 1:32 AM > *To:* IETF - MMUSIC > *Subject:* [MMUSIC] The 3D drafts > > Hi all, > > I was wondering, if everybody is happy with the current versions of the > 3D drafts, or are there still open issues? > > I look forward to your comments. > > Best regards, > > Bert > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ > > ------------------------------------------------------------------------ > > No se encontraron virus en este mensaje. > Comprobado por AVG - www.avg.com > Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de > publicaci=F3n: 02/05/12 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From capelastegui@dit.upm.es Mon Feb 13 09:02:31 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A2821F8460 for ; Mon, 13 Feb 2012 09:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98tHfm1ohmds for ; Mon, 13 Feb 2012 09:02:30 -0800 (PST) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id C105421F845E for ; Mon, 13 Feb 2012 09:02:29 -0800 (PST) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id q1DH1xGj021109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 18:01:59 +0100 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1DH1lBU002942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Feb 2012 18:01:48 +0100 From: "Pedro Capelastegui" To: "'Bert Greevenbosch'" , "'Paul Kyzivat'" , References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> <000b01cce812$52af7e70$f80e7b50$@dit.upm.es> <4F3560F7.3080303@alum.mit.edu> <46A1DF3F04371240B504290A071B4DB62327158E@szxeml509-mbs.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB62327158E@szxeml509-mbs.china.huawei.com> Date: Mon, 13 Feb 2012 18:01:57 +0100 Message-ID: <002401ccea71$327675d0$97636170$@dit.upm.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRyta7TmVXwvE3HuLTDxRY731ujAG+Y5EKAfztBYwCuejHa5b9onOA Content-Language: es Subject: Re: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 17:02:31 -0000 Hi Bert, My main concern is that the offerer may end up receiving more video = streams than it wants and, more importantly, more than it can process. Although = the draft does allow for re-negotiating the session to reduce the number of streams, this still leaves a window where an excess of streams is transmitted, leading to wasted bandwidth, and potentially overloading = the offerer=92s network or terminal. As a side effect, when QoS systems are used, this may result in = excessive bandwidth reservations, or in rejected sessions due to insufficient = network resources. Note that, while I also discussed re-negotiating sessions in my message, = my proposal in that case was to start out with a single stream and add more later, ruling out the possibility of transmitting unwanted streams. That said, there is one point that I hadn=92t really taken into = consideration until Paul brought it up: the potential for an offerer to receive lots = of unwanted streams already exists in other SDP offer/answer scenarios. Notably, this includes offers with multiple media formats for a m=3D = line, (which describes almost every SDP offer in existence). So it=92s = possible that the problem is less severe than I originally thought, but also more = general than this specific 3D video scenario. I=92ll need to give this issue = some thought. Best regards, Pedro > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Bert Greevenbosch > Sent: Monday, February 13, 2012 4:12 AM > To: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] The 3D drafts >=20 > Hi Pedro, >=20 > Thank you for your feedback. I will soon reply to your other e-mail, = about the > simulcast case, too. >=20 > As to the issue with multiple offered streams, this has been = considered in > the draft. Especially, section 7 contains the following text: >=20 > " > The following statements apply for the answerer: > ... > o If the answerer selects multiple 3D formats, it MUST be prepared > to send/receive (depending on whether it is a streaming server = or > client or both) associated streams simultaneously. >=20 > The following statements apply for the offerer: > ... > o When multiple 3D formats are selected, the offerer MAY initiate > all associated streams. Alternatively, it MAY update its offer > with a reduced number of 3D formats. > " >=20 > As you wrote below, indeed the draft proposes re-negotiation if the offerer > doesn't like the choice of the answerer. >=20 > Why do you think this should be avoided? >=20 > Best regards, > Bert >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 11 February 2012 02:25 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] The 3D drafts >=20 > Pedro, >=20 > The issue you raise here is not unique to 3D. > It shows up in many forms: >=20 > - an offer of multiple codecs on an m-line > theoretically means the offerer can use them concurrently. > But some implementations can only support one at a time. >=20 > - offering seccure and insecure versions of a stream >=20 > - offering ipv4 and ipv6 versions of a stream >=20 > It is not desirable to come up with a 3D-specific solution to this problem. > Rather you should look to what is available as a generic solution. >=20 > The most obvious approach that comes to mind for me is to use the capability > framework, to offer one form and describe the others as capabilities. >=20 > Thanks, > Paul >=20 > On 2/10/12 11:37 AM, Pedro Capelastegui wrote: > > Hi Bert, > > > > Another open issue for the "3d format" draft was the negotiation of > > sessions with more than one 3D stream. I discuss it in this mail. > > > > In the current version of the draft, it is possible to set up a > > session with multiple 3D streams. An offerer can include several 3D > > streams in its SDP, and the answerer can select any number of them. > > There are rules that prevent the answerer from selecting more = streams > > than it can process. However, nothing stops an answerer from = selecting > > more streams than _the offerer_ can send or receive - in fact, the > > answerer has no way to know how many streams can be handled by the > offerer. > > > > This can come up even in very simple scenarios. Consider the = following > > offer: > > > > m=3Dvideo 1111 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:FP SbS > > > > m=3Dvideo 1112 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:FP TaB > > > > This SDP is intended as an offer of a single 3D stream with 2 = possible > > configurations: frame-packed side-by-side, and top-bottom. The UA > > generating the offer expects the answerer to select only one 3D = format. > > But the answerer doesn't know that, and it's perfectly legal for it = to > > respond by selecting both 3D formats: > > > > m=3Dvideo 2222 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:FP SbS > > > > m=3Dvideo 2223 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:FP TaB > > > > At this point, the offerer is receiving media that it's not prepared > > to handle (which goes against the offer/answer model), and should > > either re-invite, or close the session. > > > > How to avoid this scenario? > > > > The straightforward solution is to forbid answerers from selecting > > more than one 3D format altogether. This is certainly effective, but > > too limiting, as it rules out the possibility of multi-stream 3D sessions. > > > > A better solution would be to create a new session level attribute > > ("a=3Dmax3dstreams") for the offerer to indicate the maximum number = of > > 3D streams it wants for this session. The default value for this > > attribute would be '1', so that the attribute would only be needed = for > > sessions with multiple streams. > > > > This should cover most scenarios, but there are a few corner cases > > that are left unsupported. Consider a user agent that wants to > > initiate a session with 2 3D streams, with the constraint that one = of > > the streams needs to have 2 views, and the other needs to have a = view > > and a depth map. This is a rare scenario, but it can happen if the = UA > > has different 3D screens, one taking left and right views as input, > > and the other using video+depth map: > > > > a=3Dmax3dstreams:2 > > > > m=3Dvideo 1111 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:FP SbS > > > > m=3Dvideo 1112 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:FP TaB > > > > m=3Dvideo 1113 RTP/AVP 99 > > > > a=3Drtpmap:99 H264/90000 > > > > a=3D3dFormat:2DA CD > > > > For this UA, an answer selecting "FP SbS" and "2DA CD" as 3d = formats, > > or "FP TaB" and "2DA CD" would be acceptable, but one with "FP SbS" > > and "FP TaB" would not. > > > > We could extend the signalling to cover this kind of scenario (e.g. = by > > introducing a new type of grouping), but I think this would be too > > complex, and not worth the effort. In these cases, the offerer can > > start by configuring the session with a single 3D stream, and add = any > > additional 3D streams in later offer/answer exchanges. > > > > Best regards, > > > > Pedro > > > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > *On > > Behalf Of *Bert Greevenbosch > > *Sent:* Monday, February 06, 2012 1:32 AM > > *To:* IETF - MMUSIC > > *Subject:* [MMUSIC] The 3D drafts > > > > Hi all, > > > > I was wondering, if everybody is happy with the current versions of > > the 3D drafts, or are there still open issues? > > > > I look forward to your comments. > > > > Best regards, > > > > Bert > > > > = http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ > > > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ > > > > = ---------------------------------------------------------------------- > > -- > > > > No se encontraron virus en este mensaje. > > Comprobado por AVG - www.avg.com > > Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de > > publicaci=F3n: 02/05/12 > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > ----- > No se encontraron virus en este mensaje. > Comprobado por AVG - www.avg.com > Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4800 - Fecha de publicaci=F3n: > 02/09/12 From aallen@rim.com Mon Feb 13 14:15:57 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8329721E8040 for ; Mon, 13 Feb 2012 14:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWgym5XtUibe for ; Mon, 13 Feb 2012 14:15:55 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0B21E8012 for ; Mon, 13 Feb 2012 14:15:55 -0800 (PST) X-AuditID: 0a41282f-b7f296d0000023a6-e9-4f398b9ac008 Received: from XHT108CNC.rim.net (xht108cnc.rim.net [10.65.22.54]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 9C.E1.09126.A9B893F4; Mon, 13 Feb 2012 22:15:54 +0000 (GMT) Received: from XCT105ADS.rim.net (10.67.111.46) by XHT108CNC.rim.net (10.65.22.54) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 13 Feb 2012 17:15:54 -0500 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.01.0339.001; Mon, 13 Feb 2012 16:15:52 -0600 From: Andrew Allen To: "Miguel.A.Garcia@ericsson.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Do we need to update in time 4566bis? Thread-Index: AQHM3bebVRFX2+nLu0aBhobCdNRG1JY7fqjX Date: Mon, 13 Feb 2012 22:15:52 +0000 Message-ID: In-Reply-To: <4F23E8A7.7070302@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsXC5Shmpjur29Lf4EmPgsWaTyvYLaYuf8zi wOTx6+tVNo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9sq+aSmJ+YoBBRlliUmVyq4ZBYn5yRm 5qYWKSlkptgqmSgpFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/ XQsLU0tdQyU7XSSQ8I8741TnK8aCLuGKrhcTmBoY9/N3MXJwSAiYSDy6UtbFyAlkiklcuLee DcQWEuhhktgy17WLkQvIXsooce37SmYIZwujxOJ/j1hBqtgElCWW/57BCGKLCGRI3D9xgwlk qLCAtcTylXIgpoiAjcShjVCmkcSaXguQYhYBVYkFd6cxgdi8Am4S52bsAxvIKaAj8fH9ImYQ mxHonO+n1oDVMAuIS9x6Mp8J4kwBiSV7zjND2KISLx//Y4WwFSWeNG5mgajXk7gxdQobhK0t sWzha2aIXYISJ2c+YYF4UVpix8k1jBMYxWYhWTELSfssJO2zkLQvYGRZxSiYm1FsYGaQnJes V5SZq5eXWrKJEZwgNPR3MPbt1TrEKMDBqMTDW9hq6S/EmlhWXJl7iFGCg1lJhFcvxsJfiDcl sbIqtSg/vqg0J7X4EKMFMFQmMktxJ+cDk1deSbyxgQEKR0mcd/FKLX8hgXRgKspOTS1ILYJp ZeLglGpgbPivXbRkVlMh1+ED1aaWWhvu1N6Py5DyVJQIsPdt3S3+vNLNuvtHd0usSNRN0yX2 ge8mvVH4Gnyn54XZ0hoXM6M43kqNis+7V2tdy/Kpt9mWWqkifdGIe8UVkWez33/QmunNcMan wnyu4+2MDXNO7eoS21dW//3Fkr9P3iz7UH5LneeScYeREktxRqKhFnNRcSIAwa05zCkDAAA= Subject: Re: [MMUSIC] Do we need to update in time 4566bis? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:15:57 -0000 What about considering a hitchhikers guide to SDP similar to what was done f= or SIP? One umbrella document that points the reader to all the SDP capabilities ava= ilable that they might want to take advantage of. Just a suggestion. Andrew ----- Original Message ----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Saturday, January 28, 2012 06:23 AM=0A= To: mmusic Subject: [MMUSIC] Do we need to update in time 4566bis? Hi all, You know we are revising RFC 4566. So far, the effort has been in bug fixing= . The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years ago), and was then revised as RFC 4566 in 2006. Lots of things have happened since then. We have SDP offer answer, Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. From the point of view of a reader who takes 4566 (or its current 4566bis incarnation), I think it will be difficult for her or him to understand a protocol that ignores those other extensions. For example, I recently post another e-mail where there is an apparent contradiction between 4566 and ICE (see http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). So, I was wondering if time has come to make not a bug correction in 4566bis, but also put that RFC in context with the other extensions that exist. This may include: - Add minor extensions to the core document, similarly to what we did with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know which of these= extensions make sense to include, this would be an exercise to do, but let me give you one potential example: RFC 4574, the SDP "label" attribute is a 6 pages RFC. - Adding references to extensions, when it makes sense. For example, ICE should be referred somewhere (see my previous post regarding the "o" line). I guess capneg could be also mentioned, perhaps others. I know this is a bigger effort than anticipated, but the result could really help newcomers to this world. Now, it is your turn to express your opinions. Please do it. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From kpfleming@digium.com Mon Feb 13 15:28:28 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B6E21F86DA for ; Mon, 13 Feb 2012 15:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.245 X-Spam-Level: X-Spam-Status: No, score=-106.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjZkl67NBw56 for ; Mon, 13 Feb 2012 15:28:27 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id C771C21F86D9 for ; Mon, 13 Feb 2012 15:28:27 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Rx5Jq-0005VW-HX for mmusic@ietf.org; Mon, 13 Feb 2012 17:28:26 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 861F5D8005 for ; Mon, 13 Feb 2012 17:28:26 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcvsJGqrEUyF for ; Mon, 13 Feb 2012 17:28:26 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 08238D8004 for ; Mon, 13 Feb 2012 17:28:26 -0600 (CST) Message-ID: <4F399C99.6000202@digium.com> Date: Mon, 13 Feb 2012 17:28:25 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120206051555.83B2E62176@rfc-editor.org> In-Reply-To: <20120206051555.83B2E62176@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3107) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:28:28 -0000 On 02/05/2012 11:15 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5245, > "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3107 > > -------------------------------------- > Type: Technical > Reported by: N V S Kaushik > > Section: Appendix B.6 > > Original Text > ------------- > However, the check from agent R has not yet generated a response, and agent R receives the updated offer (message 7) before getting the response (message 9). > > Corrected Text > -------------- > However, the check from agent R has not yet received a response, and agent R receives the updated offer (message 7) before getting the response (message 9). > > Notes > ----- > Here Agent R(ideally Agent B as per the figure 11) has generated the request, so it must receive the response. The original text may give a meaning that Agent R has to generate a response. This section needs quite a bit of fixing, actually. The agent designators don't match the Figure at all (agent L in the text is Agent A in the figure, and agent R in the text is agent B in the figure). However, this errata is correct: in the figure, agent A *has* generated a response, but it was lost, and so agent B has not received it. It would possibly be clearer to word this as: However, the response generated by agent A (message 6) was not received by agent B, and agent B receives the updated offer (message 7) before receiving the response (message 9). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From kpfleming@digium.com Mon Feb 13 15:32:52 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174EA21F871C for ; Mon, 13 Feb 2012 15:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkPe9ll0Ba4G for ; Mon, 13 Feb 2012 15:32:51 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36E21F8713 for ; Mon, 13 Feb 2012 15:32:51 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Rx5O6-0005az-O3 for mmusic@ietf.org; Mon, 13 Feb 2012 17:32:50 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id B9A66D8005 for ; Mon, 13 Feb 2012 17:32:50 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx-by3sp95Ln for ; Mon, 13 Feb 2012 17:32:50 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 531AED8004 for ; Mon, 13 Feb 2012 17:32:50 -0600 (CST) Message-ID: <4F399DA1.2000203@digium.com> Date: Mon, 13 Feb 2012 17:32:49 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F312BCF.9090506@ericsson.com> In-Reply-To: <4F312BCF.9090506@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Proposed change in 4566bis for private addresses X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:32:52 -0000 On 02/07/2012 07:49 AM, Miguel A. Garcia wrote: > I do agree with the proposal. I also agree with the proposal, although after the first time I read it I wasn't sure. I think the issue is that use of ICE (or similar mechanisms) makes it impractical for the offerer to know conclusively what the 'scope' of an SDP description actually is. Since that is the case, the safer route is to allow local addresses to appear in the SDP description, in case they can be used by the receiver. > > /Miguel > > On 06/02/2012 22:42, Ali C. Begen (abegen) wrote: >> Currently, RFC 4566 section 5.2 states the following: >> >> is the address of the machine from which the >> session was created. For an address type of IP4, this is either >> the fully qualified domain name of the machine or the dotted- >> decimal representation of the IP version 4 address of the machine. >> For an address type of IP6, this is either the fully qualified >> domain name of the machine or the compressed textual >> representation of the IP version 6 address of the machine. For >> both IP4 and IP6, the fully qualified domain name is the form that >> SHOULD be given unless this is unavailable, in which case the >> globally unique address MAY be substituted. A local IP address >> MUST NOT be used in any context where the SDP description might >> leave the scope in which the address is meaningful (for example, a >> local address MUST NOT be included in an application-level >> referral that might leave the scope). >> >> The last portion contradicts with what ICE-like solutions have. So, we >> suggest to change the last portion as: >> >> >> Unless an SDP extension for NAT traversal is used (e.g., ICE [RFC >> 5245], ICE TCP [draft-ietf-mmusic-ice-tcp]) a local IP address >> MUST NOT be used in any context where the SDP description might >> leave the scope in which the address is meaningful (for example, a >> local address MUST NOT be included in an application-level >> referral that might leave the scope). >> >> >> And the referred RFC/draft will be added to the informative reference >> list. >> >> Please comment on this change. A new revision will be posted well >> before the next meeting. >> >> Thanks, >> -acbegen >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From miguel.a.garcia@ericsson.com Mon Feb 13 23:42:16 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E09C21E8048 for ; Mon, 13 Feb 2012 23:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.302 X-Spam-Level: X-Spam-Status: No, score=-10.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qo-9ACLOnP5 for ; Mon, 13 Feb 2012 23:42:16 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A61EE21E803C for ; Mon, 13 Feb 2012 23:42:15 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-cc-4f3a1056b3a0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.A7.27041.6501A3F4; Tue, 14 Feb 2012 08:42:14 +0100 (CET) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012 08:42:14 +0100 Message-ID: <4F3A1055.10804@ericsson.com> Date: Tue, 14 Feb 2012 08:42:13 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Andrew Allen References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Do we need to update in time 4566bis? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 07:42:16 -0000 Sounds good to me too. If someone wants to start such draft... /Miguel On 13/02/2012 23:15, Andrew Allen wrote: > > What about considering a hitchhikers guide to SDP similar to what was done for SIP? > > One umbrella document that points the reader to all the SDP capabilities available that they might want to take advantage of. > > Just a suggestion. > > Andrew > > ----- Original Message ----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Saturday, January 28, 2012 06:23 AM > To: mmusic > Subject: [MMUSIC] Do we need to update in time 4566bis? > > > > Hi all, > > You know we are revising RFC 4566. So far, the effort has been in bug fixing. > > The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years > ago), and was then revised as RFC 4566 in 2006. > > Lots of things have happened since then. We have SDP offer answer, > Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, > labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. > > From the point of view of a reader who takes 4566 (or its current > 4566bis incarnation), I think it will be difficult for her or him to > understand a protocol that ignores those other extensions. For example, I > recently post another e-mail where there is an apparent contradiction > between 4566 and ICE (see > http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). > > So, I was wondering if time has come to make not a bug correction in > 4566bis, but also put that RFC in context with the other extensions that > exist. This may include: > > - Add minor extensions to the core document, similarly to what we did > with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which of these > extensions make sense to include, this would be an exercise to do, but > let me give you one potential example: RFC 4574, the SDP "label" > attribute is a 6 pages RFC. > > - Adding references to extensions, when it makes sense. For example, ICE > should be referred somewhere (see my previous post regarding the "o" > line). I guess capneg could be also mentioned, perhaps others. > > I know this is a bigger effort than anticipated, but the result could > really help newcomers to this world. > > Now, it is your turn to express your opinions. Please do it. > > /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Bert.Greevenbosch@huawei.com Tue Feb 14 22:30:36 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8FD21F85E0 for ; Tue, 14 Feb 2012 22:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkwfNwnSxOW4 for ; Tue, 14 Feb 2012 22:30:36 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5D33221F86BD for ; Tue, 14 Feb 2012 22:30:35 -0800 (PST) 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 <0LZF00EAK8OHHJ@szxga03-in.huawei.com> for mmusic@ietf.org; Wed, 15 Feb 2012 14:29:05 +0800 (CST) Received: from szxrg02-dlp.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 <0LZF0047U8O4PA@szxga03-in.huawei.com> for mmusic@ietf.org; Wed, 15 Feb 2012 14:29:05 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHC96929; Wed, 15 Feb 2012 14:29:04 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 14:28:58 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.226]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 14:29:01 +0800 Date: Wed, 15 Feb 2012 06:29:01 +0000 From: Bert Greevenbosch In-reply-to: <4F3A1055.10804@ericsson.com> X-Originating-IP: [10.70.109.135] To: "Miguel A. Garcia" , Andrew Allen Message-id: <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Hitchhiker's guide to SDP (was: "RE: [MMUSIC] Do we need to update in time 4566bis?") Thread-index: AQHM66sbN3SfQND40UK6utKf2hyBpw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3A1055.10804@ericsson.com> Cc: "mmusic@ietf.org" Subject: [MMUSIC] Hitchhiker's guide to SDP (was: "RE: Do we need to update in time 4566bis?") X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:30:36 -0000 Hi Miguel, Andrew, all, Sounds like a good idea. I would be happy to volunteer to play a central role in it (i.e. be the editor, create the initial draft, ...), but I would need support from other experts too. As for practicalities, I see that the "Hitchhiker's Guide to SIP" has become an RFC (5411). That means that it has been frozen, and to add new info new individual or WG drafts are needed. Would this be the same approach for SDP? Currently, there are already quite some new drafts that extend SDP. How will future extensions be handled? Maybe it would be good to make it a permanent WG draft, which is updated every now and then. Best regards, Bert -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia Sent: 14 February 2012 15:42 To: Andrew Allen Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Do we need to update in time 4566bis? Sounds good to me too. If someone wants to start such draft... /Miguel On 13/02/2012 23:15, Andrew Allen wrote: > > What about considering a hitchhikers guide to SDP similar to what was done for SIP? > > One umbrella document that points the reader to all the SDP capabilities available that they might want to take advantage of. > > Just a suggestion. > > Andrew > > ----- Original Message ----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Saturday, January 28, 2012 06:23 AM > To: mmusic > Subject: [MMUSIC] Do we need to update in time 4566bis? > > > > Hi all, > > You know we are revising RFC 4566. So far, the effort has been in bug fixing. > > The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years > ago), and was then revised as RFC 4566 in 2006. > > Lots of things have happened since then. We have SDP offer answer, > Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, > labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. > > From the point of view of a reader who takes 4566 (or its current > 4566bis incarnation), I think it will be difficult for her or him to > understand a protocol that ignores those other extensions. For example, I > recently post another e-mail where there is an apparent contradiction > between 4566 and ICE (see > http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). > > So, I was wondering if time has come to make not a bug correction in > 4566bis, but also put that RFC in context with the other extensions that > exist. This may include: > > - Add minor extensions to the core document, similarly to what we did > with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which of these > extensions make sense to include, this would be an exercise to do, but > let me give you one potential example: RFC 4574, the SDP "label" > attribute is a 6 pages RFC. > > - Adding references to extensions, when it makes sense. For example, ICE > should be referred somewhere (see my previous post regarding the "o" > line). I guess capneg could be also mentioned, perhaps others. > > I know this is a bigger effort than anticipated, but the result could > really help newcomers to this world. > > Now, it is your turn to express your opinions. Please do it. > > /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mary.ietf.barnes@gmail.com Wed Feb 15 09:14:44 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C621F84FA for ; Wed, 15 Feb 2012 09:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.64 X-Spam-Level: X-Spam-Status: No, score=-103.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93eFFdxubpo2 for ; Wed, 15 Feb 2012 09:14:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6F21F8468 for ; Wed, 15 Feb 2012 09:14:38 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1025293vcb.31 for ; Wed, 15 Feb 2012 09:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vui1mI66w2ipy5sgV4aU18qVeW/vdhyuOsKRwE8XxCY=; b=BTH+AccAPHIctjS/n6jwY8MUk0iSUDBn9yRgUOLfDHz6UnaONUvwdoTGHmgBFHCQGT qqUynpgQsPVUNWAguhNVqQJ5QUHNR+7n0SsjFttdwaDazhGx8Dzj0x1tAWmAU9X4j3Jd zqigfUZZd0FVs/tm/8EclU2yRkX/eLVh5G5c0= MIME-Version: 1.0 Received: by 10.52.67.35 with SMTP id k3mr11477011vdt.38.1329326076621; Wed, 15 Feb 2012 09:14:36 -0800 (PST) Received: by 10.52.114.200 with HTTP; Wed, 15 Feb 2012 09:14:36 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> Date: Wed, 15 Feb 2012 11:14:36 -0600 Message-ID: From: Mary Barnes To: Bert Greevenbosch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP (was: "RE: Do we need to update in time 4566bis?") X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:14:44 -0000 I think this is a good idea. I would think the experts that can contribute (and should review) can be found in the new SDP directorate: http://www.ietf.org/iesg/directorate/sdp.html BTW, it would be nice to have a link to this page on the MMUSIC WG wiki: http://trac.tools.ietf.org/wg/mmusic/trac/wiki As far as whether to publish, I think it would be a good idea to complete publication as IMHO that improves the integrity of the information - i.e., more eyes review a published RFC than a draft. It could later be updated to reflect more recent RFCs OR a "More of Hitchhikers Guide" could be published. Thanks, Mary. On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch wrote: > Hi Miguel, Andrew, all, > > Sounds like a good idea. I would be happy to volunteer to play a central = role in it (i.e. be the editor, create the initial draft, ...), but I would= need support from other experts too. > > As for practicalities, I see that the "Hitchhiker's Guide to SIP" has bec= ome an RFC (5411). That means that it has been frozen, and to add new info = new individual or WG drafts are needed. > > Would this be the same approach for SDP? Currently, there are already qui= te some new drafts that extend SDP. How will future extensions be handled? = Maybe it would be good to make it a permanent WG draft, which is updated ev= ery now and then. > > Best regards, > Bert > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Miguel A. Garcia > Sent: 14 February 2012 15:42 > To: Andrew Allen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > > Sounds good to me too. If someone wants to start such draft... > > /Miguel > > On 13/02/2012 23:15, Andrew Allen wrote: >> >> What about considering a hitchhikers guide to SDP similar to what was do= ne for SIP? >> >> One umbrella document that points the reader to all the SDP capabilities= available that they might want to take advantage of. >> >> Just a suggestion. >> >> Andrew >> >> ----- Original Message ----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: Saturday, January 28, 2012 06:23 AM >> To: mmusic >> Subject: [MMUSIC] Do we need to update in time 4566bis? >> >> >> >> Hi all, >> >> You know we are revising RFC 4566. So far, the effort has been in bug fi= xing. >> >> The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years >> ago), and was then revised as RFC 4566 in 2006. >> >> Lots of things have happened since then. We have SDP offer answer, >> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, >> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. >> >> =A0 From the point of view of a reader who takes 4566 (or its current >> 4566bis incarnation), I think it will be difficult for her or him to >> understand a protocol that ignores those other extensions. For example, = I >> recently post another e-mail where there is an apparent contradiction >> between 4566 and ICE (see >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >> >> So, I was wondering if time has come to make not a bug correction in >> 4566bis, but also put that RFC in context with the other extensions that >> exist. This may include: >> >> - Add minor extensions to the core document, similarly to what we did >> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know which of th= ese >> extensions make sense to include, this would be an exercise to do, but >> let me give you one potential example: RFC 4574, the SDP "label" >> attribute is a 6 pages RFC. >> >> - Adding references to extensions, when it makes sense. For example, ICE >> should be referred somewhere (see my previous post regarding the "o" >> line). I guess capneg could be also mentioned, perhaps others. >> >> I know this is a bigger effort than anticipated, but the result could >> really help newcomers to this world. >> >> Now, it is your turn to express your opinions. Please do it. >> >> /Miguel > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Martin.Stiemerling@neclab.eu Tue Feb 21 02:46:28 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DD621F85E3 for ; Tue, 21 Feb 2012 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hXzAUd-OOO0 for ; Tue, 21 Feb 2012 02:46:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE2021F85E4 for ; Tue, 21 Feb 2012 02:46:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8BB1E280001D9 for ; Tue, 21 Feb 2012 11:46:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpZY8hKx2Wvx for ; Tue, 21 Feb 2012 11:46:26 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 701D528000085 for ; Tue, 21 Feb 2012 11:46:21 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 21 Feb 2012 11:46:17 +0100 From: Martin Stiemerling To: "mmusic@ietf.org" Thread-Topic: RTSP 2.0: Vary header -- where to go with this Thread-Index: AczwhUQcldcIjPHyRDWJ/lcUKRjMDA== Date: Tue, 21 Feb 2012 10:46:21 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] RTSP 2.0: Vary header -- where to go with this X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:46:28 -0000 Dear all, draft-ietf-mmusic-rfc2326bis-28 specifies the Vary header in Section 16.55.= I have included the full text if this section below, for your reference.=20 This header has been taken from HTTP/1.1 and did appear in past versions of= draft-ietf-mmusic-rfc2326bis-28 as a simple reference to HTTP, i.e., witho= ut any explanation of what this header really means in RTSP. We copied and = adapted the current text from HTTP/1.1 in one of the revisions of RTSP 2.0.= =20 However, we got the comment that Vary as operation is very unclear and it i= s unclear if any existing RTSP 1.0 implementation is actually using this. I= t might be a good first indicator that Vary is not needed in RTSP 2.0 at al= l, if there is no implementation using this in RTSP 1.0.=20 I can see why this header is available in HTTP, but I have doubts about in = RTSP.=20 Let me know your opinion. Here is the full text of Section 16.55 The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. An RTSP server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that resource. A server MAY include a Vary header field with a non- cacheable response that is subject to server-driven negotiation, since this might provide the user agent with useful information about the dimensions over which the response varies at the time of the response. A Vary field value consisting of a list of field-names signals that the representation selected for the response is based on a selection algorithm which considers ONLY the listed request-header field values in selecting the most appropriate representation. A cache MAY assume that the same selection will be made for future requests with the same values for the listed field names, for the duration of time for which the response is fresh. The field-names given are not limited to the set of standard request- header fields defined by this specification. Field names are case- insensitive. A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address of the client), play a role in the selection of the response representation. The "*" value MUST NOT be generated by a proxy server; it may only be generated by an origin server. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From gonzalo.camarillo@ericsson.com Thu Feb 23 04:30:20 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA44F21F86FD for ; Thu, 23 Feb 2012 04:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.201 X-Spam-Level: X-Spam-Status: No, score=-110.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8waDM7bPLLHd for ; Thu, 23 Feb 2012 04:30:20 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A08A721F86FC for ; Thu, 23 Feb 2012 04:30:19 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-59-4f46315aa418 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B0.4C.27041.A51364F4; Thu, 23 Feb 2012 13:30:18 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012 13:30:18 +0100 Message-ID: <4F463159.5040903@ericsson.com> Date: Thu, 23 Feb 2012 14:30:17 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mary Barnes References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:30:21 -0000 Hi Mary, yes, the members of the SDP directorate would need to review such a guide. However, the fact that they agreed to be members of the directorate does not mean they will necessarily have cycles to significantly contribute to the creation of the guide. We need to make sure we have enough energy around this effort in order to start it. Cheers, Gonzalo On 15/02/2012 7:14 PM, Mary Barnes wrote: > I think this is a good idea. I would think the experts that can > contribute (and should review) can be found in the new SDP > directorate: > http://www.ietf.org/iesg/directorate/sdp.html > BTW, it would be nice to have a link to this page on the MMUSIC WG wiki: > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > As far as whether to publish, I think it would be a good idea to > complete publication as IMHO that improves the integrity of the > information - i.e., more eyes review a published RFC than a draft. > It could later be updated to reflect more recent RFCs OR a "More of > Hitchhikers Guide" could be published. > > Thanks, > Mary. > > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > wrote: >> Hi Miguel, Andrew, all, >> >> Sounds like a good idea. I would be happy to volunteer to play a central role in it (i.e. be the editor, create the initial draft, ...), but I would need support from other experts too. >> >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" has become an RFC (5411). That means that it has been frozen, and to add new info new individual or WG drafts are needed. >> >> Would this be the same approach for SDP? Currently, there are already quite some new drafts that extend SDP. How will future extensions be handled? Maybe it would be good to make it a permanent WG draft, which is updated every now and then. >> >> Best regards, >> Bert >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >> Sent: 14 February 2012 15:42 >> To: Andrew Allen >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >> >> Sounds good to me too. If someone wants to start such draft... >> >> /Miguel >> >> On 13/02/2012 23:15, Andrew Allen wrote: >>> >>> What about considering a hitchhikers guide to SDP similar to what was done for SIP? >>> >>> One umbrella document that points the reader to all the SDP capabilities available that they might want to take advantage of. >>> >>> Just a suggestion. >>> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>> Sent: Saturday, January 28, 2012 06:23 AM >>> To: mmusic >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >>> >>> >>> >>> Hi all, >>> >>> You know we are revising RFC 4566. So far, the effort has been in bug fixing. >>> >>> The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years >>> ago), and was then revised as RFC 4566 in 2006. >>> >>> Lots of things have happened since then. We have SDP offer answer, >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. >>> >>> From the point of view of a reader who takes 4566 (or its current >>> 4566bis incarnation), I think it will be difficult for her or him to >>> understand a protocol that ignores those other extensions. For example, I >>> recently post another e-mail where there is an apparent contradiction >>> between 4566 and ICE (see >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >>> >>> So, I was wondering if time has come to make not a bug correction in >>> 4566bis, but also put that RFC in context with the other extensions that >>> exist. This may include: >>> >>> - Add minor extensions to the core document, similarly to what we did >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which of these >>> extensions make sense to include, this would be an exercise to do, but >>> let me give you one potential example: RFC 4574, the SDP "label" >>> attribute is a 6 pages RFC. >>> >>> - Adding references to extensions, when it makes sense. For example, ICE >>> should be referred somewhere (see my previous post regarding the "o" >>> line). I guess capneg could be also mentioned, perhaps others. >>> >>> I know this is a bigger effort than anticipated, but the result could >>> really help newcomers to this world. >>> >>> Now, it is your turn to express your opinions. Please do it. >>> >>> /Miguel >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From gonzalo.camarillo@ericsson.com Thu Feb 23 04:43:23 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892B21F8744 for ; Thu, 23 Feb 2012 04:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.208 X-Spam-Level: X-Spam-Status: No, score=-110.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uZw-W5HdLE0 for ; Thu, 23 Feb 2012 04:43:23 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 01AFA21F8737 for ; Thu, 23 Feb 2012 04:43:22 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-22-4f46346951d8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E5.6E.27041.964364F4; Thu, 23 Feb 2012 13:43:22 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012 13:43:21 +0100 Message-ID: <4F463469.9020607@ericsson.com> Date: Thu, 23 Feb 2012 14:43:21 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Comment on draft-holmberg-mmusic-sdp-bundle-negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:43:24 -0000 Hi, the draft explains non-normatively in its introduction what a bundle group is. However, sections after the introduction focus very much on the mechanics of the mechanism (what to put in the offers and answers) but do not spend time normatively defining how a bundle group must be handled once is established. Sections 7 and 8 touch upon that, though. The draft needs to explicitly and clearly explain what clients are supposed to do to handle a bundle group. http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00 Cheers, Gonzalo From christer.holmberg@ericsson.com Thu Feb 23 04:46:33 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E146121F874F for ; Thu, 23 Feb 2012 04:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.095 X-Spam-Level: X-Spam-Status: No, score=-10.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-nUVAkB8bGU for ; Thu, 23 Feb 2012 04:46:33 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59721F8744 for ; Thu, 23 Feb 2012 04:46:29 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-7d-4f463523454e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.05.01970.325364F4; Thu, 23 Feb 2012 13:46:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 23 Feb 2012 13:46:27 +0100 From: Christer Holmberg To: Gonzalo Camarillo , mmusic Date: Thu, 23 Feb 2012 13:46:27 +0100 Thread-Topic: [MMUSIC] Comment on draft-holmberg-mmusic-sdp-bundle-negotiation Thread-Index: AczyKLzwRuUYMCdlT+6LCdHY7qnNkwAADRBA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D961184@ESESSCMS0356.eemea.ericsson.se> References: <4F463469.9020607@ericsson.com> In-Reply-To: <4F463469.9020607@ericsson.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: [MMUSIC] Comment on draft-holmberg-mmusic-sdp-bundle-negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:46:34 -0000 Hi, > the draft explains non-normatively in its introduction what a bundle grou= p is. However, sections after the introduction focus very much on the mecha= nics of the mechanism (what to put in the=20 > offers and answers) but do not spend time normatively defining how a bund= le group must be handled once is established. Sections 7 and 8 touch upon t= hat, though. > The draft needs to explicitly and clearly explain what clients are suppos= ed to do to handle a bundle group. Yes. More text will for sure be needed until the draft is published. Thanks! Regards, Christer From mary.ietf.barnes@gmail.com Thu Feb 23 09:07:00 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109EF21F8737 for ; Thu, 23 Feb 2012 09:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.63 X-Spam-Level: X-Spam-Status: No, score=-103.63 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YLDw2IiQis2 for ; Thu, 23 Feb 2012 09:06:58 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84D6B21F86D8 for ; Thu, 23 Feb 2012 09:06:58 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1112355vcb.31 for ; Thu, 23 Feb 2012 09:06:58 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.151.5 as permitted sender) client-ip=10.220.151.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.151.5 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.220.151.5]) by 10.220.151.5 with SMTP id a5mr1577490vcw.8.1330016818177 (num_hops = 1); Thu, 23 Feb 2012 09:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+SvfgTMZzbSGgpveGjrh2eGU8fLnwVxSC0Woo+Bg4Eg=; b=xttneRcZTTVkl6gPoHimwPHEXl+dMS8OUNqs8H9FLs1Z9bM3ggibQ79zmTYGgm0X5H d6jo13dhrdWn4xsJXLcgUgzDdqY2scGY9ihEi1pVDBuevyQtSnQKBwS6TTjVqF6d52S5 l89PPsQXxW+wzuoFlJVcf4/0tcz0Ak7skkMsU= MIME-Version: 1.0 Received: by 10.220.151.5 with SMTP id a5mr1309027vcw.8.1330016818095; Thu, 23 Feb 2012 09:06:58 -0800 (PST) Received: by 10.52.114.200 with HTTP; Thu, 23 Feb 2012 09:06:58 -0800 (PST) In-Reply-To: <4F463159.5040903@ericsson.com> References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> Date: Thu, 23 Feb 2012 11:06:58 -0600 Message-ID: From: Mary Barnes To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=f46d043be016fce47404b9a4abc7 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:07:00 -0000 --f46d043be016fce47404b9a4abc7 Content-Type: text/plain; charset=ISO-8859-1 I would think that in order for the document to have integrity that at least one of the directorate members should at least be a co-author. Otherwise, I see a lot more stuff falling through the cracks and needing to be resolved during WGLC and later, which usually isn't a good thing. The SIP Hitchhiker's guide provides a good example in that the author was also a primary contributor to RFC3261, etc. Mary. On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo < Gonzalo.Camarillo@ericsson.com> wrote: > Hi Mary, > > yes, the members of the SDP directorate would need to review such a > guide. However, the fact that they agreed to be members of the > directorate does not mean they will necessarily have cycles to > significantly contribute to the creation of the guide. We need to make > sure we have enough energy around this effort in order to start it. > > Cheers, > > Gonzalo > > On 15/02/2012 7:14 PM, Mary Barnes wrote: > > I think this is a good idea. I would think the experts that can > > contribute (and should review) can be found in the new SDP > > directorate: > > http://www.ietf.org/iesg/directorate/sdp.html > > BTW, it would be nice to have a link to this page on the MMUSIC WG wiki: > > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > > > As far as whether to publish, I think it would be a good idea to > > complete publication as IMHO that improves the integrity of the > > information - i.e., more eyes review a published RFC than a draft. > > It could later be updated to reflect more recent RFCs OR a "More of > > Hitchhikers Guide" could be published. > > > > Thanks, > > Mary. > > > > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > > wrote: > >> Hi Miguel, Andrew, all, > >> > >> Sounds like a good idea. I would be happy to volunteer to play a > central role in it (i.e. be the editor, create the initial draft, ...), but > I would need support from other experts too. > >> > >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" has > become an RFC (5411). That means that it has been frozen, and to add new > info new individual or WG drafts are needed. > >> > >> Would this be the same approach for SDP? Currently, there are already > quite some new drafts that extend SDP. How will future extensions be > handled? Maybe it would be good to make it a permanent WG draft, which is > updated every now and then. > >> > >> Best regards, > >> Bert > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Miguel A. Garcia > >> Sent: 14 February 2012 15:42 > >> To: Andrew Allen > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> > >> Sounds good to me too. If someone wants to start such draft... > >> > >> /Miguel > >> > >> On 13/02/2012 23:15, Andrew Allen wrote: > >>> > >>> What about considering a hitchhikers guide to SDP similar to what was > done for SIP? > >>> > >>> One umbrella document that points the reader to all the SDP > capabilities available that they might want to take advantage of. > >>> > >>> Just a suggestion. > >>> > >>> Andrew > >>> > >>> ----- Original Message ----- > >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>> Sent: Saturday, January 28, 2012 06:23 AM > >>> To: mmusic > >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >>> > >>> > >>> > >>> Hi all, > >>> > >>> You know we are revising RFC 4566. So far, the effort has been in bug > fixing. > >>> > >>> The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years > >>> ago), and was then revised as RFC 4566 in 2006. > >>> > >>> Lots of things have happened since then. We have SDP offer answer, > >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, > >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. > >>> > >>> From the point of view of a reader who takes 4566 (or its current > >>> 4566bis incarnation), I think it will be difficult for her or him to > >>> understand a protocol that ignores those other extensions. For > example, I > >>> recently post another e-mail where there is an apparent contradiction > >>> between 4566 and ICE (see > >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). > >>> > >>> So, I was wondering if time has come to make not a bug correction in > >>> 4566bis, but also put that RFC in context with the other extensions > that > >>> exist. This may include: > >>> > >>> - Add minor extensions to the core document, similarly to what we did > >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which of > these > >>> extensions make sense to include, this would be an exercise to do, but > >>> let me give you one potential example: RFC 4574, the SDP "label" > >>> attribute is a 6 pages RFC. > >>> > >>> - Adding references to extensions, when it makes sense. For example, > ICE > >>> should be referred somewhere (see my previous post regarding the "o" > >>> line). I guess capneg could be also mentioned, perhaps others. > >>> > >>> I know this is a bigger effort than anticipated, but the result could > >>> really help newcomers to this world. > >>> > >>> Now, it is your turn to express your opinions. Please do it. > >>> > >>> /Miguel > >> > >> -- > >> Miguel A. Garcia > >> +34-91-339-3608 > >> Ericsson Spain > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > --f46d043be016fce47404b9a4abc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would think that in order for the document to have integrity that at leas= t one of the directorate members should at least be a co-author. =A0Otherwi= se, I see a lot more stuff falling through the cracks and needing to be res= olved during WGLC and later, which usually isn't a good thing. =A0The S= IP Hitchhiker's guide provides a good example in that the author was al= so a primary contributor to RFC3261, etc. =A0

Mary.=A0

On Thu, Feb 23, 2= 012 at 6:30 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
Hi Mary,

yes, the members of the SDP directorate would need to review such a
guide. However, the fact that they agreed to be members of the
directorate does not mean they will necessarily have cycles to
significantly contribute to the creation of the guide. We need to make
sure we have enough energy around this effort in order to start it.

Cheers,

Gonzalo

On 15/02/2012 7:14 PM, Mary Barnes wrote:
> I think this is a good idea. =A0I would think the experts that can
> contribute (and should review) can be found in the new SDP
> directorate:
> http://www.ietf.org/iesg/directorate/sdp.html
> BTW, it would be nice to have a link to this page on the MMUSIC WG wik= i:
> http://trac.tools.ietf.org/wg/mmusic/trac/wiki
>
> As far as whether to publish, I think it would be a good idea to
> complete publication as IMHO that improves the integrity of the
> information - i.e., more eyes review a published RFC than a draft.
> It could later be updated to reflect more recent RFCs OR a "More = of
> Hitchhikers Guide" could be published.
>
> Thanks,
> Mary.
>
> On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch
> <Bert.Greevenbosch@= huawei.com> wrote:
>> Hi Miguel, Andrew, all,
>>
>> Sounds like a good idea. I would be happy to volunteer to play a c= entral role in it (i.e. be the editor, create the initial draft, ...), but = I would need support from other experts too.
>>
>> As for practicalities, I see that the "Hitchhiker's Guide= to SIP" has become an RFC (5411). That means that it has been frozen,= and to add new info new individual or WG drafts are needed.
>>
>> Would this be the same approach for SDP? Currently, there are alre= ady quite some new drafts that extend SDP. How will future extensions be ha= ndled? Maybe it would be good to make it a permanent WG draft, which is upd= ated every now and then.
>>
>> Best regards,
>> Bert
>>
>>
>> -----Original Message-----
>> From: mmusic-bounces@ie= tf.org [mailto:mmusic-bounce= s@ietf.org] On Behalf Of Miguel A. Garcia
>> Sent: 14 February 2012 15:42
>> To: Andrew Allen
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Do we need to update in time 4566bis?
>>
>> Sounds good to me too. If someone wants to start such draft...
>>
>> /Miguel
>>
>> On 13/02/2012 23:15, Andrew Allen wrote:
>>>
>>> What about considering a hitchhikers guide to SDP similar to w= hat was done for SIP?
>>>
>>> One umbrella document that points the reader to all the SDP ca= pabilities available that they might want to take advantage of.
>>>
>>> Just a suggestion.
>>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
>>> Sent: Saturday, January 28, 2012 06:23 AM
>>> To: mmusic<mmusic@ietf.o= rg>
>>> Subject: [MMUSIC] Do we need to update in time 4566bis?
>>>
>>> <as an individual>
>>>
>>> Hi all,
>>>
>>> You know we are revising RFC 4566. So far, the effort has been= in bug fixing.
>>>
>>> The first SDP version was published as RFC 2327 in 1998 (i.e.,= 14 years
>>> ago), and was then revised as RFC 4566 in 2006.
>>>
>>> Lots of things have happened since then. We have SDP offer ans= wer,
>>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, come= ida,
>>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the= pipe.
>>>
>>> =A0 From the point of view of a reader who takes 4566 (or its = current
>>> 4566bis incarnation), I think it will be difficult for her or = him to
>>> understand a protocol that ignores those other extensions. For= example, I
>>> recently post another e-mail where there is an apparent contra= diction
>>> between 4566 and ICE (see
>>> http://www.ietf.org/mail-archive/web/mmus= ic/current/msg09089.html ).
>>>
>>> So, I was wondering if time has come to make not a bug correct= ion in
>>> 4566bis, but also put that RFC in context with the other exten= sions that
>>> exist. This may include:
>>>
>>> - Add minor extensions to the core document, similarly to what= we did
>>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't kn= ow which of these
>>> extensions make sense to include, this would be an exercise to= do, but
>>> let me give you one potential example: RFC 4574, the SDP "= ;label"
>>> attribute is a 6 pages RFC.
>>>
>>> - Adding references to extensions, when it makes sense. For ex= ample, ICE
>>> should be referred somewhere (see my previous post regarding t= he "o"
>>> line). I guess capneg could be also mentioned, perhaps others.=
>>>
>>> I know this is a bigger effort than anticipated, but the resul= t could
>>> really help newcomers to this world.
>>>
>>> Now, it is your turn to express your opinions. Please do it. >>>
>>> /Miguel
>>
>> --
>> Miguel A. Garcia
>> +34-91-33= 9-3608
>> Ericsson Spain
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


--f46d043be016fce47404b9a4abc7-- From gonzalo.camarillo@ericsson.com Thu Feb 23 09:31:03 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5921F87E2 for ; Thu, 23 Feb 2012 09:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.222 X-Spam-Level: X-Spam-Status: No, score=-110.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjG-JrSrEc5c for ; Thu, 23 Feb 2012 09:31:02 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1D66421F87D8 for ; Thu, 23 Feb 2012 09:31:01 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-d0-4f4677d4bad0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.8B.27041.4D7764F4; Thu, 23 Feb 2012 18:31:00 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012 18:31:00 +0100 Message-ID: <4F4677D3.2090406@ericsson.com> Date: Thu, 23 Feb 2012 19:30:59 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mary Barnes References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:31:03 -0000 I agree. Gonzalo On 23/02/2012 7:06 PM, Mary Barnes wrote: > I would think that in order for the document to have integrity that at > least one of the directorate members should at least be a co-author. > Otherwise, I see a lot more stuff falling through the cracks and > needing to be resolved during WGLC and later, which usually isn't a good > thing. The SIP Hitchhiker's guide provides a good example in that the > author was also a primary contributor to RFC3261, etc. > > Mary. > > On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > > > wrote: > > Hi Mary, > > yes, the members of the SDP directorate would need to review such a > guide. However, the fact that they agreed to be members of the > directorate does not mean they will necessarily have cycles to > significantly contribute to the creation of the guide. We need to make > sure we have enough energy around this effort in order to start it. > > Cheers, > > Gonzalo > > On 15/02/2012 7:14 PM, Mary Barnes wrote: > > I think this is a good idea. I would think the experts that can > > contribute (and should review) can be found in the new SDP > > directorate: > > http://www.ietf.org/iesg/directorate/sdp.html > > BTW, it would be nice to have a link to this page on the MMUSIC WG > wiki: > > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > > > As far as whether to publish, I think it would be a good idea to > > complete publication as IMHO that improves the integrity of the > > information - i.e., more eyes review a published RFC than a draft. > > It could later be updated to reflect more recent RFCs OR a "More of > > Hitchhikers Guide" could be published. > > > > Thanks, > > Mary. > > > > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > > > wrote: > >> Hi Miguel, Andrew, all, > >> > >> Sounds like a good idea. I would be happy to volunteer to play a > central role in it (i.e. be the editor, create the initial draft, > ...), but I would need support from other experts too. > >> > >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" > has become an RFC (5411). That means that it has been frozen, and to > add new info new individual or WG drafts are needed. > >> > >> Would this be the same approach for SDP? Currently, there are > already quite some new drafts that extend SDP. How will future > extensions be handled? Maybe it would be good to make it a permanent > WG draft, which is updated every now and then. > >> > >> Best regards, > >> Bert > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org ] On > Behalf Of Miguel A. Garcia > >> Sent: 14 February 2012 15:42 > >> To: Andrew Allen > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> > >> Sounds good to me too. If someone wants to start such draft... > >> > >> /Miguel > >> > >> On 13/02/2012 23:15, Andrew Allen wrote: > >>> > >>> What about considering a hitchhikers guide to SDP similar to > what was done for SIP? > >>> > >>> One umbrella document that points the reader to all the SDP > capabilities available that they might want to take advantage of. > >>> > >>> Just a suggestion. > >>> > >>> Andrew > >>> > >>> ----- Original Message ----- > >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com > ] > >>> Sent: Saturday, January 28, 2012 06:23 AM > >>> To: mmusic> > >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >>> > >>> > >>> > >>> Hi all, > >>> > >>> You know we are revising RFC 4566. So far, the effort has been > in bug fixing. > >>> > >>> The first SDP version was published as RFC 2327 in 1998 (i.e., > 14 years > >>> ago), and was then revised as RFC 4566 in 2006. > >>> > >>> Lots of things have happened since then. We have SDP offer answer, > >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, > >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. > >>> > >>> From the point of view of a reader who takes 4566 (or its current > >>> 4566bis incarnation), I think it will be difficult for her or him to > >>> understand a protocol that ignores those other extensions. For > example, I > >>> recently post another e-mail where there is an apparent > contradiction > >>> between 4566 and ICE (see > >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). > >>> > >>> So, I was wondering if time has come to make not a bug correction in > >>> 4566bis, but also put that RFC in context with the other > extensions that > >>> exist. This may include: > >>> > >>> - Add minor extensions to the core document, similarly to what > we did > >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which > of these > >>> extensions make sense to include, this would be an exercise to > do, but > >>> let me give you one potential example: RFC 4574, the SDP "label" > >>> attribute is a 6 pages RFC. > >>> > >>> - Adding references to extensions, when it makes sense. For > example, ICE > >>> should be referred somewhere (see my previous post regarding the "o" > >>> line). I guess capneg could be also mentioned, perhaps others. > >>> > >>> I know this is a bigger effort than anticipated, but the result > could > >>> really help newcomers to this world. > >>> > >>> Now, it is your turn to express your opinions. Please do it. > >>> > >>> /Miguel > >> > >> -- > >> Miguel A. Garcia > >> +34-91-339-3608 > >> Ericsson Spain > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > From zhou.sujing@zte.com.cn Thu Feb 23 16:22:24 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B05C21F88A2 for ; Thu, 23 Feb 2012 16:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.089 X-Spam-Level: X-Spam-Status: No, score=-98.089 tagged_above=-999 required=5 tests=[AWL=1.890, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QI358gm4lRw for ; Thu, 23 Feb 2012 16:22:23 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A930521F88B9 for ; Thu, 23 Feb 2012 16:22:22 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280978252052; Fri, 24 Feb 2012 07:52:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 49762.978252052; Fri, 24 Feb 2012 08:21:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1O0M27S010635 for ; Fri, 24 Feb 2012 08:22:03 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: "mmusic@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 24 Feb 2012 08:21:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-24 08:22:04, Serialize complete at 2012-02-24 08:22:04 Content-Type: multipart/alternative; boundary="=_alternative 000205EA482579AE_=" X-MAIL: mse02.zte.com.cn q1O0M27S010635 Subject: [MMUSIC] Will MMUSIC have a time slot at IETF 83? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:22:24 -0000 This is a multipart message in MIME format. --=_alternative 000205EA482579AE_= Content-Type: text/plain; charset="US-ASCII" Regards~~~ -Sujing Zhou --=_alternative 000205EA482579AE_= Content-Type: text/html; charset="US-ASCII"
Regards~~~

-Sujing Zhou --=_alternative 000205EA482579AE_=-- From miguel.a.garcia@ericsson.com Thu Feb 23 22:49:02 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7721F872B for ; Thu, 23 Feb 2012 22:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-74D5vxQSCE for ; Thu, 23 Feb 2012 22:49:01 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 533F821F862D for ; Thu, 23 Feb 2012 22:49:01 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-b3-4f4732db0a68 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.20.01970.BD2374F4; Fri, 24 Feb 2012 07:49:00 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012 07:48:59 +0100 Message-ID: <4F4732DB.6000505@ericsson.com> Date: Fri, 24 Feb 2012 07:48:59 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "zhou.sujing@zte.com.cn" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Will MMUSIC have a time slot at IETF 83? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 06:49:02 -0000 Yes, MMUSIC has been allocated a timeslot on Monday from 0900 until 1130. We just got this information. https://datatracker.ietf.org/meeting/83/agenda.html /Miguel On 24/02/2012 1:21, zhou.sujing@zte.com.cn wrote: > > Regards~~~ > > -Sujing Zhou -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From internet-drafts@ietf.org Thu Feb 23 23:02:01 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68621F86C2; Thu, 23 Feb 2012 23:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9s5BGU-Y7Sm; Thu, 23 Feb 2012 23:02:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A613721F86B6; Thu, 23 Feb 2012 23:01:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120224070144.20140.13888.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 23:01:44 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:02:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Pages : 11 Date : 2012-02-23 This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiatio= n-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation= -00.txt From zhou.sujing@zte.com.cn Thu Feb 23 23:17:03 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24D821F871C for ; Thu, 23 Feb 2012 23:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.613 X-Spam-Level: X-Spam-Status: No, score=-94.613 tagged_above=-999 required=5 tests=[AWL=-1.823, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlTXlbsv1Ple for ; Thu, 23 Feb 2012 23:17:03 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBCC21E801E for ; Thu, 23 Feb 2012 23:17:00 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280978252052; Fri, 24 Feb 2012 14:47:26 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 60473.1006590112; Fri, 24 Feb 2012 15:16:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1O7Gf68028813; Fri, 24 Feb 2012 15:16:41 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F4732DB.6000505@ericsson.com> To: "Miguel A. Garcia" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 24 Feb 2012 15:16:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-24 15:16:42, Serialize complete at 2012-02-24 15:16:42 Content-Type: multipart/alternative; boundary="=_alternative 0027FC45482579AE_=" X-MAIL: mse01.zte.com.cn q1O7Gf68028813 Cc: "mmusic@ietf.org" Subject: [MMUSIC] =?gb2312?b?tPC4tDogUmU6ICBXaWxsIE1NVVNJQyBoYXZlIGEgdGlt?= =?gb2312?b?ZSBzbG90IGF0IElFVEYgODM/?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:17:03 -0000 This is a multipart message in MIME format. --=_alternative 0027FC45482579AE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlbiBob3cgY2FuIEkgYXBwbHkgZm9yIGEgcHJlc2VudGF0aW9uo78NClJlZ2FyZHN+fn4NCg0K LVN1amluZyBaaG91DQoNCiJNaWd1ZWwgQS4gR2FyY2lhIiA8TWlndWVsLkEuR2FyY2lhQGVyaWNz c29uLmNvbT4g0LTT2iAyMDEyLTAyLTI0IA0KMTQ6NDg6NTk6DQoNCj4gWWVzLCBNTVVTSUMgaGFz IGJlZW4gYWxsb2NhdGVkIGEgdGltZXNsb3Qgb24gTW9uZGF5IGZyb20gMDkwMCB1bnRpbCANCjEx MzAuIA0KPiBXZSBqdXN0IGdvdCB0aGlzIGluZm9ybWF0aW9uLg0KPiANCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzgzL2FnZW5kYS5odG1sDQo+IA0KPiAvTWlndWVsDQo+ IA0KPiBPbiAyNC8wMi8yMDEyIDE6MjEsIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gd3JvdGU6DQo+ ID4NCj4gPiBSZWdhcmRzfn5+DQo+ID4NCj4gPiAtU3VqaW5nIFpob3UNCj4gDQo+IC0tIA0KPiBN aWd1ZWwgQS4gR2FyY2lhDQo+ICszNC05MS0zMzktMzYwOA0KPiBFcmljc3NvbiBTcGFpbg0KPiAN Cg0K --=_alternative 0027FC45482579AE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4gaG93IGNhbiBJIGFwcGx5 IGZvciBhIHByZXNlbnRhdGlvbqO/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5SZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1amluZyBaaG91PC9mb250Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7TWlndWVsIEEuIEdhcmNpYSZxdW90OyAmbHQ7TWln dWVsLkEuR2FyY2lhQGVyaWNzc29uLmNvbSZndDsNCtC009ogMjAxMi0wMi0yNCAxNDo0ODo1OTo8 YnI+DQo8YnI+DQomZ3Q7IFllcywgTU1VU0lDIGhhcyBiZWVuIGFsbG9jYXRlZCBhIHRpbWVzbG90 IG9uIE1vbmRheSBmcm9tIDA5MDAgdW50aWwNCjExMzAuIDxicj4NCiZndDsgV2UganVzdCBnb3Qg dGhpcyBpbmZvcm1hdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzgzL2FnZW5kYS5odG1sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9N aWd1ZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMjQvMDIvMjAxMiAxOjIxLCB6aG91LnN1amlu Z0B6dGUuY29tLmNuIHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRz fn5+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC1TdWppbmcgWmhvdTxicj4NCiZndDsg PGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IE1pZ3VlbCBBLiBHYXJjaWE8YnI+DQomZ3Q7ICszNC05 MS0zMzktMzYwODxicj4NCiZndDsgRXJpY3Nzb24gU3BhaW48YnI+DQomZ3Q7IDxicj4NCjwvZm9u dD48L3R0Pg0K --=_alternative 0027FC45482579AE_=-- From miguel.a.garcia@ericsson.com Thu Feb 23 23:19:45 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D621F8611 for ; Thu, 23 Feb 2012 23:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot3wllpUgDVK for ; Thu, 23 Feb 2012 23:19:44 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3B21F8604 for ; Thu, 23 Feb 2012 23:19:42 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-30-4f473a0d3850 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D3.8F.27041.D0A374F4; Fri, 24 Feb 2012 08:19:41 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012 08:19:41 +0100 Message-ID: <4F473A0C.7060407@ericsson.com> Date: Fri, 24 Feb 2012 08:19:40 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Agenda requests from IETF 83 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:19:45 -0000 MMUSIC will meet for 2.5 hours at IETF 83 in Paris. If you want to request a time slot to discuss a draft, please send an e-mail to Flemming and myself. As usually, we want to remind you that we should smartly use our meeting time. In principle, the meeting time should be use to discuss open issues. We give priority to drafts that gather attention and discussion in the mailing list prior to the meeting. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu Feb 23 23:20:40 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BB321E8026 for ; Thu, 23 Feb 2012 23:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.729 X-Spam-Level: X-Spam-Status: No, score=-6.729 tagged_above=-999 required=5 tests=[AWL=-3.425, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjl5o-mLhhiF for ; Thu, 23 Feb 2012 23:20:39 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B005821E8023 for ; Thu, 23 Feb 2012 23:20:38 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-df-4f473a45e265 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 32.AF.27041.54A374F4; Fri, 24 Feb 2012 08:20:37 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012 08:20:37 +0100 Message-ID: <4F473A44.6070604@ericsson.com> Date: Fri, 24 Feb 2012 08:20:36 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "zhou.sujing@zte.com.cn" References: In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] =?gb2312?b?tPC4tDogUmU6ICBXaWxsIE1NVVNJQyBoYXZlIGEgdGlt?= =?gb2312?b?ZSBzbG90IGF0IElFVEYgODM/?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:20:40 -0000 I just sent an announcement in a separate mail to the list: Please send an e-mail to the chairs. /Miguel On 24/02/2012 8:16, zhou.sujing@zte.com.cn wrote: > > Then how can I apply for a presentation£¿ > Regards~~~ > > -Sujing Zhou > > "Miguel A. Garcia" дÓÚ 2012-02-24 14:48:59: > > > Yes, MMUSIC has been allocated a timeslot on Monday from 0900 until 1130. > > We just got this information. > > > > https://datatracker.ietf.org/meeting/83/agenda.html > > > > /Miguel > > > > On 24/02/2012 1:21, zhou.sujing@zte.com.cn wrote: > > > > > > Regards~~~ > > > > > > -Sujing Zhou > > > > -- > > Miguel A. Garcia > > +34-91-339-3608 > > Ericsson Spain > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Fri Feb 24 00:07:04 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797B821E8039 for ; Fri, 24 Feb 2012 00:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.293 X-Spam-Level: X-Spam-Status: No, score=-10.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O2BIuoKamOn for ; Fri, 24 Feb 2012 00:07:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA5021E801E for ; Fri, 24 Feb 2012 00:06:58 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-f4-4f474521fbde Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.77.27041.125474F4; Fri, 24 Feb 2012 09:06:57 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012 09:06:57 +0100 Message-ID: <4F474520.50302@ericsson.com> Date: Fri, 24 Feb 2012 09:06:56 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <4F4732DB.6000505@ericsson.com> In-Reply-To: <4F4732DB.6000505@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Will MMUSIC have a time slot at IETF 83? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:07:04 -0000 Just to clarify that the IETF agenda is still in preliminary state. Even we are allocated a 2.5 hour time slot on Monday, this could change as time approaches. /Miguel On 24/02/2012 7:48, Miguel A. Garcia wrote: > Yes, MMUSIC has been allocated a timeslot on Monday from 0900 until 1130. > We just got this information. > > https://datatracker.ietf.org/meeting/83/agenda.html > > /Miguel > > On 24/02/2012 1:21, zhou.sujing@zte.com.cn wrote: >> >> Regards~~~ >> >> -Sujing Zhou > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From xavier.marjou@gmail.com Fri Feb 24 06:46:30 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79021F842C; Fri, 24 Feb 2012 06:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tjxZGXuIGPV; Fri, 24 Feb 2012 06:46:29 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2916521F8429; Fri, 24 Feb 2012 06:46:29 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3396346obb.31 for ; Fri, 24 Feb 2012 06:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=Z0zAvedrRPL1QmFm9KJXcKQyDsDMpSCzkru69Pbu6PM=; b=tKKWIuQL+b4hKrVHwpL60Y+mahmQzWj/VXhjPmWzPGz1vtApu/twbed8XUTwuHNwiF RzEGiKN+ZUhUIKDK3MyKPbIEKEnbXQyoFzEsfXs9lCHiXYgneyw3h4qlGPmPd6ByTID2 qCegJOupTdyTbIO9l5OliPVglSocfC4WEQuhU= MIME-Version: 1.0 Received: by 10.60.28.168 with SMTP id c8mr805242oeh.35.1330094788697; Fri, 24 Feb 2012 06:46:28 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.60.2.70 with HTTP; Fri, 24 Feb 2012 06:46:28 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 24 Feb 2012 15:46:28 +0100 X-Google-Sender-Auth: KOY1rSE5q5_4ZzDc59XY1yPP6ec Message-ID: From: Xavier Marjou To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8ff1c4e865e01504b9b6d3d4 Cc: rtcweb@ietf.org, IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:46:30 -0000 --e89a8ff1c4e865e01504b9b6d3d4 Content-Type: text/plain; charset=ISO-8859-1 A minor remark regarding the examples : ports 10000 and 20000 may already be busy. http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt Cheers, Xavier On Fri, Feb 24, 2012 at 8:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > FYI, > > A milestone for BUNDLE has been created in MMUSIC, and the first > draft-ietf version of the draft has been submitted. > > Regards, > > Christer > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: 24. helmikuuta 2012 9:02 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiparty Multimedia Session > Control Working Group of the IETF. > > Title : Multiplexing Negotiation Using Session > Description Protocol (SDP) Port Numbers > Author(s) : Christer Holmberg > Harald Tveit Alvestrand > Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > Pages : 11 > Date : 2012-02-23 > > This specification defines a new SDP Grouping Framework SDP grouping > framework extension, "BUNDLE", that can be used with the Session > Description Protocol (SDP) Offer/Answer mechanism to negotiate the > usage of bundled media, which refers to the usage of a single 5-tuple > for media associated with multiple SDP media descriptions ("m=" > lines). > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8ff1c4e865e01504b9b6d3d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A minor remark regarding the examples : ports 10000 and 20000 may already b= e busy.
http://www.iana.org= /assignments/service-names-port-numbers/service-names-port-numbers.txt<= br>
Cheers,
Xavier

On Fri, Feb 24, 201= 2 at 8:09 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:

FYI,

A milestone for BUNDLE has been created in MMUSIC, and the first draft-ietf= version of the draft has been submitted.

Regards,

Christer


-----Original Message-----
From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: 24. helmikuuta 2012 9:02
To: i-d-announce= @ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.t= xt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Multiplexing Negotiation Using = Session Description Protocol (SDP) Port Numbers
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Christer Holmberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald Tveit Alvestrand=
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mmusic-sdp-bundle-nego= tiation-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-23

=A0 This specification defines a new SDP Grouping Framework SDP grouping =A0 framework extension, "BUNDLE", that can be used with the Ses= sion
=A0 Description Protocol (SDP) Offer/Answer mechanism to negotiate the
=A0 usage of bundled media, which refers to the usage of a single 5-tuple<= br> =A0 for media associated with multiple SDP media descriptions ("m=3D&= quot;
=A0 lines).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/= draft-ietf-mmusic-sdp-bundle-negotiation-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/dr= aft-ietf-mmusic-sdp-bundle-negotiation-00.txt

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

--e89a8ff1c4e865e01504b9b6d3d4-- From alan.b.johnston@gmail.com Fri Feb 24 08:01:52 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473CD21F87B0; Fri, 24 Feb 2012 08:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGl75foZ844r; Fri, 24 Feb 2012 08:01:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D11E21F87AF; Fri, 24 Feb 2012 08:01:51 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3485806obb.31 for ; Fri, 24 Feb 2012 08:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Os8VMX+NbJ12rZwTD/eXl/199RMSLy7zOnXimyeNJos=; b=x1TjMpQh7n2jsJIU9VTBhsfDMvGssMfwwsaKCovRg2/BoEcGQ8FUZWmHVZ7PwSY0RY MU/ctTjMnH3Z5EG3mYZ4oX7KPwZj3xpf8kX5lRyOgTo+P+fbN6ZEHfsX/cEnlwXDMJQd QDdIleJIQMlhvWkj6eEAVf6gVU94k2E60kj0w= MIME-Version: 1.0 Received: by 10.182.72.69 with SMTP id b5mr883461obv.77.1330099311103; Fri, 24 Feb 2012 08:01:51 -0800 (PST) Received: by 10.182.39.161 with HTTP; Fri, 24 Feb 2012 08:01:51 -0800 (PST) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 24 Feb 2012 10:01:51 -0600 Message-ID: From: Alan Johnston To: Xavier Marjou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org, IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:01:52 -0000 Also, there is no reference to RFC 5761 or use of a=3Drtcp-mux in the example. In Section 6.1 there is a typo 'rtpc-mux' - Alan - On Fri, Feb 24, 2012 at 8:46 AM, Xavier Marjou w= rote: > A minor remark regarding the examples : ports 10000 and 20000 may already= be > busy. > http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.txt > > Cheers, > Xavier > > On Fri, Feb 24, 2012 at 8:09 AM, Christer Holmberg > wrote: >> >> >> FYI, >> >> A milestone for BUNDLE has been created in MMUSIC, and the first >> draft-ietf version of the draft has been submitted. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: 24. helmikuuta 2012 9:02 >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiparty Multimedia Sess= ion >> Control Working Group of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Multiplexing Negotiation Usin= g Session >> Description Protocol (SDP) Port Numbers >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Christer Holmberg >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald Tveit Alvestra= nd >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mmusic-sdp-bundle-ne= gotiation-00.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-23 >> >> =A0 This specification defines a new SDP Grouping Framework SDP grouping >> =A0 framework extension, "BUNDLE", that can be used with the Session >> =A0 Description Protocol (SDP) Offer/Answer mechanism to negotiate the >> =A0 usage of bundled media, which refers to the usage of a single 5-tupl= e >> =A0 for media associated with multiple SDP media descriptions ("m=3D" >> =A0 lines). >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotia= tion-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiat= ion-00.txt >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From paulej@packetizer.com Fri Feb 24 09:58:46 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4763021F883A for ; Fri, 24 Feb 2012 09:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRP48MQvp6vV for ; Fri, 24 Feb 2012 09:58:44 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BE36C21F882F for ; Fri, 24 Feb 2012 09:58:44 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q1OHwheJ020488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 24 Feb 2012 12:58:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1330106324; bh=jP81rhjH2OrbQ/Ag5GjU9pDsIVaXwVSxWR66Mp4rjC4=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=FRwgUACSpJZ0wDv+3hlAIdEpDuXXhWNUZyqTklyTzgg0Wb/gyqqiqZn8CWnV4+Nwo jZJt1KOv1n/z6voDlvPH8LlmL3oTb5qdSWwKMuNSVokVWqqFfWpj0XqAgdBu0T4hpO +FZAAt7AE0au9kdSUugd5oToCLMmEqGJAHY6ubhU= From: "Paul E. Jones" To: Date: Fri, 24 Feb 2012 12:58:43 -0500 Message-ID: <00c901ccf31d$f3226320$d9672960$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CCF2F4.0A4D1E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczzGkwX4UIZqW/9Sm6nXb1lWvHAsQ== Content-Language: en-us Subject: [MMUSIC] Traffic Class Labels and classes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:58:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CA_01CCF2F4.0A4D1E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, We have a draft that describes Traffic Class Labels (TCL) for SDP: http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-00 The syntax for the TCL is basically: parent "." application *("." adjective) "." ("admitted" / "non-admitted") The admitted and non-admitted part on the end is an admission qualifier. I was asked a couple of questions: 1) Is there any reason to require the admission qualifier on the end? 2) What if there is no admission qualifier or if we want to introduce other values? The admission qualifier does not necessarily have to be at the end, but it is called out specifically since it is a class of adjectives for which we have defined values and we want to be able to quickly identify. It was suggested that perhaps we actually consider grouping adjectives into classes. The admission qualifier is just one class of adjectives, after all. I like the idea, since it would allow an application to quickly identify a type of adjective, even if it does not understand what the adjective value is. The class concept would use a syntax like "classname:adjective". For the admission qualifier, we might use "aq". So, an example TCL might be: Conversational.video.alpha.beta.aq:admitted.gamma I would like to hear others' opinions on use of classes to logically group adjectives. We would want to keep classless adjectives, too. So, the modified syntax would be roughly: parent "." application *("." [class] adjective) Comments? Paul ------=_NextPart_000_00CA_01CCF2F4.0A4D1E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We have a = draft that describes Traffic Class Labels (TCL) for = SDP:

http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-= 00

 

The syntax for the TCL is basically:

 

  parent = “.” application *(“.” adjective) “.” = (“admitted” / = “non-admitted”)

 

The admitted = and non-admitted part on the end is an admission qualifier.  I was = asked a couple of questions:

1)      = Is there any reason to require the admission = qualifier on the end?

2)      = What if there is no admission qualifier or if we = want to introduce other values?

 

The = admission qualifier does not necessarily have to be at the end, but it = is called out specifically since it is a class of adjectives for which = we have defined values and we want to be able to quickly = identify.

 

It was suggested that perhaps we actually consider = grouping adjectives into classes.  The admission qualifier is just = one class of adjectives, after all.  I like the idea, since it = would allow an application to quickly identify a type of adjective, even = if it does not understand what the adjective value is.

 

The class = concept would use a syntax like “classname:adjective”.  = For the admission qualifier, we might use “aq”.  So, an = example TCL might be:

 

   = Conversational.video.alpha.beta.aq:admitted.gamma

 

I would like = to hear others’ opinions on use of classes to logically group = adjectives.

 

We would want to keep classless adjectives, too.  = So, the modified syntax would be roughly:

 

  = parent “.” application *(“.” [class] = adjective)

 

Comments?

 

Paul

 

------=_NextPart_000_00CA_01CCF2F4.0A4D1E70-- From pkyzivat@alum.mit.edu Fri Feb 24 12:15:31 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A16E21F8806 for ; Fri, 24 Feb 2012 12:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gISpf0g0cXiV for ; Fri, 24 Feb 2012 12:15:30 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8B821F8790 for ; Fri, 24 Feb 2012 12:15:27 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id duog1i0091c6gX85DwFTRU; Fri, 24 Feb 2012 20:15:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id dwFT1i00Q07duvL3jwFTd5; Fri, 24 Feb 2012 20:15:27 +0000 Message-ID: <4F47EFDE.3090107@alum.mit.edu> Date: Fri, 24 Feb 2012 15:15:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <00c901ccf31d$f3226320$d9672960$@packetizer.com> In-Reply-To: <00c901ccf31d$f3226320$d9672960$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Some comments on draft-ietf-mmusic-traffic-class-for-sdp-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 20:15:31 -0000 I just got around to taking a look at this draft. I noted the following while reading it: - is this only for RTP? I presume not. Presumably it includes all sorts of traffic. So why don't I find anything for much common traffic, such as browsing and file transfer, backup, ...? Of course many of those are not typically described in SDP, which might explain it. What traffic class would you recommend for a SIMPLE session to be used for a file transfer? - it sounds like there may be a variety of places where these traffic class labels might be used. I think it would be wise to separate the definition of the labels themselves from any particular use, such as in SDP. (One RFC for the definition of syntax of the traffic class label itself, and the IANA registration of the initial values. A different RFC for the SDP trafficclass attribute. - The "Multiplex" application seems to be sweeping a major issue under the rug. There are now a lot of plans to multiplex many RTP streams on a single RTP session. (Sorry if I have that terminology wrong.) This is showing up in at least RTCWEB and CLUE. This is likely to evolve into a lot of traffic. Its likely that there will need to be a way to describe traffic class at a finer granularity than a port. - the parent, application, and adjective definitions seem to be very subjective. Its far from clear that two people would choose the same ones to describe a particular class of traffic. - the cac-class is hacked into the syntax. It might be better if it were distinguished more clearly - perhaps using a distinctive syntax. (And I see that Paul J is proposing something for that.) - the restriction to one traffic class per m-line seems problematic for rtp sessions that are multiplexed. This could be addressed by allowing traffic classes to be specified per SSRC. (An alternative is to use the proposed Bundle mechanism to allow more than one m-line for the same port. But its not clear if that is sufficient.) - another issue about making this per-m-line is: what about the traffic class of the RTCP session? Is there a need to describe it too? - it seems highly likely that additional app-types and app-params will eventually be defined. This will probably require use of IANA registries. Assuming that, I suggest it would be advisable to take the initial set of names out of the ABNF and instead put them into IANA registration templates. - non-standard adjectives require careful thought, because they can cause interop problems. What is to prevent two unrelated organizations from using the same non-standard adjective to mean two different things. An alternative would be an IANA registry with a low bar for additions. - I don't understand why the cac-class must be last. Seems very arbitrary. - section 4.1 Offer Behavior Offerers of this 'trafficclass' attribute MUST NOT change the label in transit (e.g., wrt to B2BUAs). SBCs at domain boundaries can change this attribute through local policy. This is unclear. Can you try again? Which things cannot change the label? ISTM that anything that terminates the media and then reoriginates it should be able to change the value. - section 4.2 I'm not at all sure of this, but I *think* this is telling me that the traffic class in the offer/answer describes the characteristics of the data the offerer/answerer will *receive*. This means that neither side has a way to describe the characteristics of the traffic it plans to send. Is that sufficient? Thanks, Paul From pkyzivat@alum.mit.edu Fri Feb 24 12:35:36 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241D021F86DC for ; Fri, 24 Feb 2012 12:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dw3jnc+ZDn8 for ; Fri, 24 Feb 2012 12:35:34 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2C70621F86DB for ; Fri, 24 Feb 2012 12:35:34 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id duur1i00227AodY57wbamU; Fri, 24 Feb 2012 20:35:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id dwba1i00E07duvL3fwbadf; Fri, 24 Feb 2012 20:35:34 +0000 Message-ID: <4F47F494.7090406@alum.mit.edu> Date: Fri, 24 Feb 2012 15:35:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <00c901ccf31d$f3226320$d9672960$@packetizer.com> In-Reply-To: <00c901ccf31d$f3226320$d9672960$@packetizer.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] Traffic Class Labels and classes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 20:35:36 -0000 On 2/24/12 12:58 PM, Paul E. Jones wrote: > Folks, > > We have a draft that describes Traffic Class Labels (TCL) for SDP: I just posted some comments on the draft. > http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-00 > > The syntax for the TCL is basically: > > parent “.” application *(“.” adjective) “.” (“admitted” / “non-admitted”) > > The admitted and non-admitted part on the end is an admission qualifier. > I was asked a couple of questions: > > 1)Is there any reason to require the admission qualifier on the end? > > 2)What if there is no admission qualifier or if we want to introduce > other values? > > The admission qualifier does not necessarily have to be at the end, but > it is called out specifically since it is a class of adjectives for > which we have defined values and we want to be able to quickly identify. Its far from evident that putting it at the end makes it quicker to identify. If it is really different from an adjective, then it might be helpful to syntactically distinguish it. Putting it at the end is one way. What you suggest below is another. We can find others. But first we should figure out if it really is different from an adjective, or if it is simply an adjective that is of more general interest than most. One difference might be how its registered. Apparently the admission qualifiers apply to all parents and applications, while maybe (I'm not certain) adjectives need to be registered separately for each parent+application combination they are valid with. > It was suggested that perhaps we actually consider grouping adjectives > into classes. The admission qualifier is just one class of adjectives, > after all. I like the idea, since it would allow an application to > quickly identify a type of adjective, even if it does not understand > what the adjective value is. This seems interesting. But only if the significance of a class can be nailed down. Perhaps my musing above relates to this: If adjectives are gathered into classes, then maybe the registration of an application could specify the classes that are relevant to it, rather than the specific adjectives. All adjectives from any of the allowed classes would then be permitted. > The class concept would use a syntax like “classname:adjective”. For the > admission qualifier, we might use “aq”. So, an example TCL might be: > > Conversational.video.alpha.beta.aq:admitted.gamma > > I would like to hear others’ opinions on use of classes to logically > group adjectives. Is it necessary to actually code the adjective class in the name? It is if the same adjective names can be used with differing meanings in different classes. But if you require all adjective names to be unique regardless of class, then you don't need to encode the class name. The class concept might also be a way to deal with non-registered adjectives. > We would want to keep classless adjectives, too. So, the modified syntax > would be roughly: > > parent “.” application *(“.” [class] adjective) Maybe rather than classless adjectives, how about a default class. That way all adjectives would have some class, which would be useful in IANA registration templates, documentation, etc. Thanks, Paul From Bert.Greevenbosch@huawei.com Fri Feb 24 16:33:03 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDA21E8013 for ; Fri, 24 Feb 2012 16:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H0naFI+9avq for ; Fri, 24 Feb 2012 16:32:59 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2A21F860B for ; Fri, 24 Feb 2012 16:32:58 -0800 (PST) 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 <0LZX005F4AUP4R@szxga05-in.huawei.com> for mmusic@ietf.org; Sat, 25 Feb 2012 08:32:49 +0800 (CST) Received: from szxrg01-dlp.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 <0LZX003LHAUOA4@szxga05-in.huawei.com> for mmusic@ietf.org; Sat, 25 Feb 2012 08:32:48 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHB02450; Sat, 25 Feb 2012 08:32:47 +0800 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 25 Feb 2012 08:32:24 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.83]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Sat, 25 Feb 2012 08:32:43 +0800 Date: Sat, 25 Feb 2012 00:32:40 +0000 From: Bert Greevenbosch In-reply-to: <000001cce7f0$1e5e5e10$5b1b1a30$@dit.upm.es> X-Originating-IP: [10.70.109.135] To: Pedro Capelastegui , 'IETF - MMUSIC' Message-id: <46A1DF3F04371240B504290A071B4DB6232C3ADA@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BbKVpwod+Lqz6AqxfdDNkg)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] The 3D drafts Thread-index: AczkZrAV0ElkOsHfT6KQFeCWDlQX8QDRl6uAAunRykA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> <000001cce7f0$1e5e5e10$5b1b1a30$@dit.upm.es> Subject: Re: [MMUSIC] The 3D drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:33:03 -0000 --Boundary_(ID_BbKVpwod+Lqz6AqxfdDNkg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Pedro, As promised, here the answer to your second e-mail. The current simulcast solution in the draft indeed assumes a single codec, = which internally contains both a 2D and an auxiliary stream. But my understanding is that your main concern is the simulcast of two stre= ams (2D and aux), with different codecs. Your proposed solution would indee= d resolve that problem. Now that we have the discussions on RTP multiplexing, especially the "BUNDL= E" draft (http://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-= negotiation), I was wondering whether we could somehow use that mechanism t= o resolve the problem. In that case, your original example m=3Dvideo 49170 RTP/AVP 99 100 a=3D3dFormat:2DA CD a=3Drtpmap:99 H264/90000 a=3D3daux: 99 H263/90000 aux-fmtp:(...) a=3Drtpmap:100 H264/90000 a=3D3daux: 100 H264/90000 aux-fmtp:(...) would become as follows: a=3Dgroup:3DS 1 2 a=3Dgroup:BUNDLE 1 2 m=3Dvideo 49170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:SC C a=3Dmid:1 m=3Dvideo 49170 RTP/AVP 100 a=3Drtpmap:100 H263/90000 a=3D3dFormat:SC D a=3Dmid:2 a=3Dgroup:3DS 3 4 a=3Dgroup:BUNDLE 3 4 m=3Dvideo 49170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:SC C a=3Dmid:3 m=3Dvideo 49170 RTP/AVP 100 a=3Drtpmap:100 H264/90000 a=3D3dFormat:SC D a=3Dmid:4 This means, that we use the separate streams mechanism + the "BUNDLE" mecha= nism to achieve our goal. It this is maybe a bit premature, as the "BUNDLE"= draft is only a personal draft, but it seems to work and we would not need= an extra mechanism in the 3D format draft. Admittedly, this solution also looks complex, especially because of the dou= ble grouping mechanism. However, it would not require to define a new "3dau= x" attribute and "aux-fmtp" semantics. What do you think? Best regards, Bert From: Pedro Capelastegui [mailto:capelastegui@dit.upm.es] Sent: 10 February 2012 20:33 To: Bert Greevenbosch; 'IETF - MMUSIC' Subject: RE: [MMUSIC] The 3D drafts Hi Bert, After taking another look at the "3d format" draft, I have found a few addi= tional issues. They are summarized below: 1) Encoding of auxiliary stream: In the "video plus auxiliary stream" = schemes using a single stream (i.e. "LD", "LP", "CD", and "CP"), no encod= ing information is provided for the auxiliary stream. 2) Ambiguous negotiation for scenarios with multiple 3D streams: There= is no clear way for an offerer to indicate when multiple 3D streams (e.g. = to show in multiple displays) are offered, as opposed to a single 3D stream= with several possible configurations. 3) Support for H264/MVC streams: The H264/MVC codec is very well suite= d for 3d video applications. It uses some encoding formats that are not sup= ported by the current draft but could be added without much effort. I'll cover each topic in a separate mail. Here is some discussion on point = 1), auxiliary stream encoding. Auxiliary video streams such as depth maps or parallax can be encoded, just= like any other video stream. In the "Signal 3d format" draft, the encoding= for these streams can be described and negotiated normally when they are t= ransmitted as separate RTP streams. However, this is no longer true when de= pth or parallax maps are encapsulated with a regular view as a single RTP s= tream, as defined in ISO 23002-3. This corresponds to the formats "2DA CD",= "2DA CP" , "2DA LD" and "2DA LP" in the draft. It could be assumed that, since no encoding information is provided for the= se streams, they can use the same encoding used for the video view they are= encapsulated with. As an example, consider the following stream: m=3Dvideo 49170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:2DA CD The above lines describe a video stream representing a central view, with a= depth map included in the same RTP stream as auxiliary data. The central v= iew is encoded in H264, but the depth map encoding is undefined. We could s= olve this by stating in the draft that, when no encoding is specified for a= n auxiliary stream, it uses the same configuration as the same view. Thus, = the depth map in the example would also use H264. I think this works well as a default assumption. However, it does not cover= all possible scenarios, as the auxiliary stream CAN use a different format= than the base view. In fact, that will likely be the best performing confi= guration, since depth maps have different properties than regular video str= eams, and codecs like H264 don't perform particularly well with them. To address this, we would need a way to express the media format for auxili= ary streams. At the very least, this would involve including the informatio= n normally expressed in "a=3Drtpmap" and "a=3Dfmtp" attributes. One possible way to do this would be to add the values of these attributes = (for the auxiliary map) as optional parameters in the "a=3D3dformat" attrib= ute. In the previous example, this could look as follows: m=3Dvideo 49170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:2DA CD aux-map:H264/90000 aux-fmtp:(...) A limitation of this approach is that it just describes a single encoding f= or the auxiliary map. Ideally, a solution should allow the offerer to sugge= st multiple configurations from which the answerer can choose one, as with = any media stream in the offer/answer model. For this, we could define a new= attribute, like "a=3D3daux", and include in it a payload type number, the = value of "a=3Drtpmap" for the auxiliary stream, and the value of "a=3Dfmtp"= for that stream. It could look as follows: m=3Dvideo 49170 RTP/AVP 99 100 a=3D3dFormat:2DA CD a=3Drtpmap:99 H264/90000 a=3D3daux: 99 H263/90000 aux-fmtp:(...) a=3Drtpmap:100 H264/90000 a=3D3daux: 100 H264/90000 aux-fmtp:(...) In this example, the offerer is providing two possible configurations: - PT 99: Central view encoded in H.264, depth map encoded in H.26= 3 - PT 100: Central view and depth map encoded in H.264 In addition, there may be other SDP fields or attributes that have to be ta= ken into account while signalling these auxiliary streams. Best regards, Pedro From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Bert Greevenbosch Sent: Monday, February 06, 2012 1:32 AM To: IETF - MMUSIC Subject: [MMUSIC] The 3D drafts Hi all, I was wondering, if everybody is happy with the current versions of the 3D = drafts, or are there still open issues? I look forward to your comments. Best regards, Bert http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ ________________________________ No se encontraron virus en este mensaje. Comprobado por AVG - www.avg.com Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de publica= ci=F3n: 02/05/12 --Boundary_(ID_BbKVpwod+Lqz6AqxfdDNkg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Pedro,

 

As promised, here the answer to your second e-mail.<= o:p>

 

The current simulcast solution in the draft indeed a= ssumes a single codec, which internally contains both a 2D and an auxiliary= stream.

 

But my understanding is that your main concern is th= e simulcast of two streams (2D and aux), with different codecs. Your propos= ed solution would indeed resolve that problem.

 

Now that we have the discussions on RTP multiplexing= , especially the "BUNDLE" draft (http://datatracker.ietf.org/doc/= draft-holmberg-mmusic-sdp-bundle-negotiation), I was wondering whether we c= ould somehow use that mechanism to resolve the problem. In that case, your original example

 

     &nbs= p;       m=3Dvideo 49170 RTP/AVP 99 100<= /o:p>

     &nbs= p;       a=3D3dFormat:2DA CD

        &nbs= p;    a=3Drtpmap:99 H264/90000

        &nbs= p;    a=3D3daux: 99 H263/90000 aux-fmtp:(…)=

        &nbs= p;    a=3Drtpmap:100 H264/90000

        &nbs= p;    a=3D3daux: 100 H264/90000 aux-fmtp:(…)

 

would become as follows:

 

        &nbs= p;    a=3Dgroup:3DS 1 2

        &nbs= p;    a=3Dgroup:BUNDLE 1 2

        &nbs= p;    m=3Dvideo 49170 RTP/AVP 99

        &nbs= p;    a=3Drtpmap:99 H264/90000

        &nbs= p;    a=3D3dFormat:SC C

        &nbs= p;    a=3Dmid:1

        &nbs= p;    m=3Dvideo 49170 RTP/AVP 100

        &nbs= p;    a=3Drtpmap:100 H263/90000

        &nbs= p;    a=3D3dFormat:SC D

        &nbs= p;    a=3Dmid:2

        &nbs= p;    a=3Dgroup:3DS 3 4

        &nbs= p;    a=3Dgroup:BUNDLE 3 4

        &nbs= p;    m=3Dvideo 49170 RTP/AVP 99

        &nbs= p;    a=3Drtpmap:99 H264/90000

        &nbs= p;    a=3D3dFormat:SC C

        &nbs= p;    a=3Dmid:3

        &nbs= p;    m=3Dvideo 49170 RTP/AVP 100

        &nbs= p;    a=3Drtpmap:100 H264/90000

        &nbs= p;    a=3D3dFormat:SC D

        &nbs= p;    a=3Dmid:4

 

This means, that we use the separate streams mechani= sm + the "BUNDLE" mechanism to achieve our goal. It this is m= aybe a bit premature, as the "BUNDLE" draft is only a personal dr= aft, but it seems to work and we would not need an extra mechanism in the 3D format draft.

 

Admittedly, this solution also looks complex, especi= ally because of the double grouping mechanism. However, it would not requir= e to define a new "3daux" attribute and "aux-fmtp" sema= ntics.

 

What do you think?

 

Best regards,

Bert

 

 

From: Pedro Capelastegui = [mailto:capelastegui@dit.upm.es]
Sent: 10 February 2012 20:33
To: Bert Greevenbosch; 'IETF - MMUSIC'
Subject: RE: [MMUSIC] The 3D drafts

 

Hi Bert,

 

After taking another look at the “3d format= 221; draft, I have found a few additional issues. They are summarized below= :

 

1)      Encoding of auxiliary stream: In the “video p= lus auxiliary stream” schemes using a single stream (i.e. “LD&#= 8221;, “LP”,  “CD”, and  “CP”= ), no encoding information is provided for the auxiliary stream.

2)      Ambiguous negotiation for scenarios with multiple 3= D streams: There is no clear way for an offerer to indicate when multiple 3= D streams (e.g. to show in multiple displays) are offered, as opposed to a = single 3D stream with several possible configurations.

3)      Support for H264/MVC streams: The H264/MVC codec is= very well suited for 3d video applications. It uses some encoding formats = that are not supported by the current draft but could be added without much= effort.

I’ll cover each topic in a separate mail. Here= is some discussion on point 1), auxiliary stream encoding.

 

Auxiliary video streams such as depth maps or parall= ax can be encoded, just like any other video stream. In the “Signal 3= d format” draft, the encoding for these streams can be described and = negotiated normally when they are transmitted as separate RTP streams. However, this is no longer true when depth or par= allax maps are encapsulated with a regular view as a single RTP stream, as = defined in ISO 23002-3. This corresponds to the formats “2DA CD”= ;, “2DA CP” , “2DA LD” and “2DA LP” in = the draft.

 

It could be assumed that, since no encoding informat= ion is provided for these streams, they can use the same encoding used for = the video view they are encapsulated with. As an example, consider the foll= owing stream:

 

m=3Dvideo 49170 RTP/AVP= 99

a=3Drtpmap:99 H264/9000= 0

a=3D3dFormat:2DA CD

 

The above lines describe a video stream representing= a central view, with a depth map included in the same RTP stream as auxili= ary data. The central view is encoded in H264, but the depth map encoding i= s undefined. We could solve this by stating in the draft that, when no encoding is specified for an auxiliary = stream, it uses the same configuration as the same view. Thus, the depth ma= p in the example would also use H264.

 

I think this works well as a default assumption. How= ever, it does not cover all possible scenarios, as the auxiliary stream CAN= use a different format than the base view. In fact, that will likely be th= e best performing configuration, since depth maps have different properties than regular video streams, and codec= s like H264 don’t perform particularly well with them.

 

To address this, we would need a way to express the = media format for auxiliary streams. At the very least, this would involve i= ncluding the information normally expressed in “a=3Drtpmap” and= “a=3Dfmtp” attributes.

 

One possible way to do this would be to add the valu= es of these attributes (for the auxiliary map) as optional parameters in th= e “a=3D3dformat” attribute. In the previous example, this could= look as follows:

 

m=3Dvideo 49170 RTP/AVP= 99

a=3Drtpmap:99 H264/9000= 0

a=3D3dFormat:2DA CD aux= -map:H264/90000 aux-fmtp:(…)

 

A limitation of this approach is that it just descri= bes a single encoding for the auxiliary map. Ideally, a solution should all= ow the offerer to suggest multiple configurations from which the answerer c= an choose one, as with any media stream in the offer/answer model. For this, we could define a new attribute, like= “a=3D3daux”, and include in it a payload type number, the valu= e of “a=3Drtpmap” for the auxiliary stream, and the value of &#= 8220;a=3Dfmtp” for that stream. It could look as follows:<= /p>

 

m=3Dvideo 49170 RTP/AVP= 99 100

a=3D3dFormat:2DA CD

a=3Drtpmap:99 H264/9000= 0

a=3D3daux: 99 H263/9000= 0 aux-fmtp:(…)

a=3Drtpmap:100 H264/900= 00

a=3D3daux: 100 H264/900= 00 aux-fmtp:(…)

 

In this example, the offerer is providing two possib= le configurations:

 

-       = ;   PT 99:  Central view encoded in H.264, depth m= ap encoded in H.263

-       = ;   PT 100: Central view and depth map encoded in H.264=

 

In addition, there may be other SDP fields or attrib= utes that have to be taken into account while signalling these auxiliary st= reams.

 

Best regards,

Pedro

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bert Greevenbosch
Sent: Monday, February 06, 2012 1:32 AM
To: IETF - MMUSIC
Subject: [MMUSIC] The 3D drafts

 

Hi all,

 

I was wondering, if everybody is happy with the curr= ent versions of the 3D drafts, or are there still open issues?

I look forward to your comments.

 

Best regards,

Bert

 

http://datatracker.ietf.org/doc/draft-ietf-mm= usic-parallax-attribute/

http://datatracker.ietf.org/doc/draft-ietf-mmus= ic-signal-3d-format/

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versi=F3n: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de publica= ci=F3n: 02/05/12

--Boundary_(ID_BbKVpwod+Lqz6AqxfdDNkg)-- From jmpolk@cisco.com Sat Feb 25 14:31:48 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8529221F85DD for ; Sat, 25 Feb 2012 14:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.33 X-Spam-Level: X-Spam-Status: No, score=-109.33 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOTksEXk3CYf for ; Sat, 25 Feb 2012 14:31:48 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F28CA21F85C3 for ; Sat, 25 Feb 2012 14:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=609; q=dns/txt; s=iport; t=1330209107; x=1331418707; h=message-id:date:to:from:subject:cc:mime-version; bh=VR3+A5z8lrwU9NMAhy8COcMPMCVOEiNxSjRQYbSniqo=; b=d3TFktnp2pC5wRh+IQt0Zc2Muyh5j0ttqTOGdKAyfI7flZRIPSnfYDr9 U+O/C8e3Wh7EYCYMe+fAoWlng+0kl1iq1nTaTuJPCgwMy4XP08jRupxx/ PLBurWVw1fcRYm/lj0MoZM3iiK3Nd8Jt9mcdhTuHa6eoC3LVOOKqo7c+r Q=; X-IronPort-AV: E=Sophos;i="4.73,482,1325462400"; d="scan'208";a="32536465" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 25 Feb 2012 22:31:46 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1PMVjVB000320; Sat, 25 Feb 2012 22:31:45 GMT Message-Id: <201202252231.q1PMVjVB000320@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 25 Feb 2012 16:31:44 -0600 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Subha Dhesikan \(sdhesika\)" Subject: [MMUSIC] Change to trafficclass attribute for -01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 22:31:48 -0000 We have received some feedback that seems to make sense, that the adjective 'desktop', when used to describe a desktop audio/video call is antiquated - given how mobile we're becoming. Therefore I propose we change this adjective to 'avconf' (for audio/video conference), or alternatively to 'mmconf' (for multimedia conference) in the next version of the draft. Either seem more appropriate given the use of laptops, tablets and smart mobile phones we use that are not tethered like a desktop computer generally is thought of being. Please let me know your thoughts. James/Paul/Subha From jmpolk@cisco.com Sat Feb 25 14:40:37 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F1621F85C3 for ; Sat, 25 Feb 2012 14:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.405 X-Spam-Level: X-Spam-Status: No, score=-109.405 tagged_above=-999 required=5 tests=[AWL=1.194, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dltGosYpqXL0 for ; Sat, 25 Feb 2012 14:40:37 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA4221F8548 for ; Sat, 25 Feb 2012 14:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=952; q=dns/txt; s=iport; t=1330209637; x=1331419237; h=message-id:date:to:from:subject:mime-version; bh=ENk3yL+3nrcDohGkl01OS+LwrpTBtLFOHfQmMxNqV/s=; b=lysOd/rFzNgzwy/7XuKBmyospUEOGv5wmBNV56spms4n8fQsp+XJ8bwS 6cLmZsQY5Q/Ml+1Ep5g36iPstqK4SCVpI8zfzFXkJxDl11qn9gQejxlFM fpMiv2FVvKY4d/IvPlXI9+HyB3LeDZsxxJuXPNkYW/+HExX3w8XZVqkUu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAGliSU+rRDoJ/2dsb2JhbABDsymBB4IMASUCVjopeYdjn02BJwGWD40ODgoBCQEGAhADAwIKAg0JAwoYAwMDAoUNA3qDHgSIT597 X-IronPort-AV: E=Sophos;i="4.73,483,1325462400"; d="scan'208";a="32537703" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Feb 2012 22:40:37 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1PMear1009221 for ; Sat, 25 Feb 2012 22:40:36 GMT Message-Id: <201202252240.q1PMear1009221@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 25 Feb 2012 16:40:36 -0600 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Another change to trafficclass for -01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 22:40:37 -0000 We've also received some feedback about the general confusion around the term 'multimedia conferencing' as a patent class or category. The meaning we're after in the -01 version of the draft is not audio and not human video, but presentation data, application sharing or collaboration associated with conversational audio and/or conversational video. Think of a web conferencing or telepresence application in which folks talk, folks can see each other, and there is either a common presentation (generally) from one person's computer or folks are sharing an application and editing the common application during the call. 'Multimedia Conferencing' as a term has some baggage from RFC 4594, and we'd like to change this parent class or category for these types of usages to 'Collaboration', which is a bit more appropriate with what the usage is. Please let us know your thoughts about this change. James/Paul/Subha From christer.holmberg@ericsson.com Sun Feb 26 00:00:42 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C821F8643; Sun, 26 Feb 2012 00:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.137 X-Spam-Level: X-Spam-Status: No, score=-10.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGdY+ULoB1ZU; Sun, 26 Feb 2012 00:00:40 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAC21F863F; Sun, 26 Feb 2012 00:00:40 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-1a-4f49e6a6ff35 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AB.9C.27041.6A6E94F4; Sun, 26 Feb 2012 09:00:38 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 26 Feb 2012 09:00:37 +0100 From: Christer Holmberg To: Alan Johnston , Xavier Marjou Date: Sun, 26 Feb 2012 08:59:15 +0100 Thread-Topic: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: AczzDZ9hCZQ11KUKROiPIv27tYrUTABTulFP Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5DC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CC@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== Cc: "rtcweb@ietf.org" , IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 08:00:42 -0000 Hi Alan and Xavier, Thanks for your comments! Regards, Christer ________________________________________ From: Alan Johnston [alan.b.johnston@gmail.com] Sent: Friday, February 24, 2012 6:01 PM To: Xavier Marjou Cc: Christer Holmberg; rtcweb@ietf.org; IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] FW: I-D Action: draft-ietf-mmusic-sdp-bundle= -negotiation-00.txt Also, there is no reference to RFC 5761 or use of a=3Drtcp-mux in the example. In Section 6.1 there is a typo 'rtpc-mux' - Alan - On Fri, Feb 24, 2012 at 8:46 AM, Xavier Marjou w= rote: > A minor remark regarding the examples : ports 10000 and 20000 may already= be > busy. > http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.txt > > Cheers, > Xavier > > On Fri, Feb 24, 2012 at 8:09 AM, Christer Holmberg > wrote: >> >> >> FYI, >> >> A milestone for BUNDLE has been created in MMUSIC, and the first >> draft-ietf version of the draft has been submitted. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: 24. helmikuuta 2012 9:02 >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiparty Multimedia Sess= ion >> Control Working Group of the IETF. >> >> Title : Multiplexing Negotiation Using Session >> Description Protocol (SDP) Port Numbers >> Author(s) : Christer Holmberg >> Harald Tveit Alvestrand >> Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> Pages : 11 >> Date : 2012-02-23 >> >> This specification defines a new SDP Grouping Framework SDP grouping >> framework extension, "BUNDLE", that can be used with the Session >> Description Protocol (SDP) Offer/Answer mechanism to negotiate the >> usage of bundled media, which refers to the usage of a single 5-tuple >> for media associated with multiple SDP media descriptions ("m=3D" >> lines). >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotia= tion-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiat= ion-00.txt >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Sun Feb 26 12:52:53 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E9921F8533 for ; Sun, 26 Feb 2012 12:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.173 X-Spam-Level: X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0dpEG6-R-ch for ; Sun, 26 Feb 2012 12:52:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4CED721F852B for ; Sun, 26 Feb 2012 12:52:52 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-72-4f4a9ba31ac0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 24.59.01970.3AB9A4F4; Sun, 26 Feb 2012 21:52:51 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 26 Feb 2012 21:52:50 +0100 From: Christer Holmberg To: Gonzalo Camarillo , Mary Barnes Date: Sun, 26 Feb 2012 21:52:49 +0100 Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP Thread-Index: AczyUO0u5pQanwH4SOajV7Bj81wjMQCd4zFg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> In-Reply-To: <4F4677D3.2090406@ericsson.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: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 20:52:53 -0000 Hi, As a directorate member, I am willing to co-author such draft, should a dec= ision to write one be taken. Regards, Christer=20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Gonzalo Camarillo Sent: 23. helmikuuta 2012 19:31 To: Mary Barnes Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP I agree. Gonzalo On 23/02/2012 7:06 PM, Mary Barnes wrote: > I would think that in order for the document to have integrity that at=20 > least one of the directorate members should at least be a co-author. > Otherwise, I see a lot more stuff falling through the cracks and=20 > needing to be resolved during WGLC and later, which usually isn't a=20 > good thing. The SIP Hitchhiker's guide provides a good example in=20 > that the author was also a primary contributor to RFC3261, etc. >=20 > Mary.=20 >=20 > On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo=20 > > > wrote: >=20 > Hi Mary, >=20 > yes, the members of the SDP directorate would need to review such a > guide. However, the fact that they agreed to be members of the > directorate does not mean they will necessarily have cycles to > significantly contribute to the creation of the guide. We need to mak= e > sure we have enough energy around this effort in order to start it. >=20 > Cheers, >=20 > Gonzalo >=20 > On 15/02/2012 7:14 PM, Mary Barnes wrote: > > I think this is a good idea. I would think the experts that can > > contribute (and should review) can be found in the new SDP > > directorate: > > http://www.ietf.org/iesg/directorate/sdp.html > > BTW, it would be nice to have a link to this page on the MMUSIC WG > wiki: > > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > > > As far as whether to publish, I think it would be a good idea to > > complete publication as IMHO that improves the integrity of the > > information - i.e., more eyes review a published RFC than a draft. > > It could later be updated to reflect more recent RFCs OR a "More of > > Hitchhikers Guide" could be published. > > > > Thanks, > > Mary. > > > > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > > > wrote: > >> Hi Miguel, Andrew, all, > >> > >> Sounds like a good idea. I would be happy to volunteer to play a > central role in it (i.e. be the editor, create the initial draft, > ...), but I would need support from other experts too. > >> > >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" > has become an RFC (5411). That means that it has been frozen, and to > add new info new individual or WG drafts are needed. > >> > >> Would this be the same approach for SDP? Currently, there are > already quite some new drafts that extend SDP. How will future > extensions be handled? Maybe it would be good to make it a permanent > WG draft, which is updated every now and then. > >> > >> Best regards, > >> Bert > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org ] On > Behalf Of Miguel A. Garcia > >> Sent: 14 February 2012 15:42 > >> To: Andrew Allen > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> > >> Sounds good to me too. If someone wants to start such draft... > >> > >> /Miguel > >> > >> On 13/02/2012 23:15, Andrew Allen wrote: > >>> > >>> What about considering a hitchhikers guide to SDP similar to > what was done for SIP? > >>> > >>> One umbrella document that points the reader to all the SDP > capabilities available that they might want to take advantage of. > >>> > >>> Just a suggestion. > >>> > >>> Andrew > >>> > >>> ----- Original Message ----- > >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com > ] > >>> Sent: Saturday, January 28, 2012 06:23 AM > >>> To: mmusic> > >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >>> > >>> > >>> > >>> Hi all, > >>> > >>> You know we are revising RFC 4566. So far, the effort has been > in bug fixing. > >>> > >>> The first SDP version was published as RFC 2327 in 1998 (i.e., > 14 years > >>> ago), and was then revised as RFC 4566 in 2006. > >>> > >>> Lots of things have happened since then. We have SDP offer answer= , > >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida= , > >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pi= pe. > >>> > >>> From the point of view of a reader who takes 4566 (or its curre= nt > >>> 4566bis incarnation), I think it will be difficult for her or him= to > >>> understand a protocol that ignores those other extensions. For > example, I > >>> recently post another e-mail where there is an apparent > contradiction > >>> between 4566 and ICE (see > >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html= ). > >>> > >>> So, I was wondering if time has come to make not a bug correction= in > >>> 4566bis, but also put that RFC in context with the other > extensions that > >>> exist. This may include: > >>> > >>> - Add minor extensions to the core document, similarly to what > we did > >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know whic= h > of these > >>> extensions make sense to include, this would be an exercise to > do, but > >>> let me give you one potential example: RFC 4574, the SDP "label" > >>> attribute is a 6 pages RFC. > >>> > >>> - Adding references to extensions, when it makes sense. For > example, ICE > >>> should be referred somewhere (see my previous post regarding the = "o" > >>> line). I guess capneg could be also mentioned, perhaps others. > >>> > >>> I know this is a bigger effort than anticipated, but the result > could > >>> really help newcomers to this world. > >>> > >>> Now, it is your turn to express your opinions. Please do it. > >>> > >>> /Miguel > >> > >> -- > >> Miguel A. Garcia > >> +34-91-339-3608 > >> Ericsson Spain > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From paulej@packetizer.com Sun Feb 26 13:48:04 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D988921F8555 for ; Sun, 26 Feb 2012 13:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2yWqSVtS5gp for ; Sun, 26 Feb 2012 13:48:04 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F0DC621F8550 for ; Sun, 26 Feb 2012 13:48:03 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q1QLm1o9016312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Feb 2012 16:48:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1330292882; bh=m2IeEFv4DeTPdHUqV0DUD8fndcnSBzW14nMGOU+7pm8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=s/m8NHFP1KgO/nh3mAUAyhzUj7Ho8RbQq3TM2YcX7cixgTmxUJPgxfnp1Nzt56Hw0 VLSA3DWKFv22+OYTcn+XSxAAlEVgoXKkpdbO0EzdSWuwV2cCOviSq23k6DPrNWvhz/ apBykYq3MMfACh/GuaaXDQVxc12Y4Gg9+K50VDWI= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <00c901ccf31d$f3226320$d9672960$@packetizer.com> <4F47F494.7090406@alum.mit.edu> In-Reply-To: <4F47F494.7090406@alum.mit.edu> Date: Sun, 26 Feb 2012 16:48:06 -0500 Message-ID: <013601ccf4d0$53885400$fa98fc00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-index: AQIkhRBjyENkiMN4ljZbyR23CB/tDgIKxMDMlZA40fA= Subject: Re: [MMUSIC] Traffic Class Labels and classes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 21:48:05 -0000 Paul, > Its far from evident that putting it at the end makes it quicker to > identify. Programmatically, it is. That was part of the reason we specified it this way. One would not have to inspect the actual values of adjectives: just jump to the end and you'd find the admission qualifier. > If it is really different from an adjective, then it might be helpful to > syntactically distinguish it. Putting it at the end is one way. What you > suggest below is another. We can find others. But first we should figure > out if it really is different from an adjective, or if it is simply an > adjective that is of more general interest than most. It isn't different from other adjectives. This is why it was suggested we change the syntax. It was also argued that some labels may not have an admission qualifier, so it should not be required. So, it now becomes an adjective that is no different than any other. > One difference might be how its registered. Apparently the admission > qualifiers apply to all parents and applications, while maybe (I'm not > certain) adjectives need to be registered separately for each > parent+application combination they are valid with. That was our initial thinking, but we got push back on that. However, I think we can have our cake and eat it too by using classes. The adjective is placed anywhere, yet still quickly identified -- even if not understood. > > It was suggested that perhaps we actually consider grouping adjectives > > into classes. The admission qualifier is just one class of adjectives, > > after all. I like the idea, since it would allow an application to > > quickly identify a type of adjective, even if it does not understand > > what the adjective value is. > > This seems interesting. But only if the significance of a class can be > nailed down. Perhaps my musing above relates to this: > > If adjectives are gathered into classes, then maybe the registration of an > application could specify the classes that are relevant to it, rather than > the specific adjectives. All adjectives from any of the allowed classes > would then be permitted. I think we would need to specify both. However, I believe it's really the other way around. A class or adjective that we define and register should indicate what categories and applications to which it is relevant. After all, we will introduce new adjectives and new classes as we go forward. As those are registered, we should not have to update the category or application registrations. > > The class concept would use a syntax like "classname:adjective". For > > the admission qualifier, we might use "aq". So, an example TCL might be: > > > > Conversational.video.alpha.beta.aq:admitted.gamma > > > > I would like to hear others' opinions on use of classes to logically > > group adjectives. > > Is it necessary to actually code the adjective class in the name? It is if > the same adjective names can be used with differing meanings in different > classes. But if you require all adjective names to be unique regardless of > class, then you don't need to encode the class name. Including the class name allows us to quickly identify adjectives of a certain class, even if the adjective itself is not understood. It would also allow the same name to be used in two different classes. This might be useful, though I do not have a good example right now. > The class concept might also be a way to deal with non-registered > adjectives. > > > We would want to keep classless adjectives, too. So, the modified > > syntax would be roughly: > > > > parent "." application *("." [class] adjective) > > Maybe rather than classless adjectives, how about a default class. That > way all adjectives would have some class, which would be useful in IANA > registration templates, documentation, etc. Classless, no class, or "default" class -- does not matter to me. I just think we need to allow some adjectives to be defined that are not part of a specific class. Paul From vsingh.ietf@gmail.com Mon Feb 27 02:55:59 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D2721F863B for ; Mon, 27 Feb 2012 02:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax0aMhdEY-4y for ; Mon, 27 Feb 2012 02:55:58 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED4FE21F864C for ; Mon, 27 Feb 2012 02:55:57 -0800 (PST) Received: by werb10 with SMTP id b10so1174538wer.31 for ; Mon, 27 Feb 2012 02:55:57 -0800 (PST) Received-SPF: pass (google.com: domain of vsingh.ietf@gmail.com designates 10.180.77.228 as permitted sender) client-ip=10.180.77.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vsingh.ietf@gmail.com designates 10.180.77.228 as permitted sender) smtp.mail=vsingh.ietf@gmail.com; dkim=pass header.i=vsingh.ietf@gmail.com Received: from mr.google.com ([10.180.77.228]) by 10.180.77.228 with SMTP id v4mr26874184wiw.2.1330340157255 (num_hops = 1); Mon, 27 Feb 2012 02:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=ci/3akLrOOy6zyCWmZlm9eIgwZNqQjsqvL1TCIMw3WI=; b=WYQvXpsJzxWpHH+FBZ207g5Ejcq4F8KYHemUhyFjzv0QvTc70NjOcmYDgjisEe7dxf F7bJ8TwK7FrQk5L/C1TKuYn6MjWPo3NHyorPpK1NKlAKAl6jTPmRwH51rjkP7d8hPmo8 GIerZeh3eU/pMdNSI2jBCDbzseNCUeXbrrifE= Received: by 10.180.77.228 with SMTP id v4mr21303767wiw.2.1330340157195; Mon, 27 Feb 2012 02:55:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.70.130 with HTTP; Mon, 27 Feb 2012 02:55:37 -0800 (PST) From: Varun Singh Date: Mon, 27 Feb 2012 12:55:37 +0200 Message-ID: To: mmusic Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 10:55:59 -0000 Hi, We have submitted an updated draft for Multipath RTP (MPRTP) and would like the WG to review the draft and provide feedback. The exact changes are: https://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-04.txt The changes are: 1. MPRTP Interface advertisement can be MPRTP interfaces can be done in RTCP or in SDP. Both extensions are in the draft. 2. If an endpoint wants to do NAT traversal then it should use ICE procedures but using ICE is optional. So session can be setup using ICE and without ICE (Examples for session setup are in Section 11.6). 3. Using MPRTP with RTSP 2.0 For MMUSIC the interesting parts are: Section 11 covers SDP: a. Indicating support for MPRTP in SDP. b. Advertise MPRTP interfaces in SDP. c. If an endpoint wants to do NAT traversal then how to use ICE with MPRTP. d. Using MPRTP in Offer/Answer and Declarative form. e. Examples for ICE and non-ICE O/A Section 12 describes procedures for using MPRTP in RTSP 2.0 i. without ICE ii. with ICE iii. Extensions required. (PLAY_NOTIFY, RTSP Transport Header Extension etc) Initially, we have tried to keep all the information in one draft so that it is easier to compare and contrast the RTCP and SDP based interface advertisement. We plan to split the document, the simplest thing would be to put the RTSP part in another document. However, we are open to suggestions for splitting/keeping the draft as is. Cheers, Varun Begin forwarded message: > A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successfully submitted by Varun Singh and posted to the IETF repository. > > Filename: draft-singh-avtcore-mprtp > Revision: 04 > Title: Multipath RTP (MPRTP) > Creation date: 2012-02-27 > WG ID: Individual Submission > Number of pages: 49 > > Abstract: > The Real-time Transport Protocol (RTP) is used to deliver real-time > content and, along with the RTP Control Protocol (RTCP), forms the > control channel between the sender and receiver. However, RTP and > RTCP assume a single delivery path between the sender and receiver > and make decisions based on the measured characteristics of this > single path. Increasingly, endpoints are becoming multi-homed, which > means that they are connected via multiple Internet paths. Network > utilization can be improved when endpoints use multiple parallel > paths for communication. The resulting increase in reliability and > throughput can also enhance the user experience. This document > extends the Real-time Transport Protocol (RTP) so that a single > session can take advantage of the availability of multiple paths > between two endpoints. > > > > > The IETF Secretariat From christer.holmberg@ericsson.com Mon Feb 27 03:43:30 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9121F86D6 for ; Mon, 27 Feb 2012 03:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7QfQxugI0wM for ; Mon, 27 Feb 2012 03:43:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7C221F86DB for ; Mon, 27 Feb 2012 03:43:28 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-24-4f4b6c5ead51 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.D5.27041.E5C6B4F4; Mon, 27 Feb 2012 12:43:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 27 Feb 2012 12:43:25 +0100 From: Christer Holmberg To: Varun Singh , mmusic Date: Mon, 27 Feb 2012 12:42:45 +0100 Thread-Topic: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04.txt Thread-Index: Acz1PmaELaHDWUWiTGmNPXMloUQ0UAAAmEOQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A501B@ESESSCMS0356.eemea.ericsson.se> References: 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: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 11:43:30 -0000 Hi Varun, I will have to look through my old comments, but a few ones that come to my= mind when taking a first look at the new version of the draft. Q1: The draft basically defines a mechanism to, without ICE, provide altern= ative IP addresses, e.g. one IPv4 and IPv6 address. But, eventhough the use= -case is a little different, it doesn't mandate the usage of all addresses.= We have had discussions about before, when people have suggested new attri= butes from provding alternative IP addresses, so I think the comments that = have been given then needs to be evalauated also against this draft. Q2: The draft says that ICE MAY be used to perform connectivity checks. But= , if ICE is not used, what is then? Q3: Section 7.1.1. says, that if an interface is reachable, connectivity ch= ecks are not needed. That sounds a little strange, but I assume you mean so= mething else. Globally reachable? Q4: Section 7.1.3. talks about in-band interface announcement. How does tha= t affect the SDP state? Q5: Section 7.4 says that flows must be kept alive, but there is no referen= ce to any keep-alive mechanism for doing that. Q6: Section 8.1.1 says that ICE may be used to gather additional candidates= . But, aren't you only talking about additional interfaces, ie host candida= tes in ICE language. Why do you need ICE to gather such? Q7a: In section 11.6.2.2 the first offer contains ICE information, but the = updated offer doesn't. Is the intention to terminate ICE?=20 Q7b: In section 11.6.2.2 the association between ICE candidates and interfa= ces are not described. I assume you are using a 1:1 mapping, or? Regards, Christer =20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Varun Singh Sent: 27. helmikuuta 2012 12:56 To: mmusic Subject: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04= .txt Hi, We have submitted an updated draft for Multipath RTP (MPRTP) and would like= the WG to review the draft and provide feedback. The exact changes are: https://tools.ietf.org/rfcdiff?url2=3Ddraft-singh-avtcore-mprtp-04.txt The changes are: 1. MPRTP Interface advertisement can be MPRTP interfaces can be done in RT= CP or in SDP. Both extensions are in the draft. 2. If an endpoint wants to do NAT traversal then it should use ICE procedur= es but using ICE is optional. So session can be setup using ICE and without= ICE (Examples for session setup are in Section 11.6). 3. Using MPRTP with RTSP 2.0 For MMUSIC the interesting parts are: Section 11 covers SDP: a. Indicating support for MPRTP in SDP. b. Advertise MPRTP interfaces in SDP. c. If an endpoint wants to do NAT traversal then how to use ICE with MPRTP. d. Using MPRTP in Offer/Answer and Declarative form. e. Examples for ICE and non-ICE O/A Section 12 describes procedures for using MPRTP in RTSP 2.0 i. without ICE = ii. with ICE iii. Extensions required. (PLAY_NOTIFY, RTSP Transport Header = Extension etc) Initially, we have tried to keep all the information in one draft so that i= t is easier to compare and contrast the RTCP and SDP based interface advert= isement. We plan to split the document, the simplest thing would be to put the RTSP = part in another document. However, we are open to suggestions for splitting= /keeping the draft as is. Cheers, Varun Begin forwarded message: > A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successfu= lly submitted by Varun Singh and posted to the IETF repository. > > Filename: draft-singh-avtcore-mprtp > Revision: 04 > Title: Multipath RTP (MPRTP) > Creation date: 2012-02-27 > WG ID: Individual Submission > Number of pages: 49 > > Abstract: > The Real-time Transport Protocol (RTP) is used to deliver real-time > content and, along with the RTP Control Protocol (RTCP), forms the > control channel between the sender and receiver. However, RTP and > RTCP assume a single delivery path between the sender and receiver > and make decisions based on the measured characteristics of this > single path. Increasingly, endpoints are becoming multi-homed, which > means that they are connected via multiple Internet paths. Network > utilization can be improved when endpoints use multiple parallel > paths for communication. The resulting increase in reliability and > throughput can also enhance the user experience. This document > extends the Real-time Transport Protocol (RTP) so that a single > session can take advantage of the availability of multiple paths > between two endpoints. > > > > > The IETF Secretariat _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From vsingh.ietf@gmail.com Mon Feb 27 05:15:40 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5321F870F for ; Mon, 27 Feb 2012 05:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxW8Redi-HV8 for ; Mon, 27 Feb 2012 05:15:39 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2109621F8647 for ; Mon, 27 Feb 2012 05:15:38 -0800 (PST) Received: by wicr5 with SMTP id r5so885895wic.31 for ; Mon, 27 Feb 2012 05:15:38 -0800 (PST) Received-SPF: pass (google.com: domain of vsingh.ietf@gmail.com designates 10.180.80.35 as permitted sender) client-ip=10.180.80.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vsingh.ietf@gmail.com designates 10.180.80.35 as permitted sender) smtp.mail=vsingh.ietf@gmail.com; dkim=pass header.i=vsingh.ietf@gmail.com Received: from mr.google.com ([10.180.80.35]) by 10.180.80.35 with SMTP id o3mr28221763wix.5.1330348538423 (num_hops = 1); Mon, 27 Feb 2012 05:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+moEqxNct2+QUpW7DCM5BsE6+KUqC17qznplufRkzXg=; b=RL4ayrnbdATWyAZ/zOovjaiDOOybsYEegG5ae1m04sdw+FbfKOne1koftZN+lufmxa 7NoAS2s8bzcDvMIEihxo2LYu+K4n3N3IgK4yqBZ2Wu71AhaatEzSszdt+G0soEG4IK9n VcIbFX2mW5WiB2w9TiUY4XkSSOiRQ3/WhMj9w= Received: by 10.180.80.35 with SMTP id o3mr22377892wix.5.1330348538362; Mon, 27 Feb 2012 05:15:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.70.130 with HTTP; Mon, 27 Feb 2012 05:15:18 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A501B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A501B@ESESSCMS0356.eemea.ericsson.se> From: Varun Singh Date: Mon, 27 Feb 2012 15:15:18 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmusic Subject: Re: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 13:15:40 -0000 Hi Christer, Comments inline. On Mon, Feb 27, 2012 at 13:42, Christer Holmberg wrote: > > Hi Varun, > > I will have to look through my old comments, but a few ones that come to = my mind when taking a first look at the new version of the draft. > > Q1: The draft basically defines a mechanism to, without ICE, provide alte= rnative IP addresses, e.g. one IPv4 and IPv6 address. But, eventhough the u= se-case is a little different, it doesn't mandate the usage of all addresse= s. We have had discussions about before, when people have suggested new att= ributes from provding alternative IP addresses, so I think the comments tha= t have been given then needs to be evalauated also against this draft. > The context or use-case is slightly different, because the intention of the endpoint is to use all the advertised interfaces (which may be a subset of its available interfaces). If an interface has both v4 and a v6 addresses then the potential challenge using both the addresses is if the scheduling algorithm (or congestion control) is able to take into account the available bandwidth. Since the scheduling algorithm is not discussed in draft, we haven't specified what may happen if an endpoint advertises both the IPv4 and IPv6 address for a single interface. So is the comment that we cannot advertise MPRTP interfaces in SDP? > Q2: The draft says that ICE MAY be used to perform connectivity checks. B= ut, if ICE is not used, what is then? > Nothing. NAT traversal is optional. If the endpoint is in a deployment where the other endpoints are reachable (globally/locally) then they shouldn't need to use ICE. > Q3: Section 7.1.1. says, that if an interface is reachable, connectivity = checks are not needed. That sounds a little strange, but I assume you mean = something else. Globally reachable? > Yes, globally reachable or in some deployments/configurations where the endpoints are reachable. > Q4: Section 7.1.3. talks about in-band interface announcement. How does t= hat affect the SDP state? > See response to this in Q7a. > Q5: Section 7.4 says that flows must be kept alive, but there is no refer= ence to any keep-alive mechanism for doing that. > In Section 7, we discuss about the available methods to choose from. So it should refer to RFC 6263 (RTP keep-alive). However, MPRTP proposes to multiplex RTP and RTCP on the same port (RFC 5761) in Section 8. > Q6: Section 8.1.1 says that ICE may be used to gather additional candidat= es. But, aren't you only talking about additional interfaces, ie host candi= dates in ICE language. Why do you need ICE to gather such? > Right, for additional candidates host candidates should be enough. However, for NAT traversal the endpoint would have to gather the candidates for each of its host candidates. > Q7a: In section 11.6.2.2 the first offer contains ICE information, but th= e updated offer doesn't. Is the intention to terminate ICE? > The intention is that at that point endpoint has sufficient interfaces to proceed with MPRTP. However, if the endpoints implements only aggressive ICE nomination, then we want the endpoints to continue with their ICE checks. The updated offer is to advertise which interfaces the endpoint is willing to use for MPRTP (stream media from or receive media on). While it is in an offer/answer it is more of a notification to the other endpoint. For this reason, we also propose in-band advertisement. As soon as the ICE checks succeed for a candidate, the endpoint can advertise its updated set in-band (in RTCP). The other endpoint on receiving the updated set of interfaces can start to stream data to them. In Section 11, we also propose that if an endpoint receives MPRTP interface advertisements in SDP and in RTCP (some kind of race condition) then it should just respond in SDP. See https://tools.ietf.org/html/draft-singh-avtcore-mprtp-04#section-11.4 Probably the endpoint's SDP state requires that the default address (in the c=3D and m=3D lines) are still available. > Q7b: In section 11.6.2.2 the association between ICE candidates and inter= faces are not described. I assume you are using a 1:1 mapping, or? Yes. 1:1 mapping but not all attributes in "a=3Dcandidate" (ICE) appear in "a=3Dmprtp interface" (MPRTP) Regards, Varun > > Regards, > > Christer > > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Varun Singh > Sent: 27. helmikuuta 2012 12:56 > To: mmusic > Subject: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-= 04.txt > > Hi, > > We have submitted an updated draft for Multipath RTP (MPRTP) and would li= ke the WG to review the draft and provide feedback. > The exact changes are: > https://tools.ietf.org/rfcdiff?url2=3Ddraft-singh-avtcore-mprtp-04.txt > > The changes are: > 1. MPRTP Interface advertisement can be =A0MPRTP interfaces can be done i= n RTCP or in SDP. Both extensions are in the draft. > 2. If an endpoint wants to do NAT traversal then it should use ICE proced= ures but using ICE is optional. So session can be setup using ICE and witho= ut ICE (Examples for session setup are in Section 11.6). > 3. Using MPRTP with RTSP 2.0 > > For MMUSIC the interesting parts are: > Section 11 covers SDP: > a. Indicating support for MPRTP in SDP. > b. Advertise MPRTP interfaces in SDP. > c. If an endpoint wants to do NAT traversal then how to use ICE with MPRT= P. > d. Using MPRTP in Offer/Answer and Declarative form. > e. Examples for ICE and non-ICE O/A > > Section 12 describes procedures for using MPRTP in RTSP 2.0 i. without IC= E ii. with ICE iii. Extensions required. (PLAY_NOTIFY, RTSP Transport Heade= r Extension etc) > > Initially, we have tried to keep all the information in one draft so that= it is easier to compare and contrast the RTCP and SDP based interface adve= rtisement. > We plan to split the document, the simplest thing would be to put the RTS= P part in another document. However, we are open to suggestions for splitti= ng/keeping the draft as is. > > > Cheers, > Varun > > > Begin forwarded message: >> A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successf= ully submitted by Varun Singh and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0draft-singh-avtcore-mprtp >> Revision: =A0 =A0 =A004 >> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Multipath RTP (MPRTP) >> Creation date: =A0 =A0 =A0 =A0 2012-02-27 >> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 49 >> >> Abstract: >> =A0 The Real-time Transport Protocol (RTP) is used to deliver real-time >> =A0 content and, along with the RTP Control Protocol (RTCP), forms the >> =A0 control channel between the sender and receiver. =A0However, RTP and >> =A0 RTCP assume a single delivery path between the sender and receiver >> =A0 and make decisions based on the measured characteristics of this >> =A0 single path. =A0Increasingly, endpoints are becoming multi-homed, wh= ich >> =A0 means that they are connected via multiple Internet paths. =A0Networ= k >> =A0 utilization can be improved when endpoints use multiple parallel >> =A0 paths for communication. =A0The resulting increase in reliability an= d >> =A0 throughput can also enhance the user experience. =A0This document >> =A0 extends the Real-time Transport Protocol (RTP) so that a single >> =A0 session can take advantage of the availability of multiple paths >> =A0 between two endpoints. >> >> >> >> >> The IETF Secretariat > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 http://www.netlab.tkk.fi/~varun/ From abegen@cisco.com Mon Feb 27 10:22:13 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFD21F878B for ; Mon, 27 Feb 2012 10:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYODGuZSl2rl for ; Mon, 27 Feb 2012 10:22:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 071FE21F8664 for ; Mon, 27 Feb 2012 10:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2360; q=dns/txt; s=iport; t=1330366928; x=1331576528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KnzmNzLUtygvbDsY17xwd86Ln0A4c32RZDZ978dJuOA=; b=C0UiGEKic0Xi+pieswomA9Bs+zl86PKtje350g7CsCpUhAhOlwEwijgb Rs0+GdmmyNtBvXmxu5BjZg9ncgU6rJsofpb3PYlgbtKEjmX6fb8gr1+CY KVXAdPeNjgTlBAOeQMF8PFhuSBecMZy/OEh2g+sg6SN+yF2xmSDh/K2JC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAAKjIS0+rRDoH/2dsb2JhbABDoX2Rd4EHgXMBAQEDARIBZgUHBAIBCBEEAQEBCh0HMhQJCAEBBAENBQgah18EAaEgAZcUiXmDBAUCDAEEBwwDAgYDBQoPCQMIGgkChQIPM4MBYwSoK4Fd X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="32692763" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 27 Feb 2012 18:22:08 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1RIM7cr020023; Mon, 27 Feb 2012 18:22:07 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Mon, 27 Feb 2012 10:22:07 -0800 From: "Ali C. Begen (abegen)" To: "Miguel A. Garcia" , OKUMURA Shinji Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.txt Thread-Index: AcywU07/iWInum7IS9O/m1fSSTKAyRFKPGrQ Date: Mon, 27 Feb 2012 18:22:06 +0000 Message-ID: References: <20111024175730.13367.80904.idtracker@ietfa.amsl.com> <4ED7C10A.3090906@ericsson.com> In-Reply-To: <4ED7C10A.3090906@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18738.005 x-tm-as-result: No--62.695400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:22:13 -0000 Sorry, I thought I replied to this message. Apparently, I have not. > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, December 01, 2011 1:02 PM > To: OKUMURA Shinji > Cc: mmusic@ietf.org; Ali C. Begen (abegen) > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.txt >=20 > Hi Shinji, >=20 > my replies (as an individual). I am also copying Ali, since he is editing > the draft. >=20 > On 30/11/2011 10:34, OKUMURA Shinji wrote: > > Hi, > > > > I have some questions concerning draft-ietf-mmusic-rfc4566bis-04. > > > > [Page 25] > > "If the sub-field is "udp" the sub-fields MUST > > reference a media type describing the format under the "audio", > > "video", "text", "application", or "message" top-level media > > types. The media type registration SHOULD define the packet > > format for use with UDP transport." > > > > Q1. In this document, there are some "media type", > > "top-level media content types", "top-level content type" > > and "top-level media types". > > > > Which do these mean "MIME media type" or "SDP media type"? > > Or do the both of two have the same meaning? > > I think these are ambiguous expressions. >=20 >=20 > I think in the past the original term was MIME type, but since it was not > only used for e-mail, that old term has been nowadays being replaced by > "media types". This is my understanding, too. =20 > A media type is composed of a "top-level media type", such as "audio", or > "video", and a "subtype", such as "G729" or "iLBC". Sometimes, the > "top-level media type" is also known as "Content type", or more simply, > "type". >=20 > I agree with you that the draft should be coherent with the terminology. > I suggest to avoid the word "MIME". And I suggest to pick one term for > the "top-level media type", I don't have a strong preference for one. I will replace "top-level content type" with "top-level media type". There = are just a few occurrences anyway. As for the MIME, I checked where it appeared. And I don=92t see a need for = any changes (I have not seen any confusion around those points). But, if yo= u think we need to change something, please propose a specific text.=20 Thanks. -acbegen=20 From internet-drafts@ietf.org Mon Feb 27 10:33:50 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC97421F87A9; Mon, 27 Feb 2012 10:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDGKdUee0pWn; Mon, 27 Feb 2012 10:33:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C8321F878B; Mon, 27 Feb 2012 10:33:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227183350.1912.52957.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 10:33:50 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:33:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-05.txt Pages : 49 Date : 2012-02-27 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-05.txt From fandreas@cisco.com Mon Feb 27 15:35:58 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9758D21E8053 for ; Mon, 27 Feb 2012 15:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIBw3dSG6EzU for ; Mon, 27 Feb 2012 15:35:57 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A252621E803C for ; Mon, 27 Feb 2012 15:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=10254; q=dns/txt; s=iport; t=1330385757; x=1331595357; h=message-id:date:from:mime-version:to:cc:subject; bh=ugJqvoTDhenUDBDNDZ/zHmLrAncY/dxL8pZ2ihxj0DQ=; b=D1KGPBjNymmtNQDLh+vLC7KSD1VRQb28MdQe22rIh9Zmf7SILG1lqjw5 nc2woHI0zmi6mRBVpzK0zVqayxsq+7n4klerl0g1A4r3miTKH7QdLOHW1 Z9yVSR8bVS2hJTthUFA82Z7LFy6t6/XN385/jggoI0mfavNGLqzetJlrm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAPgSTE+tJXHA/2dsb2JhbABDglGfeYgUAYkggQeCDAFlATwWGAMCAQIBSw0BBwEBBRmHZAugewGSDoUfiXmCfgMBAwMIBwMBCksOAQqEWQIHBR4DHQIDAQkCAgMCAQICAgEBBQMEAQkHBRaDNQSIT4xukwyBPw X-IronPort-AV: E=Sophos;i="4.73,493,1325462400"; d="scan'208,217";a="62215546" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2012 23:35:57 +0000 Received: from rtp-fandreas-8711.cisco.com (rtp-fandreas-8711.cisco.com [10.117.7.82]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1RNZufY002781; Mon, 27 Feb 2012 23:35:56 GMT Message-ID: <4F4C135C.2040905@cisco.com> Date: Mon, 27 Feb 2012 18:35:56 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------090301020501000905050706" Subject: [MMUSIC] WG poll on 3dformat and parallax drafts following recent IPR declarations X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 23:35:58 -0000 This is a multi-part message in MIME format. --------------090301020501000905050706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello MMUSIC group Following the initial submission and WG presentation of the 3dformat and parallax drafts, the WG expressed an interest in working on these topics and milestones were added to the MMUSIC charter. At the last IETF, the chairs polled the group for interest in adopting draft-greevenbosch-mmusic-signal-3d-format-02 and draft-greevenbosch-mmusic-parallax-attribute-01 as WG items for these milestones. A WG hum indicated support in the room for doing so, and hence they were adopted and resubmitted as WG drafts. At the time, there was no known IPR on either of these drafts, however the authors' affiliated company has subsequently submitted IPR declarations for both of these drafts. Since the 3dformat and parallax drafts were adopted as WG items without knowledge of the potential IPR issue, the chairs would like to sense the group for whether it still wishes to have these as WG items. The IPR declarations on the drafts are as follows: 1) draft-ietf-mmusic-signal-3d-format-00 had a Huawei IPR declaration 1673: http://datatracker.ietf.org/ipr/1673/ which points to the following patent application: http://ip.com/sipoen/102137298 Apparently this patent application was filed on March 2nd, 201 and the first version of this draft was published as draft-greevenbosch-mmusic-signal-3d-format-00.txt on March 3rd, 2011. 2) draft-ietf-mmusic-parallax-attribute-00 had a Huawei IPR declaration 1674: http://datatracker.ietf.org/ipr/1674/ which points to the following patent application: http://ip.com/sipoen/102137264 Apparently this patent application was filed on August 25th, 2010 and the first version of this draft was submitted as draft-greevenbosch-mmusic-parallax-attribute-00.txt on February 25th, 2011. We would like to remind all WG participants of their obligation to dislose any known IPR in accordance with RFC 3979 and in particular in accordance with the procedures stated in Section 6.2.1 of RFC 3979, which says: The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. The CCAMP WG experienced a similar incident recently, and as a result sent out a more detailed reminder, which is appropriate for everybody here to read as well: http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html Again, since the 3dformat and parallax drafts were adopted as WG items without knowledge of the potential IPR issue, the chairs are hereby soliciting the WG for feedback as to whether people still wish to have these drafts as WG items. Please comment Flemming and Miguel (MMUSIC chairs) --------------090301020501000905050706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello MMUSIC group

Following the initial submission and WG presentation of the 3dformat and parallax drafts, the WG expressed an interest in working on these topics and milestones were added to the MMUSIC charter. At the last IETF, the chairs polled the group for interest in adopting

            draft-greevenbosch-mmusic-signal-3d-format-02

and

            draft-greevenbosch-mmusic-parallax-attribute-01

as WG items for these milestones. A WG hum indicated support in the room for doing so, and hence they were adopted and resubmitted as WG drafts.

At the time, there was no known IPR on either of these drafts, however the authors' affiliated company has subsequently submitted IPR declarations for both of these drafts. Since the 3dformat and parallax drafts were adopted as WG items without knowledge of the potential IPR issue, the chairs would like to sense the group for whether it still wishes to have these as WG items.

The IPR declarations on the drafts are as follows:

1) draft-ietf-mmusic-signal-3d-format-00 had a Huawei IPR declaration 1673:
     http://datatracker.ietf.org/ipr/1673/

which points to the following patent application: http://ip.com/sipoen/102137298

Apparently this patent application was filed on March 2nd, 201 and the first version of this draft was published as draft-greevenbosch-mmusic-signal-3d-format-00.txt on March 3rd, 2011.

2) draft-ietf-mmusic-parallax-attribute-00 had a Huawei IPR declaration 1674:
    http://datatracker.ietf.org/ipr/1674/

which points to the following patent application: http://ip.com/sipoen/102137264

Apparently this patent application was filed on August 25th, 2010 and the first version of this draft was submitted as draft-greevenbosch-mmusic-parallax-attribute-00.txt on February 25th, 2011.


We would like to remind all WG participants of their obligation to dislose any known IPR in accordance with RFC 3979 and in particular in accordance with the procedures stated in Section 6.2.1 of RFC 3979, which says:

   The IPR disclosure required pursuant to section 6.1.1 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft unless the required disclosure is already on file.


The CCAMP WG experienced a similar incident recently, and as a result sent out a more detailed reminder, which is appropriate for everybody here to read as well: 

            http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html

 

Again, since the 3dformat and parallax drafts were adopted as WG items without knowledge of the potential IPR issue, the chairs are hereby soliciting the WG for feedback as to whether people still wish to have these drafts as WG items.


Please comment

           Flemming and Miguel (MMUSIC chairs)
 

--------------090301020501000905050706-- From magnus.westerlund@ericsson.com Tue Feb 28 00:42:41 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17DC21F872F for ; Tue, 28 Feb 2012 00:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.285 X-Spam-Level: X-Spam-Status: No, score=-110.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op4V1pxImw0N for ; Tue, 28 Feb 2012 00:42:41 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19B21F8710 for ; Tue, 28 Feb 2012 00:42:40 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-60-4f4c937f59e2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 45.59.01970.F739C4F4; Tue, 28 Feb 2012 09:42:39 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 09:42:39 +0100 Message-ID: <4F4C937E.5090900@ericsson.com> Date: Tue, 28 Feb 2012 09:42:38 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Stiemerling References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP 2.0: Vary header -- where to go with this X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 08:42:41 -0000 WG, My personal opinion of this is that we should remove Vary. This is a piece of HTTP that seems to poorly match RTSP and would need significant work to be made functional. For example Vary talks about server-driven negotation which isn't explained in the RTSP 2.0 spec at all. If you want to know of it you need to go read section 12.1 of RFC 2616 (HTTP). Although the idea behind the vary header may be usful for RTSP media stream caching I suspect a different approach is needed. If there is interest in any issue that would arise due to the cache and server not knowing the criterias for tailoring of the delivered media stream present in the cache then a more suitable solution will need to be developed. Cheers Magnus On 2012-02-21 11:46, Martin Stiemerling wrote: > Dear all, > > draft-ietf-mmusic-rfc2326bis-28 specifies the Vary header in Section 16.55. I have included the full text if this section below, for your reference. > > This header has been taken from HTTP/1.1 and did appear in past versions of draft-ietf-mmusic-rfc2326bis-28 as a simple reference to HTTP, i.e., without any explanation of what this header really means in RTSP. We copied and adapted the current text from HTTP/1.1 in one of the revisions of RTSP 2.0. > > However, we got the comment that Vary as operation is very unclear > and it is unclear if any existing RTSP 1.0 implementation is actually using this. It might be a good first indicator that Vary is not needed in RTSP 2.0 at all, if there is no implementation using this in RTSP 1.0. > > I can see why this header is available in HTTP, but I have doubts about in RTSP. > > Let me know your opinion. > > Here is the full text of Section 16.55 > > The Vary field value indicates the set of request-header fields that > fully determines, while the response is fresh, whether a cache is > permitted to use the response to reply to a subsequent request > without revalidation. For uncacheable or stale responses, the Vary > field value advises the user agent about the criteria that were used > to select the representation. A Vary field value of "*" implies that > a cache cannot determine from the request headers of a subsequent > request whether this response is the appropriate representation. > > An RTSP server SHOULD include a Vary header field with any cacheable > response that is subject to server-driven negotiation. Doing so > allows a cache to properly interpret future requests on that resource > and informs the user agent about the presence of negotiation on that > resource. A server MAY include a Vary header field with a non- > cacheable response that is subject to server-driven negotiation, > since this might provide the user agent with useful information about > the dimensions over which the response varies at the time of the > response. > > A Vary field value consisting of a list of field-names signals that > the representation selected for the response is based on a selection > algorithm which considers ONLY the listed request-header field values > in selecting the most appropriate representation. A cache MAY assume > that the same selection will be made for future requests with the > same values for the listed field names, for the duration of time for > which the response is fresh. > > The field-names given are not limited to the set of standard request- > header fields defined by this specification. Field names are case- > insensitive. > > A Vary field value of "*" signals that unspecified parameters not > limited to the request-headers (e.g., the network address of the > client), play a role in the selection of the response representation. > The "*" value MUST NOT be generated by a proxy server; it may only be > generated by an origin server. > > Martin > > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Martin.Stiemerling@neclab.eu Wed Feb 29 07:34:13 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803A421F86CB for ; Wed, 29 Feb 2012 07:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ8CoEGf6-I2 for ; Wed, 29 Feb 2012 07:34:12 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 452EA21F867E for ; Wed, 29 Feb 2012 07:34:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6C72228000205; Wed, 29 Feb 2012 16:34:01 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQZW19X-GjYW; Wed, 29 Feb 2012 16:34:01 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4AC9928000084; Wed, 29 Feb 2012 16:33:51 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 29 Feb 2012 16:33:51 +0100 From: Martin Stiemerling To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] RTSP 2.0: Vary header -- where to go with this Thread-Index: AczwhUQcldcIjPHyRDWJ/lcUKRjMDAFZ0bgAAEKwWWA= Date: Wed, 29 Feb 2012 15:33:50 +0000 Message-ID: References: <4F4C937E.5090900@ericsson.com> In-Reply-To: <4F4C937E.5090900@ericsson.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Magnus Westerlund Subject: Re: [MMUSIC] RTSP 2.0: Vary header -- where to go with this X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 15:34:13 -0000 Hi all,=20 I basically see it the same way, Vary is useful in HTTP but it will require= a lot work to bring to RTSP without seeing a clear need for it.=20 I will remove the Vary header from the upcoming version of the draft, unles= s somebody has any objection to it.=20 Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, February 28, 2012 9:43 AM > To: Martin Stiemerling > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP 2.0: Vary header -- where to go with this >=20 > WG, >=20 > My personal opinion of this is that we should remove Vary. This is a > piece of HTTP that seems to poorly match RTSP and would need significant > work to be made functional. >=20 > For example Vary talks about server-driven negotation which isn't > explained in the RTSP 2.0 spec at all. If you want to know of it you > need to go read section 12.1 of RFC 2616 (HTTP). >=20 > Although the idea behind the vary header may be usful for RTSP media > stream caching I suspect a different approach is needed. If there is > interest in any issue that would arise due to the cache and server not > knowing the criterias for tailoring of the delivered media stream > present in the cache then a more suitable solution will need to be > developed. >=20 > Cheers >=20 > Magnus >=20 > On 2012-02-21 11:46, Martin Stiemerling wrote: > > Dear all, > > > > draft-ietf-mmusic-rfc2326bis-28 specifies the Vary header in Section > 16.55. I have included the full text if this section below, for your > reference. > > > > This header has been taken from HTTP/1.1 and did appear in past > versions of draft-ietf-mmusic-rfc2326bis-28 as a simple reference to > HTTP, i.e., without any explanation of what this header really means in > RTSP. We copied and adapted the current text from HTTP/1.1 in one of the > revisions of RTSP 2.0. > > > > However, we got the comment that Vary as operation is very unclear > > and > it is unclear if any existing RTSP 1.0 implementation is actually using > this. It might be a good first indicator that Vary is not needed in RTSP > 2.0 at all, if there is no implementation using this in RTSP 1.0. > > > > I can see why this header is available in HTTP, but I have doubts > about in RTSP. > > > > Let me know your opinion. > > > > Here is the full text of Section 16.55 > > > > The Vary field value indicates the set of request-header fields that > > fully determines, while the response is fresh, whether a cache is > > permitted to use the response to reply to a subsequent request > > without revalidation. For uncacheable or stale responses, the Vary > > field value advises the user agent about the criteria that were used > > to select the representation. A Vary field value of "*" implies tha= t > > a cache cannot determine from the request headers of a subsequent > > request whether this response is the appropriate representation. > > > > An RTSP server SHOULD include a Vary header field with any cacheable > > response that is subject to server-driven negotiation. Doing so > > allows a cache to properly interpret future requests on that resourc= e > > and informs the user agent about the presence of negotiation on that > > resource. A server MAY include a Vary header field with a non- > > cacheable response that is subject to server-driven negotiation, > > since this might provide the user agent with useful information abou= t > > the dimensions over which the response varies at the time of the > > response. > > > > A Vary field value consisting of a list of field-names signals that > > the representation selected for the response is based on a selection > > algorithm which considers ONLY the listed request-header field value= s > > in selecting the most appropriate representation. A cache MAY assum= e > > that the same selection will be made for future requests with the > > same values for the listed field names, for the duration of time for > > which the response is fresh. > > > > The field-names given are not limited to the set of standard request= - > > header fields defined by this specification. Field names are case- > > insensitive. > > > > A Vary field value of "*" signals that unspecified parameters not > > limited to the request-headers (e.g., the network address of the > > client), play a role in the selection of the response representation= . > > The "*" value MUST NOT be generated by a proxy server; it may only b= e > > generated by an origin server. > > > > Martin > > > > > > martin.stiemerling@neclab.eu > > > > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered= in > England 2832014 > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ----------------------------------------------------------------------