From ari.keranen@nomadiclab.com Fri Apr 1 00:31:39 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D029F3A691A for ; Fri, 1 Apr 2011 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPEu5T6kNLuP for ; Fri, 1 Apr 2011 00:31:36 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 6821B3A6A87 for ; Fri, 1 Apr 2011 00:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6E9424E6D8; Fri, 1 Apr 2011 10:33:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53R09WFO0I5t; Fri, 1 Apr 2011 10:33:14 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 81AFF4E6D1; Fri, 1 Apr 2011 10:33:14 +0300 (EEST) Message-ID: <4D957FC3.7070401@nomadiclab.com> Date: Fri, 01 Apr 2011 09:33:23 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jonathan Lennox References: <7B899E65-EFF9-4259-88DF-B926D8BDF5A6@vidyo.com> <4D94F8CF.7010109@nomadiclab.com> <9991D5E3-27CC-4484-83B2-65FFEEF24043@vidyo.com> In-Reply-To: <9991D5E3-27CC-4484-83B2-65FFEEF24043@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of ice-tcp-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:31:39 -0000 On 1.4.2011 8:09, Jonathan Lennox wrote: > On Mar 31, 2011, at 11:57 PM, Ari Keranen wrote: >> On 31.3.2011 20:06, Jonathan Lennox wrote: >>> >>> I think this needs to be MUST -- under what circumstances would >>> a sender want to insert false-positive STUN packets in the >>> stream? >>> >>> (Of course, depending on the content, it's possible that the >>> sender knows a priori that there can be no false positives, for >>> instance if it's sending a 7-bit-ASCII protocol.) >> >> While a bit of a corner case, I think this proves SHOULD is an >> appropriate one here :) > > I think the sender MUST ensure there are no false-positive STUN > packets in the stream, but as discussed here and the subsequent > discussion, there are a number of ways to accomplish this. Whether > to give implementation guidance as to how best to do it is a separate > matter, and I see your point about not wanting to go on too much > about it. I had an off-line discussion about this, and it seems having this as a MUST makes things simpler, and should not hurt really anyone. So let's make it a MUST in the next revision. >>> For section 5.2, Server Reflexive Candidates (and also the >>> prioritization formulas): >>> >>> Unless I'm missing something, Server Reflexive Candidates are >>> only possible and useful for Simultaneous-Open connections, not >>> Active or Passive? Either this should be pointed out, or there >>> should be an explanation of how you'd create, and how you'd make >>> use of, Server-Reflexive Active or Passive candidates. >> >> AFAIK, server reflexive should be OK also for passive candidates >> (once you do the tricks described in Appendix B). > > Ah, I see -- so you're recommending doing the "send from your receive > port" trick to STUN your passive candidate, in hopes the NAT has > Endpoint-Independent Filtering. I don't know how likely that policy > is going to be in practice (for pure server-reflexive, as opposed to > NAT-assisted, candidates), but I guess it couldn't hurt to try it, so > long as your OS supports the Appendix B tricks. Exactly. >> I could add to the server reflexive candidate section something >> along the lines of: >> >> Obtaining server reflexive passive candidates may require sending >> requests from the passive candidate; see Appendix B for >> implementation details. Server reflexive active candidates can be >> derived from the passive or S-O candidates by using the same IP >> address as the passive or S-O server reflexive candidate has. > > That makes sense. > > It's probably worth having some language describing why they're > useful, too (i.e. the TURN permissions issue) -- I probably won't be > the only person to miss that. OK, I'll add that too. >>> For section 5.3, UDP-Tunneled Candidates: >>> >>> When UDP tunneling is done by your operating system (as is the >>> case with Teredo on Microsoft Windows), it may not be obvious >>> based on the system APIs that a given candidate is in fact a >>> UDP-tunneled candidate and not a host candidate. If there is a >>> need to give UDP-tunneled candidates a lower type-preference, it >>> should be pointed out that implementations will need to detect >>> local pseudo-interfaces that are actually UDP tunnels. >> >> OK. This is a bit of an implementation detail, but I can try to >> add something along those lines to the section 5.4. > > As you wish. (It's not just Teredo on Windows; most OS-provided > tunnel addresses will look like an additional interface address, I > think.) > >>> There's also the complexity that Teredo candidates may, in fact, >>> end up being Relayed candidates, when matched up with non-Teredo >>> IPv6 addresses. Handling this (and de-prioritizing the pairs) >>> based on the normal rules of ICE would be very difficult, >>> however, other than by unilateral action of the controlling >>> endpoint. >> >> Yes. But given how complex this goes, I think we're better of >> without trying to define something for this. > > I agree we can't standardize this in any useful way, yes; but it > could be a consideration for the controlling endpoint's choice of > which pair to nominate, so it might be worth pointing out. > > On the other hand, it's not TCP-specific, and it's an implementation > detail; I know you're trying to stop the document from getting too > long. So as you wish. OK. I think it makes sense to avoid extra complexity here, but adding the short note about detecting the tunnel interface is still worth it. Cheers, Ari From stephen.botzko@gmail.com Fri Apr 1 00:41:26 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCD528C104 for ; Fri, 1 Apr 2011 00:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1+LY+x-zU96 for ; Fri, 1 Apr 2011 00:41:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id DF4F928C103 for ; Fri, 1 Apr 2011 00:41:24 -0700 (PDT) Received: by vxg33 with SMTP id 33so2927035vxg.31 for ; Fri, 01 Apr 2011 00:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dDzMvY2sjjzFB6lMFSOAewkzhZCvzKRb53tdtOfTra8=; b=kp4UfgeCACjMIrJtefLSzEz3d2XNnixWtpt2ssWiNju7JFaKbmenGFki4qTOxVEcHd B412PODWsH3Mqpo8sHtqRXGxZdDI75msYRRRX1u1AjGlYh7ix2911eCIJI8lYnHETOWI 9Y2JBtQSdcngC3vSb1wqS/tKZLvLZMMlvhwig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=q42zb9Z85UDwlgNw5Zh8Z9z1B1CAclFYUFxlRTJ8xaiZ3wmlrr0Zbcf6Fc4qpD2vkA bnqoJxsxs5MWtGJILdYsKTLDcW6FsWNOTgkZG4YtY9NMqiy/tVlOWjxiGjBPp9UiIrd4 c0uhP/7TAfqsVg8VB5r2VV9Qeve4qZ1RedGw0= MIME-Version: 1.0 Received: by 10.52.173.74 with SMTP id bi10mr5107848vdc.47.1301643784534; Fri, 01 Apr 2011 00:43:04 -0700 (PDT) Received: by 10.220.81.18 with HTTP; Fri, 1 Apr 2011 00:43:04 -0700 (PDT) In-Reply-To: References: <4919E001-92CF-4546-B759-8E4118CEB73E@magorcorp.com> Date: Fri, 1 Apr 2011 09:43:04 +0200 Message-ID: From: Stephen Botzko To: mmusic Content-Type: multipart/alternative; boundary=bcaec51b1bb966bc68049fd68f8c Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:41:26 -0000 --bcaec51b1bb966bc68049fd68f8c Content-Type: text/plain; charset=ISO-8859-1 I am wondering about the following: Section 3.1 "This is a declarative SDP parameter and is not negotiated." Section 3.3 "The offer MUST contain the sender's desired layout. The answer MAY contain the desired layout of the streams that the system sending the answer will be sending to the system that sent the offer." The text in section 3.3 looks like negotiation to me. Presumably the answering system is taking the offering system's desired layout into account. Also, I do not think the arrangement of audio streams in an MxN grid is very compelling - do you have a good use case for this? There are of course several sound formats already available in RFC 3551, I am wondering why we need to standardize more than that. BR Stephen Botzko On Fri, Apr 1, 2011 at 8:42 AM, Peter Musgrave wrote: > Hi Cullen/Ali, > > Overall, I think this is clean and usable. It solves enough useful cases > without trying to "solve world hunger". > > Is it worth having an example in which the video is SSRC muxed as described > in section 3.2? > > Also, I believe your example in 4.2 wants to have all the m lines be video > (they are audio in the sample). > > Thanks, > > Peter Musgrave > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --bcaec51b1bb966bc68049fd68f8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am wondering about the following:

Section 3.1 "This is a decl= arative SDP parameter and is not negotiated."

Section 3.3 "The offer MUST con= tain the sender's desired layout. The answer MAY contain the desired l= ayout of the streams that the system sending the answer will be sending to = the system that sent the offer."

The text in section 3.3 looks like negotiation to me.=A0 Presumably the= answering system is taking the offering system's desired layout into a= ccount.

Also, I do not think the arrangement of audio streams in an = MxN grid is very compelling - do you have a good use case for this?=A0 Ther= e are of course several sound formats already available in RFC 3551, I am w= ondering why we need to standardize more than that.

BR
Stephen Botzko


On Fri, Apr = 1, 2011 at 8:42 AM, Peter Musgrave <peter.musgrave@magorcorp.com> w= rote:
Hi Cullen/Ali,

Overall, I think this is clean and usable. It solves enough useful cases wi= thout trying to "solve world hunger".

Is it worth having an example in which the video is SSRC muxed as described= in section 3.2?

Also, I believe your example in 4.2 wants to have all the m lines be video = (they are audio in the sample).

Thanks,

Peter Musgrave


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

--bcaec51b1bb966bc68049fd68f8c-- From magnus.westerlund@ericsson.com Fri Apr 1 00:54:23 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBF53A6BFD for ; Fri, 1 Apr 2011 00:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdOVeBJ2MOiW for ; Fri, 1 Apr 2011 00:54:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D36173A6BD7 for ; Fri, 1 Apr 2011 00:54:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-5f-4d958512938f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0A.D1.21265.215859D4; Fri, 1 Apr 2011 09:56:02 +0200 (CEST) Received: from [153.88.17.18] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 1 Apr 2011 09:56:01 +0200 Message-ID: <4D958511.4040603@ericsson.com> Date: Fri, 1 Apr 2011 09:56:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4D9443CB.7080705@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "DRAGE, Keith \(Keith\)" , mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:54:23 -0000 Gonzalo Salgueiro skrev 2011-03-31 15:52: > Almost a year ago Kevin Fleming and I had this discussion. We ran into > this issue in the course of working with the ITU-T on a SIP Forum FoIP > TG initiated contribution to T.38. When updating references from RFC > 2327 to RFC 4566, we came across the fact that in RFC 2327 the > possible values for the 'media' type are documented as sharing the name > space with the top-level media content types in the MIME (RFC 2048) > registry, whereas in RFC 4566 this statement does not appear. RFC 4566 > does contain language that would appear to include such top-level media > content types as valid 'media' types in SDP, but also establishes a new > SDP-specific 'media' type registry. The MIME top-level media content > registry *does* have a registration for 'image'. As you correctly note, > IANA does not appear to have > actually created an SDP media type registry (and populated it with > the values from RFC 4566). As a result of this we intended to write the > I-D for consideration by MMUSIC to register the 'image' media type for > SDP. We'll happily submit this if the group agrees. > Isn't it simpler to just point at the media types registry in general. Not indicate which of the existing media types that might or might not be used in SDP. That way you don't have to change the SDP specification if anyone creates a new top media level type. Cheers 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 abegen@cisco.com Fri Apr 1 02:09:35 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41C23A67A4 for ; Fri, 1 Apr 2011 02:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1oIPP7MLnPt for ; Fri, 1 Apr 2011 02:09:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9E2BC3A6452 for ; Fri, 1 Apr 2011 02:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2258; q=dns/txt; s=iport; t=1301649075; x=1302858675; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=gpwfP7i4su4cEtPtcCqxpdpiyFQxZkJA63K+PC2WAi0=; b=nH4q119e9Sq1bCdo/2TrT1L5rfQ7Lky9HonIr0vGd+jJ6jI9hAPVE79h ZNK3/LOrK5R6rbphJ2RzL7TylspHq/almvbgBMAh/XuoO3UcqbTgEOIbe H1ExnVwDabtjbHusH+1S46WQ+Rz3w3TFG0lQ6lZ+mr132Cj7wa+b13luK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFmVlU2rRDoH/2dsb2JhbACYHo0+d6RUnDyDEIJbBIVEizY X-IronPort-AV: E=Sophos;i="4.63,281,1299456000"; d="scan'208";a="422203321" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2011 09:11:14 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p319BEDV006291; Fri, 1 Apr 2011 09:11:14 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 02:11:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 02:11:11 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EAAD3B5@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 Thread-Index: AcvwQHlMPKYZF36KTgeC8xO/Wnl9uAAC7lhg References: <4919E001-92CF-4546-B759-8E4118CEB73E@magorcorp.com> From: "Ali C. Begen (abegen)" To: "Stephen Botzko" , "mmusic" X-OriginalArrivalTime: 01 Apr 2011 09:11:14.0621 (UTC) FILETIME=[C064E6D0:01CBF04C] Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 09:09:35 -0000 We might need to fix the text but as the prezo said, the sender gives = its preference on how the media needs to be displayed on the other side. = And the other side - if it is sending media - tells this side how to = present that media. It is not negotiation. As for the audio, the use case may not be as compelling as it is for = video, but the semantics are not media dependent. In the revision, we should fix the errors in the examples. Thanks. -acbegen > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Stephen Botzko > Sent: Friday, April 01, 2011 9:43 AM > To: mmusic > Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 >=20 > I am wondering about the following: >=20 > Section 3.1 "This is a declarative SDP parameter and is not = negotiated." >=20 > Section 3.3 "The offer MUST contain the sender's desired layout. The = answer MAY contain the desired layout of the streams > that the system sending the answer will be sending to the system that = sent the offer." >=20 > The text in section 3.3 looks like negotiation to me. Presumably the = answering system is taking the offering system's desired > layout into account. >=20 > Also, I do not think the arrangement of audio streams in an MxN grid = is very compelling - do you have a good use case for > this? There are of course several sound formats already available in = RFC 3551, I am wondering why we need to standardize > more than that. >=20 > BR > Stephen Botzko >=20 >=20 >=20 > On Fri, Apr 1, 2011 at 8:42 AM, Peter Musgrave = wrote: >=20 >=20 > Hi Cullen/Ali, >=20 > Overall, I think this is clean and usable. It solves enough useful = cases without trying to "solve world hunger". >=20 > Is it worth having an example in which the video is SSRC muxed as = described in section 3.2? >=20 > Also, I believe your example in 4.2 wants to have all the m lines be = video (they are audio in the sample). >=20 > Thanks, >=20 > Peter Musgrave >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 From petithug@acm.org Fri Apr 1 03:23:14 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA46B3A67F1 for ; Fri, 1 Apr 2011 03:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avci+G5R-qZa for ; Fri, 1 Apr 2011 03:23:12 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 3EA7E3A67E9 for ; Fri, 1 Apr 2011 03:23:12 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id A58B3DBCC046; Fri, 1 Apr 2011 10:24:52 +0000 (UTC) Received: from [10.42.217.116] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id BF8C1DBCC044 for ; Fri, 1 Apr 2011 10:24:51 +0000 (UTC) Message-ID: <4D95A7F2.1050901@acm.org> Date: Fri, 01 Apr 2011 12:24:50 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] xkcd X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 10:23:14 -0000 Another great xkcd, relevant from this group I think... http://xkcd.com/880/ -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From stewe@stewe.org Fri Apr 1 03:45:26 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554533A67F5; Fri, 1 Apr 2011 03:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q+n+EXsCBEM; Fri, 1 Apr 2011 03:45:25 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0AFF73A67D3; Fri, 1 Apr 2011 03:45:24 -0700 (PDT) Received: from [130.129.83.67] (unverified [130.129.83.67]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4736-1743317 for multiple; Fri, 01 Apr 2011 12:47:03 +0200 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 01 Apr 2011 12:46:58 +0200 From: Stephan Wenger To: , , , Message-ID: Thread-Topic: Incoming liaison statement from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384506822_481335" X-Originating-IP: 130.129.83.67 X-Authenticated-User: stewe@stewe.org Subject: [MMUSIC] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 10:45:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384506822_481335 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from the MPEG meeting that took place last week. No action is requested from us. They have an initial draft for the profiles of their HTTP streaming project known as "DASH", which is in DIS state. In short, my reading is that they are currently considering one "simple" and one more complex profile for each MPEG-2 TS and ISO file format based mux structure, for a total of four profiles. The statement should appear on the IETF statement tracker shortly, but if you need a copy urgently, please send me a private email and I will forward. Thanks, Stephan --B_3384506822_481335 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
We have re= ceived a liaison statement from the MPEG meeting that took place last week. =  No action is requested from us.
They have an initial draft f= or the profiles of their HTTP streaming project known as "DASH", which is in= DIS state.  In short, my reading is that they are currently considerin= g one "simple" and one more complex profile for each MPEG-2 TS and ISO file = format based mux structure, for a total of four profiles.  The statemen= t should appear on the IETF statement tracker shortly, but if you need a cop= y urgently, please send me a private email and I will forward.
Tha= nks,
Stephan

--B_3384506822_481335-- From Bert.Greevenbosch@huawei.com Fri Apr 1 04:33:00 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4423A681B for ; Fri, 1 Apr 2011 04:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.072 X-Spam-Level: X-Spam-Status: No, score=-4.072 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44N6mqYPZpKu for ; Fri, 1 Apr 2011 04:32:59 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F0D8B3A6823 for ; Fri, 1 Apr 2011 04:32:58 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIZ004E11HG3G@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 01 Apr 2011 19:34:28 +0800 (CST) Received: from szxeml208-edg.china.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 <0LIZ00HNQ1HGLZ@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 01 Apr 2011 19:34:28 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 01 Apr 2011 19:34:22 +0800 Received: from SZXEML501-MBX.china.huawei.com ([169.254.5.242]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Fri, 01 Apr 2011 19:34:23 +0800 Date: Fri, 01 Apr 2011 11:34:22 +0000 From: Bert Greevenbosch X-Originating-IP: [172.24.2.40] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BFo4YoLFr1zIS76YTPyBeA)" Content-language: en-GB Accept-Language: en-GB, zh-CN, en-US Thread-topic: Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [MMUSIC] Remarks from today X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 11:33:00 -0000 --Boundary_(ID_BFo4YoLFr1zIS76YTPyBeA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts: Parallax Signalling draft * Why use unit "pixels"? Maybe should think of format that is more general for different display sizes. * Is the timed 3D text meant to overlay video? 3D Format draft * What is the relationship between the 3D Format draft and the RTP transport of MVC draft? * What is the relationship to the adjacent-grouping draft (and CLUE)? * Why signal it in SDP, when it can also be signalled in the codec? * Should there be a central registry for this kind of signalling? Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts. I plan to come back with detailed responses on the list next week. Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bert.greevenbosch@huawei.com telephone: +86-755-28978088 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China ******************************************************************************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ******************************************************************************* --Boundary_(ID_BFo4YoLFr1zIS76YTPyBeA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,

Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts:

Parallax Signalling draft
  • Why use unit "pixels"? Maybe should think of format that is more general for different display sizes.
  • Is the timed 3D text meant to overlay video?
3D Format draft
  • What is the relationship between the 3D Format draft and the RTP transport of MVC draft?
  • What is the relationship to the adjacent-grouping draft (and CLUE)?
  • Why signal it in SDP, when it can also be signalled in the codec?
  • Should there be a central registry for this kind of signalling?
Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts.

I plan to come back with detailed responses on the list next week.

Best regards,
Bert


---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bert.greevenbosch@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian, Longgang District

Shenzhen  518129

P.R. China

 

*******************************************************************************

This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!

*******************************************************************************

--Boundary_(ID_BFo4YoLFr1zIS76YTPyBeA)-- From christer.holmberg@ericsson.com Fri Apr 1 04:58:45 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464A43A6818 for ; Fri, 1 Apr 2011 04:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adm6sHb4hXKv for ; Fri, 1 Apr 2011 04:58:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3DCFC3A680E for ; Fri, 1 Apr 2011 04:58:44 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-cd-4d95be57941d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 18.07.09202.75EB59D4; Fri, 1 Apr 2011 14:00:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 1 Apr 2011 14:00:23 +0200 From: Christer Holmberg To: mmusic Date: Fri, 1 Apr 2011 14:00:21 +0200 Thread-Topic: IETF#80: mmusic notes Thread-Index: AcvwZGBf1XZrkWnESE+elfvFZmb6DA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851949172CD9@ESESSCMS0356.eemea.ericsson.se> 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: [MMUSIC] IETF#80: mmusic notes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 11:58:45 -0000 Hi, Below are my notes from the mmusic session. Regards, Christer -------------------------- General ------- - Request for RTSP 2.0 reviwers.=20 -- Peiyu Yue indicated willingness. - Milestones -- Indication that as soon as RTSP 2.0 is done we can move forward the rela= ted RTSP extensions. SDP Extension For Setting Up Audio and Video Media Streams Over Circuit-Swi= tched Bearers In The PSTN ---------------------------------------------------------------------------= ------------------------- Presenter: Simo Veikkolainen Draft: draft-ietf-mmusic-sdp-cs-06 - The presenter proposed to fix the open issues, submit a new version of th= at the draft, and then be able to initiate WGLC by June. Title and Bandwidth Capabilities Negotiation in the Session Description ----------------------------------------------------------------------- Presenter: Simo Veikkolainen Draft: draft-mmusic-sdp-icap-bcap-01 - It was questioned about the need and use-cases for the bandwidth capabili= ty attribute. A use-case needs to be added to the draft. ICE Updated Offer Problematic ----------------------------- Presenter: ??? Draft: draft-elwell-mmusic-ice-updated-offer-00 - The issues described in the draft, and mechanism proposals on how to solv= e those, were presented. - ISSUE 1: UPDATE race conditions -- Comment that an ICE entity should always know whether a updated offer is= expected.=20 -- In case an UPDATE would always be sent, it was questioned how long the r= emote peer should wait for that UPDATE. - ISSUE 2: Interaction with 3PCC - Conclusions -- Clarification on what types of middle boxes are considered. Indicated th= at middle boxes that modify SDP will terminte ICE. -- It was indictated that we should not raise the bar for implementing ICE,= e.g. by mandating the support of additional features (e.g. 100rel and prec= onditions). Media level ice-options SDP attribute ------------------------------------- Presenter: Marc Petit-Huguenin Draft: draft-petithuguenin-mmusic-ice-attributes-level-00 - There was interest in working with the problem defined in the problem. DCCP Encapsulation for NAT Traversal (DCCP-UDP) ----------------------------------------------- Presenter: Colen Perkins Draft: draft-ietf-dccp-udpencap-07 - The main issue is how to signal the support of the feature in SDP. -- Alt 1: Attribute with port number -- Alt 2: New m=3D protoc type - Comment that the usage of different port number will make things complica= ted, e.g. because many APIs etc only support one port number. - Different mechanisms were proposed: ICE, SDP CapNeg, SDP grouping framewo= rk. - Indicated that a similar issue exists for SCTP, and that we should aim to= come up with a generic solution that can be used also for that. SCTP-Based Media Transport in the SDP ------------------------------------- Presenter: Salvatore Loreto Draft: draft-loreto-mmusic-sctp-sdp-07 - Indication that some of the AVT groups are also working on a similar mult= ihoming problem, so it might be a good idea to have a look at what that wor= k. - Question whether there is a need for this, as there would be much work. I= s someone going to send media over SCTP? - Question what the advantage of sending media over SCTP is, if you can onl= y use one stream. - Further discussions are needed in order to clarify the scope of the propo= sed work. Grouping of Adjacent Media in the SDP ------------------------------------- Presenter: Cullen Jennings Draft: draft-jennings-mmusic-adjacent-grouping-03 - Indicated that the use-case is different from CLUE, and that draft should= not talk about telepresence. - Indicated that the use-case is not SDP offer/answer, but more a one-way d= escription. - Indicated that something similar might be needed for CLUE, but that this = is only a subset of what is needed for CLUE. SDP 'trafficclass' Attribute ---------------------------- Presenter: James Polk Draft: draft-polk-mmusic-traffic-class-for-sdp-01 - Indicated that the meaning of different attribute values need to be defin= ed. - Indicated that the WG could work on a framework, but that specific traffi= cclass values should be defined by others, working on specific areas. - Indicated that there needs to e.g. some global registry, where values are= defined, so that everyone have the same understanding on what the value me= ans. From mperumal@cisco.com Fri Apr 1 05:16:35 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE41F28C37B for ; Fri, 1 Apr 2011 05:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE1nrAmi+qPG for ; Fri, 1 Apr 2011 05:16:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9C74228C31E for ; Fri, 1 Apr 2011 05:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=17884; q=dns/txt; s=iport; t=1301659951; x=1302869551; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=IWCfhqNEVXruWWutD00vXgXmDsgmpDBHPleZt1bIFwc=; b=RaX+FdoWL5oekEQIbMPSVRa6iqgH/cI4b+Ryefvy9cm+KAa1TRWT4orm 7uLYkd1LdC25wu0AewtHzKQzLrTwQKE7/g52evAYvxLRcR1LDUZZOZHsP 7IMgz2wsMaqwKjKttwsEDCqtsMmUye+lW3MC0XHmG9UKiNLaPFEKvBxLS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAALzAlU2Q/khLgWdsb2JhbACYH40+FAEBFiYlpTucRIVrBIVCizg X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="24107889" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 12:12:30 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p31CCLTN019184; Fri, 1 Apr 2011 12:12:29 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 17:42:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 17:42:21 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513FC25@XMB-BGL-414.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058519491729BD@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? Thread-Index: AcvwAWdtQ+oOgn1/QH+21l+JdJh8dAAERjjQAAnZsoAACskQ8A== References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com><0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058519491729BD@ESESSCMS0356.eemea.ericsson.se> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Christer Holmberg" , "Hadriel Kaplan" , "mmusic" X-OriginalArrivalTime: 01 Apr 2011 12:12:26.0712 (UTC) FILETIME=[10AA5580:01CBF066] Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:16:36 -0000 Does 3GPP have similar issues in getting signaling protocols that operate on the media path (ICE, DTLS etc) though their SBCs? Do they have any recommendations to make them work better? thanks, Muthu=20 |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Friday, April 01, 2011 12:28 PM |To: Muthu ArulMozhi Perumal (mperumal); Hadriel Kaplan; mmusic |Subject: RE: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? | |Hi, | |>The main goal of the draft as it seems to claim is to |>describe the desirable behaviors of middleboxes and signaling |>protocols that operate on the media path, to aid in |>firewall/NAT traversal. It looks like an extension of RFC |>3303 whose focus is also firewall and NAT traversal |>use-cases. The draft claims that the architecture/functions |>it describes is used in IMS and specified in 3GPP, TISPAN and |>PacketCable specs -- if it true, then this is where the |>recommendations in the draft would be useful I think. | |3GPP already specifies NAT traversal etc behavior for their "SBCs". | |Regards, | |Christer | |> However, it doesn't look it would be useful for all B2BUA/SBC |> use-cases/deployments -- if we want to make it, then I think |> it would be a scope creep. |> |> Muthu |> |> |-----Original Message----- |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> Behalf Of Hadriel Kaplan |> |Sent: Friday, April 01, 2011 5:42 AM |> |To: mmusic |> |Subject: Re: [MMUSIC] Continued WG interest inSDP |> offer/answerwithmiddleboxes? |> | |> | |> |Howdy, |> |I read the draft, and also found the use of the term "ALG" to be |> confusing and annoying. It's not |> |just rfc3303 which defines an ALG as being in a inline/NAT |> type device |> - lots of the user market uses |> |the term ALG for inline type as well. (it's basically a derogatory |> term) One "SBC" vendor I know of |> |arguably had a real SIP ALG, but they went defunct years ago. |> | |> |Then again, the drawings actually show the SIP-ALG+middlebox not |> changing the SDP at all, so maybe |> |they do mean ALG. |> | |> |But anyway... I don't mean to sound negative, but what's the |> purpose of |> this document? What do we |> |think it's going to achieve if it's published as an RFC? |> |The only "output" of this document are four "preliminary |> recommendations". Of those four, I'd argue |> |three of them are now wrong or misleading, and the remaining one is |> unlikely to occur/help. It also |> |claims to describe the impact on ICE, but doesn't; claims to propose |> mechanisms to mitigate latching, |> |but doesn't; doesn't describe the issues with middleboxes |> and forked or |> moved calls on early in-band |> |media signaling; and uses terminology from ancient history (ie, RFC |> 3303). |> | |> |So what's the point of this doc again? |> | |> |-hadriel |> | |> | |> | |> |On Mar 31, 2011, at 10:13 AM, Dan Wing wrote: |> | |> |>> -----Original Message----- |> |>> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> |>> Sent: Thursday, March 31, 2011 1:01 PM |> |>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, |> Keith (Keith); |> |>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic |> |>> Subject: RE: [MMUSIC] Continued WG interest in SDP |> |>> offer/answerwithmiddleboxes? |> |>> |> |>> I agree with your interpretation of what an SBC is. However, the |> reason |> |>> why I don't find anything wrong in the use of ALG in |> |>> draft-ietf-mmusic-media-path-middleboxes is because it describes |> |>> firewall and NAT traversal functions that are typically |> implemented |> as |> |>> ALGs, except that these functions are decoupled into a |> MIDCOM agent |> and |> |>> a middle box. In addition RFC 3303 goes on to say |> (section 2.8) that |> |>> MIDCOM agents are entities performing ALG functions, logically |> external |> |>> to a middlebox. It even says these agents can reside on a proxy. |> |>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the |> ALG |> |>> in |> |>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the |> draft |> |>> I think. |> |> |> |> If Figure 1 was modified to show a NAT or firewall, it could |> reasonably |> |> use the term ALG with those devices. |> |> |> |> But when showing an SBC, which is smack in the middle of |> Figure 1, it |> |> cannot accurately call the SBC a "SIP ALG", as it does right now. |> |> |> |> -d |> |> |> |> |> |>> Muthu |> |>> |> |>> |-----Original Message----- |> |>> |From: Dan Wing (dwing) |> |>> |Sent: Wednesday, March 30, 2011 2:52 PM |> |>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); |> |>> 'DRAGE, Keith (Keith)'; 'Christer |> |>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' |> |>> |Subject: RE: [MMUSIC] Continued WG interest in SDP |> |>> offer/answerwithmiddleboxes? |> |>> | |> |>> |> -----Original Message----- |> |>> |> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> |>> |> Sent: Tuesday, March 29, 2011 3:58 PM |> |>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer |> |>> Holmberg; |> |>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic |> |>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP |> |>> |> offer/answerwithmiddleboxes? |> |>> |> |> |>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is |> just |> |>> an |> |>> |> extension of RFC 3303 -- while the later describes the |> middlebox |> |>> |> communication architecture and framework, the former describes |> some |> |>> of |> |>> |> the desirable behaviors of these middleboxes and protocols that |> |>> operate |> |>> |> on the media path unspecified in the later. RFC 3303 defines |> what |> |>> an |> |>> |> ALG is and it doesn't forbid packets being addressed to the ALG |> at |> |>> the |> |>> |> IP layer. |> |>> |> |> |>> |> |> |>> |> 2.6. ALG |> |>> |> Application Level Gateways (ALGs) are entities that |> possess the |> |>> |> application specific intelligence and knowledge of an |> associated |> |>> |> middlebox function. An ALG examines application traffic in |> transit |> |>> |> and assists the middlebox in carrying out its function. |> |>> |> |> |>> |> ALGs are different from proxies. ALGs are not visible to |> end-hosts, |> |>> |> unlike the proxies which are relay agents terminating sessions |> with |> |>> |> both end-hosts. ALGs do not terminate sessions with |> either end- |> |>> host. |> |>> |> Instead, ALGs examine, and optionally modify, |> application payload |> |>> |> content to facilitate the flow of application traffic |> through a |> |>> |> middlebox. |> |>> |> |> |>> |> 2.8. MIDCOM Agents |> |>> |> MIDCOM agents are entities performing ALG functions, logically |> |>> |> external to a middlebox. |> |>> |> |> |>> |> The packets may be addressed to the agent node at the IP layer. |> |>> |> Alternatively they may not be addressed to the agent node, but |> may |> |>> be |> |>> |> constrained by other factors to flow through it. |> |>> |> |> |>> |> |> |>> |> So, I don't see anything wrong in the use of ALG in |> |>> |> draft-ietf-mmusic-media-path-middleboxes, unless we |> plan to make |> |>> |> changes to how RFC 3303 describes it. |> |>> | |> |>> |3303 is quite clear, in exactly the text you quoted in the |> paragraph |> |>> |starting with "ALGs are different from proxies", that |> ALGs aren't |> |>> |visible to hosts and ALGs don't terminate sessions. |> |>> | |> |>> |An SBC is certainly visible to the end host, for both the SIP |> |>> |signaling and the RTP media -- the end host is sending |> packets to |> |>> |the SBC's IP address and receiving packets from the SBC's IP |> |>> |address. |> |>> | |> |>> |-d |> |>> | |> |>> | |> |>> |> Muthu |> |>> |> |> |>> |> |-----Original Message----- |> |>> |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> Behalf Of Parthasarathi R (partr) |> |>> |> |Sent: Wednesday, March 16, 2011 6:15 PM |> |>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); |> |>> |> Flemming |> |>> |> Andreasen (fandreas); mmusic |> |>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP |> |>> |> offer/answerwithmiddleboxes? |> |>> |> | |> |>> |> |Keith, |> |>> |> | |> |>> |> |Sorry in case "media" word in my mail mislead you. |> Dan explains |> in |> |>> |> |another mail thread |> |>> |> |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) |> |>> |> why |> |>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for |> this |> |>> |> draft. |> |>> |> | |> |>> |> | |> |>> |> |Fig 1 of |> draft-ietf-mmusic-media-path-middleboxes-03.txt exactly |> |>> fits |> |>> |> |your definition of B2BUA as it involves only SIP & |> SDP and media |> is |> |>> |> |defined as middlebox. |> |>> |> | |> |>> |> |I have mentioned as kind of B2BUA because the draft |> concentrates |> on |> |>> |> |callflow where one side of B2BUA acts as UAC and other side |> always |> |>> |> acts |> |>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC |> |>> callflows |> |>> |> |specific issues. In the current scope of draft is |> continued for |> the |> |>> |> |draft, the new definition may be required or draft text has to |> |>> clarify |> |>> |> |the scope. |> |>> |> | |> |>> |> |Thanks |> |>> |> |Partha |> |>> |> | |> |>> |> |-----Original Message----- |> |>> |> |From: DRAGE, Keith (Keith) |> [mailto:keith.drage@alcatel-lucent.com] |> |>> |> |Sent: Wednesday, March 16, 2011 5:33 PM |> |>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing |> (dwing); |> |>> |> |Flemming Andreasen (fandreas); mmusic |> |>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> |> |withmiddleboxes? |> |>> |> | |> |>> |> |The only definition of B2BUA that I know of comes in RFC 3261 |> (sort |> |>> |> of) |> |>> |> |where the scope is limited to SIP. So a UA acts in |> one or more |> |>> |> |directions as a SIP UA. Whatever else it does is outside the |> |>> |> definition. |> |>> |> |That I believe matches with what Christer is saying. |> |>> |> | |> |>> |> |If you want something that defines what it does with |> media, then |> |>> you |> |>> |> |need something that defines that, but using the term |> B2BUA to do |> |>> that |> |>> |> is |> |>> |> |probably not the best choice. |> |>> |> | |> |>> |> |Regards |> |>> |> | |> |>> |> |Keith |> |>> |> | |> |>> |> |> -----Original Message----- |> |>> |> |> From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> |> Behalf Of Parthasarathi R (partr) |> |>> |> |> Sent: 15 March 2011 09:54 |> |>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen |> |>> |> |> (fandreas); mmusic |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> middleboxes? |> |>> |> |> |> |>> |> |> Christer, |> |>> |> |> |> |>> |> |> AFAIK, There is no restriction in terms of SIP |> B2BUA to handle |> |>> |> |> signaling only and it is upto the implementation to decide. |> Also, |> |>> |> this |> |>> |> | |> |>> |> |> draft does not have restriction that SIP B2BUA and media |> server |> |>> has |> |>> |> to |> |>> |> | |> |>> |> |> be co-exist in the same device. The draft talks about the |> |>> scenario |> |>> |> |> wherein SIP B2BUA communicates with media server |> using Megaco |> |>> |> (H.248). |> |>> |> |> |> |>> |> |> As I mentioned in other mail thread, ALG does not look |> |>> appropriate |> |>> |> and |> |>> |> | |> |>> |> |> the draft is talking only about the specific type |> of B2BUA. In |> |>> real |> |>> |> |> deployment, Few vendors named these sort of B2BUA |> as "Session |> |>> Border |> |>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as |> SBC |> |>> does |> |>> |> |> lot more. In case there is a need to have different name for |> |>> these |> |>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work |> it |> |>> out. |> |>> |> |> |> |>> |> |> Thanks |> |>> |> |> Partha |> |>> |> |> |> |>> |> |> -----Original Message----- |> |>> |> |> From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> |> Behalf Of Christer Holmberg |> |>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM |> |>> |> |> To: Dan Wing (dwing); Flemming Andreasen |> (fandreas); 'mmusic' |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> middleboxes? |> |>> |> |> |> |>> |> |> |> |>> |> |> Hi Dan, |> |>> |> |> |> |>> |> |> In my definition of an ALG packets can be sent |> directly to its |> IP |> |>> |> |> address. |> |>> |> |> |> |>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG |> also |> |>> |> |> focuses on other things, like media. A SIP ALG |> contains a SIP |> |>> B2BUA. |> |>> |> |> |> |>> |> |> Regards, |> |>> |> |> |> |>> |> |> Christer |> |>> |> |> |> |>> |> |> -----Original Message----- |> |>> |> |> From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> |> Behalf Of Dan Wing |> |>> |> |> Sent: 15. maaliskuuta 2011 4:39 |> |>> |> |> To: 'Flemming Andreasen'; 'mmusic' |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> middleboxes ? |> |>> |> |> |> |>> |> |> The draft uses the term "SIP ALG", which at least |> does not fit |> my |> |>> |> |> definition of an ALG. An ALG doesn't have packets sent |> directly |> |>> to |> |>> |> |> its IP address; it does its job stealthily without awareness |> of |> |>> one |> |>> |> |> (or |> |>> |> |> both) of the sessoin endpoints. In contrast, the function |> |>> described |> |>> |> |> in draft-ietf-mmusic-media-path-middleboxes |> |>> |> |> is different -- packets are always sent to the IP address of |> the |> |>> SIP |> |>> |> |> "ALG", and packets are sent from the IP address of the SIP |> "ALG". |> |>> |> |> This functionality is most often called a "server" |> |>> |> |> or a "proxy" -- not an ALG. |> |>> |> |> |> |>> |> |> This distinction is important because this draft is closely |> |>> related |> |>> |> to |> |>> |> | |> |>> |> |> functions common in NATs, which _do_ sometimes have |> SIP ALGs |> |>> |> |> implemented in them. |> |>> |> |> |> |>> |> |> So ... can we change "SIP ALG" to something like "SIP proxy" |> |>> |> |> or "SIP user agent" or "SIP Back-to-Back User |> Agent"? Really, |> it |> |>> is |> |>> |> a |> |>> |> | |> |>> |> |> B2BUA, at least as best I understand the definition of a |> B2BUA, |> |>> so |> |>> |> |> B2BUA seems best. |> |>> |> |> |> |>> |> |> d |> |>> |> |> |> |>> |> |> |> |>> |> |> > -----Original Message----- |> |>> |> |> > From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> |>> On |> |>> |> |> > Behalf Of Flemming Andreasen |> |>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM |> |>> |> |> > To: mmusic |> |>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> > middleboxes ? |> |>> |> |> > |> |>> |> |> > We currently have a MMUSIC milestone for |> "considerations for |> |>> using |> |>> |> |> > SDP |> |>> |> |> |> |>> |> |> > offer/answer with middleboxes". The latest draft |> for this WG |> |>> item |> |>> |> is |> |>> |> |> > |> |>> |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt |> |>> |> |> > |> |>> |> |> > which expired in January 2011. There hasn't been much |> |>> discussion |> |>> |> on |> |>> |> |> > this topic for a while, and the current draft authors are |> not |> |>> |> |> > planning |> |>> |> |> |> |>> |> |> > continued work on the draft, so we need new authors if we |> are |> |>> to |> |>> |> |> > continue with this WG item. Please let us know if |> |>> |> |> > 1) You are still interested in this deliverable |> |>> |> |> > 2) You are willing to actively contribute to and/or author |> this |> |>> |> |> > document. |> |>> |> |> > |> |>> |> |> > Thanks |> |>> |> |> > |> |>> |> |> > Flemming & Miguel [MMUSIC chairs] |> |>> |> |> > |> |>> |> |> > |> |>> |> |> > _______________________________________________ |> |>> |> |> > 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 |> |>> |> |> _______________________________________________ |> |>> |> |> 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 |> | |> |_______________________________________________ |> |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 HKaplan@acmepacket.com Fri Apr 1 05:18:39 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76ED728CA9E for ; Fri, 1 Apr 2011 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3c953VOEyhd for ; Fri, 1 Apr 2011 05:18:38 -0700 (PDT) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id C8CED28CCE7 for ; Fri, 1 Apr 2011 05:14:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 1 Apr 2011 08:16:14 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 1 Apr 2011 08:16:14 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" Date: Fri, 1 Apr 2011 08:16:10 -0400 Thread-Topic: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? Thread-Index: AcvwZpf2DAHHvwOGRNGc8htfEXoaqQ== Message-ID: References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com> <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:18:40 -0000 On Mar 31, 2011, at 10:48 PM, Muthu ArulMozhi Perumal (mperumal) wrote: > The main goal of the draft as it seems to claim is to describe the > desirable behaviors of middleboxes and signaling protocols that operate > on the media path, to aid in firewall/NAT traversal. It looks like an > extension of RFC 3303 whose focus is also firewall and NAT traversal > use-cases. The draft claims that the architecture/functions it describes > is used in IMS and specified in 3GPP, TISPAN and PacketCable specs -- if > it true, then this is where the recommendations in the draft would be > useful I think. When you say "to aid in firewall/NAT traversal", I assume you mean when the= SIP+middlebox device *is* the firewall/NAT, right? You do NOT mean when a= SIP+middlebox device is out in the network, helping the UA traverse a Fire= wall/NAT in-between it and the UA? (what is normally called "Hosted NAT Tra= versal" or "Far-end NAT traversal" by vendors) I ask because the former case of being the NAT is not the same as the latte= r case. Latching and most of the policies described in this draft do not t= ypically apply to the former case, but do to the latter. ICE behaves diffe= rently for the two cases. SBCs, as well as the 3GPP and TISPAN variants, a= re of the latter variety, not the former. And they don't need an RFC to te= ll them anything, because it's not something they don't already know. What= 's worse, it's actually wrong or misleading in some of its recommendations. The draft conflates the two cases, probably because RFC 3303 did as well be= cause it is a really old RFC from back when the whole SIP middlebox market = began. And the draft is wrong about ICE because it was written before ICE = was published. "Extending" 3303 with this draft is useless at best, or har= mful at worst, unless it gets a serious re-write. My 2 cents anyway. -hadriel From jmpolk@cisco.com Fri Apr 1 05:33:43 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D94928C145 for ; Fri, 1 Apr 2011 05:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68MfPwYJnCQ5 for ; Fri, 1 Apr 2011 05:33:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C88153A68F7 for ; Fri, 1 Apr 2011 05:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2018; q=dns/txt; s=iport; t=1301661230; x=1302870830; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=gidj3gBrdu+gSxXC6cEv02OMuiqkBUv2+7dObFl4BKU=; b=KBPitpfRIxI+N6eetjWefvMM1ozFDBEPl7Y0KpQa3DJSbG1udbzkf/5Q WoXfbrCiM/Z+AKCwAESi8l2ElHa5mirLH6WI2rSZCLFQNBvfUZ77QGuUY TpTskgqjvid+JyzM0eOWKZiPYr44pVQULiNEXkElGD2SbrrQ3eDEi8dzx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG3FlU2rRDoG/2dsb2JhbAClXXelSJxAhWsEhUQ X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="328910914" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2011 12:33:49 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-vpn-client-10-89-7-59.cisco.com [10.89.7.59]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p31CXltu027365; Fri, 1 Apr 2011 12:33:48 GMT Message-Id: <201104011233.p31CXltu027365@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Apr 2011 07:33:41 -0500 To: mmusic From: "James M. Polk" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851949172CD9@ESESSCMS0356.ee mea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851949172CD9@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Christer Holmberg Subject: Re: [MMUSIC] IETF#80: mmusic notes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:33:43 -0000 At 07:00 AM 4/1/2011, Christer Holmberg wrote: >Hi, > >Below are my notes from the mmusic session. > >Regards, > >Christer > >-------------------------- comments on the set of observations regarding the following ID... >SDP 'trafficclass' Attribute >---------------------------- > >Presenter: James Polk >Draft: draft-polk-mmusic-traffic-class-for-sdp-01 > >- Indicated that the meaning of different attribute values need to be defined. agreed >- Indicated that the WG could work on a framework, but that specific >trafficclass values should be defined by others, working on specific areas. This was a late comment during the preso, and no one else really reacted to it. I believe there is a basic framework within this existing ID (i.e., the -01 version) about the structure of how the strings fit together to form a traffic classification label, but no consensus has been reached on that yet (obviously). I agreed during the preso that I don't want to overstep or overlap existing definitions that may exist - but I'm not sure that's exact what's written above. I also don't know if too many of these strings are defined anywhere at this time - or are defined in a way we want to use them (which may mean we have to switch to a string for a specific meaning we want). I'm open to be proven wrong. >- Indicated that there needs to e.g. some global registry, where >values are defined, so that everyone have the same understanding on >what the value means. agreed - but I hope this "global registry" is IANA, because that's all I talked about in today's preso. No one talked about anything other than IANA today. Another thing to consider is that we will have several layers looking at this same registry (i.e., applications and network layer folks) each from their own point of view. James >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From lennox@cs.columbia.edu Fri Apr 1 05:39:24 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A7F3A68CD for ; Fri, 1 Apr 2011 05:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG20R4ZEoSEj for ; Fri, 1 Apr 2011 05:39:24 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id 8AD2928C11F for ; Fri, 1 Apr 2011 05:38:53 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id B79C81F08B; Fri, 1 Apr 2011 08:40:33 -0400 (EDT) Received: from irtcluster12.cs.columbia.edu (irtcluster12.cs.columbia.edu [128.59.11.141]) by mailbackend.panix.com (Postfix) with ESMTP id 45DD532907; Fri, 1 Apr 2011 08:40:33 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> Date: Fri, 1 Apr 2011 08:40:32 -0400 To: Bert Greevenbosch In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:39:24 -0000 On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" saying: > Hi all, > > Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts: > [...] > > Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts. I had one other question I was going to ask, but the line had been closed. What is the backward-compability story here? It seems like a non-3D-aware endpoint receiving this SDP message is going to have a lot of problems understanding what it means. (Remember that in SDP, unknown attributes are ignored.) Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing. -- Jonathan Lennox lennox@cs.columbia.edu From christer.holmberg@ericsson.com Fri Apr 1 05:44:35 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DD53A6835 for ; Fri, 1 Apr 2011 05:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGEnjCMVYrC2 for ; Fri, 1 Apr 2011 05:44:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A44073A6802 for ; Fri, 1 Apr 2011 05:44:34 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-05-4d95c916bea8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BB.8D.09202.619C59D4; Fri, 1 Apr 2011 14:46:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 1 Apr 2011 14:46:14 +0200 From: Christer Holmberg To: "James M. Polk" , mmusic Date: Fri, 1 Apr 2011 14:46:13 +0200 Thread-Topic: [MMUSIC] IETF#80: mmusic notes Thread-Index: AcvwaQ7DCr6M1V+4TVezPLn62zauDgAAUVUQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851949172D28@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851949172CD9@ESESSCMS0356.eemea.ericsson.se> <201104011233.p31CXltu027365@mtv-core-1.cisco.com> In-Reply-To: <201104011233.p31CXltu027365@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] IETF#80: mmusic notes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:44:36 -0000 Hi James, >>- Indicated that the WG could work on a framework, but that specific=20 >>trafficclass values should be defined by others, working on=20 >>specific areas. >=20 >This was a late comment during the preso, and no one else=20 >really reacted to it. I believe there is a basic framework=20 >within this existing ID (i.e., the -01 version) about the=20 >structure of how the strings fit together to form a traffic=20 >classification label, but no consensus has been reached on=20 >that yet (obviously). I agreed during the preso that I don't=20 >want to overstep or overlap existing definitions that may=20 >exist - but I'm not sure that's exact what's written above.=20 >I also don't know if too many of these strings are defined=20 >anywhere at this time - or are defined in a way we want to=20 >use them (which may mean we have to switch to a string for a=20 >specific meaning we want). I'm open to be proven wrong. My intention was not to indicate that the WG has agreed on this, but simply= trying to reflect comments (this particular comment was given by myself :)= that were given during the session. >>- Indicated that there needs to e.g. some global registry,=20 >>where values are defined, so that everyone have the same understanding on= =20 >>what the value means. >=20 >agreed - but I hope this "global registry" is IANA, because=20 >that's all I talked about in today's preso. No one talked=20 >about anything other than IANA today. Sure. I agree that IANA would be the most obvious. Regards, Christer From thomas.belling@nsn.com Fri Apr 1 05:45:52 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED41A3A684F for ; Fri, 1 Apr 2011 05:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToaUm+7NUGSc for ; Fri, 1 Apr 2011 05:45:51 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 598D43A6835 for ; Fri, 1 Apr 2011 05:45:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p31ClMgC022014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 14:47:23 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p31ClLUu008648; Fri, 1 Apr 2011 14:47:21 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 14:47:17 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 14:47:15 +0200 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72203B5A837@DEMUEXC014.nsn-intra.net> In-Reply-To: <1D062974A4845E4D8A343C65380492020513FC25@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? Thread-Index: AcvwAWdtQ+oOgn1/QH+21l+JdJh8dAAERjjQAAnZsoAACskQ8AABcRHQ References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com><0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com><1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A058519491729BD@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C65380492020513FC25@XMB-BGL-414.cisco.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Muthu ArulMozhi Perumal (mperumal)" , "Christer Holmberg" , "Hadriel Kaplan" , "mmusic" X-OriginalArrivalTime: 01 Apr 2011 12:47:17.0224 (UTC) FILETIME=[EEB52680:01CBF06A] Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:45:53 -0000 For ICE: 3GPP terminates it as an SBC. -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Muthu ArulMozhi Perumal (mperumal) Sent: Friday, April 01, 2011 2:12 PM To: Christer Holmberg; Hadriel Kaplan; mmusic Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? Does 3GPP have similar issues in getting signaling protocols that operate on the media path (ICE, DTLS etc) though their SBCs? Do they have any recommendations to make them work better? thanks, Muthu=20 |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Friday, April 01, 2011 12:28 PM |To: Muthu ArulMozhi Perumal (mperumal); Hadriel Kaplan; mmusic |Subject: RE: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? | |Hi, | |>The main goal of the draft as it seems to claim is to describe the=20 |>desirable behaviors of middleboxes and signaling protocols that=20 |>operate on the media path, to aid in firewall/NAT traversal. It looks=20 |>like an extension of RFC |>3303 whose focus is also firewall and NAT traversal use-cases. The=20 |>draft claims that the architecture/functions it describes is used in=20 |>IMS and specified in 3GPP, TISPAN and PacketCable specs -- if it true, |>then this is where the recommendations in the draft would be useful I=20 |>think. | |3GPP already specifies NAT traversal etc behavior for their "SBCs". | |Regards, | |Christer | |> However, it doesn't look it would be useful for all B2BUA/SBC=20 |> use-cases/deployments -- if we want to make it, then I think it would |> be a scope creep. |> |> Muthu |> |> |-----Original Message----- |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> Behalf Of Hadriel Kaplan |> |Sent: Friday, April 01, 2011 5:42 AM |> |To: mmusic |> |Subject: Re: [MMUSIC] Continued WG interest inSDP |> offer/answerwithmiddleboxes? |> | |> | |> |Howdy, |> |I read the draft, and also found the use of the term "ALG" to be |> confusing and annoying. It's not |> |just rfc3303 which defines an ALG as being in a inline/NAT |> type device |> - lots of the user market uses |> |the term ALG for inline type as well. (it's basically a derogatory |> term) One "SBC" vendor I know of |> |arguably had a real SIP ALG, but they went defunct years ago. |> | |> |Then again, the drawings actually show the SIP-ALG+middlebox not |> changing the SDP at all, so maybe |> |they do mean ALG. |> | |> |But anyway... I don't mean to sound negative, but what's the |> purpose of |> this document? What do we |> |think it's going to achieve if it's published as an RFC? |> |The only "output" of this document are four "preliminary |> recommendations". Of those four, I'd argue |> |three of them are now wrong or misleading, and the remaining one is |> unlikely to occur/help. It also |> |claims to describe the impact on ICE, but doesn't; claims to propose |> mechanisms to mitigate latching, |> |but doesn't; doesn't describe the issues with middleboxes |> and forked or |> moved calls on early in-band |> |media signaling; and uses terminology from ancient history (ie, RFC |> 3303). |> | |> |So what's the point of this doc again? |> | |> |-hadriel |> | |> | |> | |> |On Mar 31, 2011, at 10:13 AM, Dan Wing wrote: |> | |> |>> -----Original Message----- |> |>> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> |>> Sent: Thursday, March 31, 2011 1:01 PM |> |>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, |> Keith (Keith); |> |>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic |> |>> Subject: RE: [MMUSIC] Continued WG interest in SDP=20 |> |>> offer/answerwithmiddleboxes? |> |>> |> |>> I agree with your interpretation of what an SBC is. However, the |> reason |> |>> why I don't find anything wrong in the use of ALG in=20 |> |>> draft-ietf-mmusic-media-path-middleboxes is because it describes=20 |> |>> firewall and NAT traversal functions that are typically |> implemented |> as |> |>> ALGs, except that these functions are decoupled into a |> MIDCOM agent |> and |> |>> a middle box. In addition RFC 3303 goes on to say |> (section 2.8) that |> |>> MIDCOM agents are entities performing ALG functions, logically |> external |> |>> to a middlebox. It even says these agents can reside on a proxy. |> |>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the |> ALG |> |>> in |> |>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the |> draft |> |>> I think. |> |> |> |> If Figure 1 was modified to show a NAT or firewall, it could |> reasonably |> |> use the term ALG with those devices. |> |> |> |> But when showing an SBC, which is smack in the middle of |> Figure 1, it |> |> cannot accurately call the SBC a "SIP ALG", as it does right now. |> |> |> |> -d |> |> |> |> |> |>> Muthu |> |>> |> |>> |-----Original Message----- |> |>> |From: Dan Wing (dwing) |> |>> |Sent: Wednesday, March 30, 2011 2:52 PM |> |>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); |> |>> 'DRAGE, Keith (Keith)'; 'Christer |> |>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' |> |>> |Subject: RE: [MMUSIC] Continued WG interest in SDP |> |>> offer/answerwithmiddleboxes? |> |>> | |> |>> |> -----Original Message----- |> |>> |> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> |>> |> Sent: Tuesday, March 29, 2011 3:58 PM |> |>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer |> |>> Holmberg; |> |>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic |> |>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP=20 |> |>> |> offer/answerwithmiddleboxes? |> |>> |> |> |>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is |> just |> |>> an |> |>> |> extension of RFC 3303 -- while the later describes the |> middlebox |> |>> |> communication architecture and framework, the former describes |> some |> |>> of |> |>> |> the desirable behaviors of these middleboxes and protocols that |> |>> operate |> |>> |> on the media path unspecified in the later. RFC 3303 defines |> what |> |>> an |> |>> |> ALG is and it doesn't forbid packets being addressed to the ALG |> at |> |>> the |> |>> |> IP layer. |> |>> |> |> |>> |> |> |>> |> 2.6. ALG |> |>> |> Application Level Gateways (ALGs) are entities that |> possess the |> |>> |> application specific intelligence and knowledge of an |> associated |> |>> |> middlebox function. An ALG examines application traffic in |> transit |> |>> |> and assists the middlebox in carrying out its function. |> |>> |> |> |>> |> ALGs are different from proxies. ALGs are not visible to |> end-hosts, |> |>> |> unlike the proxies which are relay agents terminating sessions |> with |> |>> |> both end-hosts. ALGs do not terminate sessions with |> either end- |> |>> host. |> |>> |> Instead, ALGs examine, and optionally modify, |> application payload |> |>> |> content to facilitate the flow of application traffic |> through a |> |>> |> middlebox. |> |>> |> |> |>> |> 2.8. MIDCOM Agents |> |>> |> MIDCOM agents are entities performing ALG functions, logically |> |>> |> external to a middlebox. |> |>> |> |> |>> |> The packets may be addressed to the agent node at the IP layer. |> |>> |> Alternatively they may not be addressed to the agent node, but |> may |> |>> be |> |>> |> constrained by other factors to flow through it. |> |>> |> |> |>> |> |> |>> |> So, I don't see anything wrong in the use of ALG in=20 |> |>> |> draft-ietf-mmusic-media-path-middleboxes, unless we |> plan to make |> |>> |> changes to how RFC 3303 describes it. |> |>> | |> |>> |3303 is quite clear, in exactly the text you quoted in the |> paragraph |> |>> |starting with "ALGs are different from proxies", that |> ALGs aren't |> |>> |visible to hosts and ALGs don't terminate sessions. |> |>> | |> |>> |An SBC is certainly visible to the end host, for both the SIP=20 |> |>> |signaling and the RTP media -- the end host is sending |> packets to |> |>> |the SBC's IP address and receiving packets from the SBC's IP=20 |> |>> |address. |> |>> | |> |>> |-d |> |>> | |> |>> | |> |>> |> Muthu |> |>> |> |> |>> |> |-----Original Message----- |> |>> |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> Behalf Of Parthasarathi R (partr) |> |>> |> |Sent: Wednesday, March 16, 2011 6:15 PM |> |>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); |> |>> |> Flemming |> |>> |> Andreasen (fandreas); mmusic |> |>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP |> |>> |> offer/answerwithmiddleboxes? |> |>> |> | |> |>> |> |Keith, |> |>> |> | |> |>> |> |Sorry in case "media" word in my mail mislead you. |> Dan explains |> in |> |>> |> |another mail thread |> |>> |> |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) |> |>> |> why |> |>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for |> this |> |>> |> draft. |> |>> |> | |> |>> |> | |> |>> |> |Fig 1 of |> draft-ietf-mmusic-media-path-middleboxes-03.txt exactly |> |>> fits |> |>> |> |your definition of B2BUA as it involves only SIP & |> SDP and media |> is |> |>> |> |defined as middlebox. |> |>> |> | |> |>> |> |I have mentioned as kind of B2BUA because the draft |> concentrates |> on |> |>> |> |callflow where one side of B2BUA acts as UAC and other side |> always |> |>> |> acts |> |>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC |> |>> callflows |> |>> |> |specific issues. In the current scope of draft is |> continued for |> the |> |>> |> |draft, the new definition may be required or draft text has to |> |>> clarify |> |>> |> |the scope. |> |>> |> | |> |>> |> |Thanks |> |>> |> |Partha |> |>> |> | |> |>> |> |-----Original Message----- |> |>> |> |From: DRAGE, Keith (Keith) |> [mailto:keith.drage@alcatel-lucent.com] |> |>> |> |Sent: Wednesday, March 16, 2011 5:33 PM |> |>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing |> (dwing); |> |>> |> |Flemming Andreasen (fandreas); mmusic |> |>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> |> |withmiddleboxes? |> |>> |> | |> |>> |> |The only definition of B2BUA that I know of comes in RFC 3261 |> (sort |> |>> |> of) |> |>> |> |where the scope is limited to SIP. So a UA acts in |> one or more |> |>> |> |directions as a SIP UA. Whatever else it does is outside the |> |>> |> definition. |> |>> |> |That I believe matches with what Christer is saying. |> |>> |> | |> |>> |> |If you want something that defines what it does with |> media, then |> |>> you |> |>> |> |need something that defines that, but using the term |> B2BUA to do |> |>> that |> |>> |> is |> |>> |> |probably not the best choice. |> |>> |> | |> |>> |> |Regards |> |>> |> | |> |>> |> |Keith |> |>> |> | |> |>> |> |> -----Original Message----- |> |>> |> |> From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> |> Behalf Of Parthasarathi R (partr) |> |>> |> |> Sent: 15 March 2011 09:54 |> |>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen |> |>> |> |> (fandreas); mmusic |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> middleboxes? |> |>> |> |> |> |>> |> |> Christer, |> |>> |> |> |> |>> |> |> AFAIK, There is no restriction in terms of SIP |> B2BUA to handle |> |>> |> |> signaling only and it is upto the implementation to decide. |> Also, |> |>> |> this |> |>> |> | |> |>> |> |> draft does not have restriction that SIP B2BUA and media |> server |> |>> has |> |>> |> to |> |>> |> | |> |>> |> |> be co-exist in the same device. The draft talks about the |> |>> scenario |> |>> |> |> wherein SIP B2BUA communicates with media server |> using Megaco |> |>> |> (H.248). |> |>> |> |> |> |>> |> |> As I mentioned in other mail thread, ALG does not look |> |>> appropriate |> |>> |> and |> |>> |> | |> |>> |> |> the draft is talking only about the specific type |> of B2BUA. In |> |>> real |> |>> |> |> deployment, Few vendors named these sort of B2BUA |> as "Session |> |>> Border |> |>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as |> SBC |> |>> does |> |>> |> |> lot more. In case there is a need to have different name for |> |>> these |> |>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work |> it |> |>> out. |> |>> |> |> |> |>> |> |> Thanks |> |>> |> |> Partha |> |>> |> |> |> |>> |> |> -----Original Message----- |> |>> |> |> From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> |> Behalf Of Christer Holmberg |> |>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM |> |>> |> |> To: Dan Wing (dwing); Flemming Andreasen |> (fandreas); 'mmusic' |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> middleboxes? |> |>> |> |> |> |>> |> |> |> |>> |> |> Hi Dan, |> |>> |> |> |> |>> |> |> In my definition of an ALG packets can be sent |> directly to its |> IP |> |>> |> |> address. |> |>> |> |> |> |>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG |> also |> |>> |> |> focuses on other things, like media. A SIP ALG |> contains a SIP |> |>> B2BUA. |> |>> |> |> |> |>> |> |> Regards, |> |>> |> |> |> |>> |> |> Christer |> |>> |> |> |> |>> |> |> -----Original Message----- |> |>> |> |> From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> On |> |>> |> |> Behalf Of Dan Wing |> |>> |> |> Sent: 15. maaliskuuta 2011 4:39 |> |>> |> |> To: 'Flemming Andreasen'; 'mmusic' |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> middleboxes ? |> |>> |> |> |> |>> |> |> The draft uses the term "SIP ALG", which at least |> does not fit |> my |> |>> |> |> definition of an ALG. An ALG doesn't have packets sent |> directly |> |>> to |> |>> |> |> its IP address; it does its job stealthily without awareness |> of |> |>> one |> |>> |> |> (or |> |>> |> |> both) of the sessoin endpoints. In contrast, the function |> |>> described |> |>> |> |> in draft-ietf-mmusic-media-path-middleboxes |> |>> |> |> is different -- packets are always sent to the IP address of |> the |> |>> SIP |> |>> |> |> "ALG", and packets are sent from the IP address of the SIP |> "ALG". |> |>> |> |> This functionality is most often called a "server" |> |>> |> |> or a "proxy" -- not an ALG. |> |>> |> |> |> |>> |> |> This distinction is important because this draft is closely |> |>> related |> |>> |> to |> |>> |> | |> |>> |> |> functions common in NATs, which _do_ sometimes have |> SIP ALGs |> |>> |> |> implemented in them. |> |>> |> |> |> |>> |> |> So ... can we change "SIP ALG" to something like "SIP proxy" |> |>> |> |> or "SIP user agent" or "SIP Back-to-Back User |> Agent"? Really, |> it |> |>> is |> |>> |> a |> |>> |> | |> |>> |> |> B2BUA, at least as best I understand the definition of a |> B2BUA, |> |>> so |> |>> |> |> B2BUA seems best. |> |>> |> |> |> |>> |> |> d |> |>> |> |> |> |>> |> |> |> |>> |> |> > -----Original Message----- |> |>> |> |> > From: mmusic-bounces@ietf.org |> [mailto:mmusic-bounces@ietf.org] |> |>> On |> |>> |> |> > Behalf Of Flemming Andreasen |> |>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM |> |>> |> |> > To: mmusic |> |>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP |> offer/answer |> |>> with |> |>> |> |> > middleboxes ? |> |>> |> |> > |> |>> |> |> > We currently have a MMUSIC milestone for |> "considerations for |> |>> using |> |>> |> |> > SDP |> |>> |> |> |> |>> |> |> > offer/answer with middleboxes". The latest draft |> for this WG |> |>> item |> |>> |> is |> |>> |> |> > |> |>> |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt |> |>> |> |> > |> |>> |> |> > which expired in January 2011. There hasn't been much |> |>> discussion |> |>> |> on |> |>> |> |> > this topic for a while, and the current draft authors are |> not |> |>> |> |> > planning |> |>> |> |> |> |>> |> |> > continued work on the draft, so we need new authors if we |> are |> |>> to |> |>> |> |> > continue with this WG item. Please let us know if |> |>> |> |> > 1) You are still interested in this deliverable |> |>> |> |> > 2) You are willing to actively contribute to and/or author |> this |> |>> |> |> > document. |> |>> |> |> > |> |>> |> |> > Thanks |> |>> |> |> > |> |>> |> |> > Flemming & Miguel [MMUSIC chairs] |> |>> |> |> > |> |>> |> |> > |> |>> |> |> > _______________________________________________ |> |>> |> |> > 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 |> |>> |> |> _______________________________________________ |> |>> |> |> 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 |> | |> |_______________________________________________ |> |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 ari.keranen@nomadiclab.com Fri Apr 1 05:54:48 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE26A3A6879 for ; Fri, 1 Apr 2011 05:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eXO6RiePEn4 for ; Fri, 1 Apr 2011 05:54:48 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1E8EC3A6876 for ; Fri, 1 Apr 2011 05:54:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id CD8BE4E6DF for ; Fri, 1 Apr 2011 15:56:27 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUr+ktGnPG7s for ; Fri, 1 Apr 2011 15:56:27 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id D405D4E6BD for ; Fri, 1 Apr 2011 15:56:26 +0300 (EEST) Message-ID: <4D95CB84.9050201@nomadiclab.com> Date: Fri, 01 Apr 2011 14:56:36 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE TCP final fixes (and WGLC) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 12:54:49 -0000 Folks, Due to the packed schedule of the WG meeting today, we didn't have time to present the ICE TCP draft. Luckily, we seem to have all our open issues closed and I believe (and everyone I've talked with seems to agree) we're pretty much ready for WGLC. Jonathan Lennox's review pointed out a few small things worth fixing before the WGLC so I'm planning to post a new version containing these fixes (as discussed on that thread) soon. I'll wait a few more days for more comments, so if you have any, please post them now so that they can be addressed before the WGLC too. Cheers, Ari From HKaplan@acmepacket.com Sat Apr 2 05:35:31 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A8D3A67D9 for ; Sat, 2 Apr 2011 05:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOjmNolrlt0c for ; Sat, 2 Apr 2011 05:35:28 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 00FF13A67EB for ; Sat, 2 Apr 2011 05:35:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Sat, 2 Apr 2011 08:37:08 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 2 Apr 2011 08:37:08 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" Date: Sat, 2 Apr 2011 08:37:06 -0400 Thread-Topic: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? Thread-Index: AcvxMq5Igfum4KqARfyi+AYelYYrzA== Message-ID: <66C311BD-618B-4811-B9EE-015280457186@acmepacket.com> References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com><0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058519491729BD@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C65380492020513FC25@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020513FC25@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 12:35:31 -0000 ICE doesn't go through 3GPP systems, and DTLS/SRTP is non-existent in 3GPP = networks. -hadriel On Apr 1, 2011, at 8:12 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > Does 3GPP have similar issues in getting signaling protocols that > operate on the media path (ICE, DTLS etc) though their SBCs? Do they > have any recommendations to make them work better? > > thanks, > Muthu > > |-----Original Message----- > |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |Sent: Friday, April 01, 2011 12:28 PM > |To: Muthu ArulMozhi Perumal (mperumal); Hadriel Kaplan; mmusic > |Subject: RE: [MMUSIC] Continued WG interest > inSDPoffer/answerwithmiddleboxes? > | > |Hi, > | > |>The main goal of the draft as it seems to claim is to > |>describe the desirable behaviors of middleboxes and signaling > |>protocols that operate on the media path, to aid in > |>firewall/NAT traversal. It looks like an extension of RFC > |>3303 whose focus is also firewall and NAT traversal > |>use-cases. The draft claims that the architecture/functions > |>it describes is used in IMS and specified in 3GPP, TISPAN and > |>PacketCable specs -- if it true, then this is where the > |>recommendations in the draft would be useful I think. > | > |3GPP already specifies NAT traversal etc behavior for their "SBCs". > | > |Regards, > | > |Christer > | > |> However, it doesn't look it would be useful for all B2BUA/SBC > |> use-cases/deployments -- if we want to make it, then I think > |> it would be a scope creep. > |> > |> Muthu > |> > |> |-----Original Message----- > |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> Behalf Of Hadriel Kaplan > |> |Sent: Friday, April 01, 2011 5:42 AM > |> |To: mmusic > |> |Subject: Re: [MMUSIC] Continued WG interest inSDP > |> offer/answerwithmiddleboxes? > |> | > |> | > |> |Howdy, > |> |I read the draft, and also found the use of the term "ALG" to be > |> confusing and annoying. It's not > |> |just rfc3303 which defines an ALG as being in a inline/NAT > |> type device > |> - lots of the user market uses > |> |the term ALG for inline type as well. (it's basically a derogatory > |> term) One "SBC" vendor I know of > |> |arguably had a real SIP ALG, but they went defunct years ago. > |> | > |> |Then again, the drawings actually show the SIP-ALG+middlebox not > |> changing the SDP at all, so maybe > |> |they do mean ALG. > |> | > |> |But anyway... I don't mean to sound negative, but what's the > |> purpose of > |> this document? What do we > |> |think it's going to achieve if it's published as an RFC? > |> |The only "output" of this document are four "preliminary > |> recommendations". Of those four, I'd argue > |> |three of them are now wrong or misleading, and the remaining one is > |> unlikely to occur/help. It also > |> |claims to describe the impact on ICE, but doesn't; claims to propose > |> mechanisms to mitigate latching, > |> |but doesn't; doesn't describe the issues with middleboxes > |> and forked or > |> moved calls on early in-band > |> |media signaling; and uses terminology from ancient history (ie, RFC > |> 3303). > |> | > |> |So what's the point of this doc again? > |> | > |> |-hadriel > |> | > |> | > |> | > |> |On Mar 31, 2011, at 10:13 AM, Dan Wing wrote: > |> | > |> |>> -----Original Message----- > |> |>> From: Muthu ArulMozhi Perumal (mperumal) > |> [mailto:mperumal@cisco.com] > |> |>> Sent: Thursday, March 31, 2011 1:01 PM > |> |>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, > |> Keith (Keith); > |> |>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic > |> |>> Subject: RE: [MMUSIC] Continued WG interest in SDP > |> |>> offer/answerwithmiddleboxes? > |> |>> > |> |>> I agree with your interpretation of what an SBC is. However, the > |> reason > |> |>> why I don't find anything wrong in the use of ALG in > |> |>> draft-ietf-mmusic-media-path-middleboxes is because it describes > |> |>> firewall and NAT traversal functions that are typically > |> implemented > |> as > |> |>> ALGs, except that these functions are decoupled into a > |> MIDCOM agent > |> and > |> |>> a middle box. In addition RFC 3303 goes on to say > |> (section 2.8) that > |> |>> MIDCOM agents are entities performing ALG functions, logically > |> external > |> |>> to a middlebox. It even says these agents can reside on a proxy. > |> |>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the > |> ALG > |> |>> in > |> |>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the > |> draft > |> |>> I think. > |> |> > |> |> If Figure 1 was modified to show a NAT or firewall, it could > |> reasonably > |> |> use the term ALG with those devices. > |> |> > |> |> But when showing an SBC, which is smack in the middle of > |> Figure 1, it > |> |> cannot accurately call the SBC a "SIP ALG", as it does right now. > |> |> > |> |> -d > |> |> > |> |> > |> |>> Muthu > |> |>> > |> |>> |-----Original Message----- > |> |>> |From: Dan Wing (dwing) > |> |>> |Sent: Wednesday, March 30, 2011 2:52 PM > |> |>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); > |> |>> 'DRAGE, Keith (Keith)'; 'Christer > |> |>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' > |> |>> |Subject: RE: [MMUSIC] Continued WG interest in SDP > |> |>> offer/answerwithmiddleboxes? > |> |>> | > |> |>> |> -----Original Message----- > |> |>> |> From: Muthu ArulMozhi Perumal (mperumal) > |> [mailto:mperumal@cisco.com] > |> |>> |> Sent: Tuesday, March 29, 2011 3:58 PM > |> |>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer > |> |>> Holmberg; > |> |>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic > |> |>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP > |> |>> |> offer/answerwithmiddleboxes? > |> |>> |> > |> |>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes > is > |> just > |> |>> an > |> |>> |> extension of RFC 3303 -- while the later describes the > |> middlebox > |> |>> |> communication architecture and framework, the former describes > |> some > |> |>> of > |> |>> |> the desirable behaviors of these middleboxes and protocols > that > |> |>> operate > |> |>> |> on the media path unspecified in the later. RFC 3303 defines > |> what > |> |>> an > |> |>> |> ALG is and it doesn't forbid packets being addressed to the > ALG > |> at > |> |>> the > |> |>> |> IP layer. > |> |>> |> > |> |>> |> > |> |>> |> 2.6. ALG > |> |>> |> Application Level Gateways (ALGs) are entities that > |> possess the > |> |>> |> application specific intelligence and knowledge of an > |> associated > |> |>> |> middlebox function. An ALG examines application traffic in > |> transit > |> |>> |> and assists the middlebox in carrying out its function. > |> |>> |> > |> |>> |> ALGs are different from proxies. ALGs are not visible to > |> end-hosts, > |> |>> |> unlike the proxies which are relay agents terminating sessions > |> with > |> |>> |> both end-hosts. ALGs do not terminate sessions with > |> either end- > |> |>> host. > |> |>> |> Instead, ALGs examine, and optionally modify, > |> application payload > |> |>> |> content to facilitate the flow of application traffic > |> through a > |> |>> |> middlebox. > |> |>> |> > |> |>> |> 2.8. MIDCOM Agents > |> |>> |> MIDCOM agents are entities performing ALG functions, logically > |> |>> |> external to a middlebox. > |> |>> |> > |> |>> |> The packets may be addressed to the agent node at the IP > layer. > |> |>> |> Alternatively they may not be addressed to the agent node, but > |> may > |> |>> be > |> |>> |> constrained by other factors to flow through it. > |> |>> |> > |> |>> |> > |> |>> |> So, I don't see anything wrong in the use of ALG in > |> |>> |> draft-ietf-mmusic-media-path-middleboxes, unless we > |> plan to make > |> |>> |> changes to how RFC 3303 describes it. > |> |>> | > |> |>> |3303 is quite clear, in exactly the text you quoted in the > |> paragraph > |> |>> |starting with "ALGs are different from proxies", that > |> ALGs aren't > |> |>> |visible to hosts and ALGs don't terminate sessions. > |> |>> | > |> |>> |An SBC is certainly visible to the end host, for both the SIP > |> |>> |signaling and the RTP media -- the end host is sending > |> packets to > |> |>> |the SBC's IP address and receiving packets from the SBC's IP > |> |>> |address. > |> |>> | > |> |>> |-d > |> |>> | > |> |>> | > |> |>> |> Muthu > |> |>> |> > |> |>> |> |-----Original Message----- > |> |>> |> |From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] > |> On > |> |>> |> Behalf Of Parthasarathi R (partr) > |> |>> |> |Sent: Wednesday, March 16, 2011 6:15 PM > |> |>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing > (dwing); > |> |>> |> Flemming > |> |>> |> Andreasen (fandreas); mmusic > |> |>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP > |> |>> |> offer/answerwithmiddleboxes? > |> |>> |> | > |> |>> |> |Keith, > |> |>> |> | > |> |>> |> |Sorry in case "media" word in my mail mislead you. > |> Dan explains > |> in > |> |>> |> |another mail thread > |> |>> |> > |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) > |> |>> |> why > |> |>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for > |> this > |> |>> |> draft. > |> |>> |> | > |> |>> |> | > |> |>> |> |Fig 1 of > |> draft-ietf-mmusic-media-path-middleboxes-03.txt exactly > |> |>> fits > |> |>> |> |your definition of B2BUA as it involves only SIP & > |> SDP and media > |> is > |> |>> |> |defined as middlebox. > |> |>> |> | > |> |>> |> |I have mentioned as kind of B2BUA because the draft > |> concentrates > |> on > |> |>> |> |callflow where one side of B2BUA acts as UAC and other side > |> always > |> |>> |> acts > |> |>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC > |> |>> callflows > |> |>> |> |specific issues. In the current scope of draft is > |> continued for > |> the > |> |>> |> |draft, the new definition may be required or draft text has > to > |> |>> clarify > |> |>> |> |the scope. > |> |>> |> | > |> |>> |> |Thanks > |> |>> |> |Partha > |> |>> |> | > |> |>> |> |-----Original Message----- > |> |>> |> |From: DRAGE, Keith (Keith) > |> [mailto:keith.drage@alcatel-lucent.com] > |> |>> |> |Sent: Wednesday, March 16, 2011 5:33 PM > |> |>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing > |> (dwing); > |> |>> |> |Flemming Andreasen (fandreas); mmusic > |> |>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP > |> offer/answer > |> |>> |> |withmiddleboxes? > |> |>> |> | > |> |>> |> |The only definition of B2BUA that I know of comes in RFC 3261 > |> (sort > |> |>> |> of) > |> |>> |> |where the scope is limited to SIP. So a UA acts in > |> one or more > |> |>> |> |directions as a SIP UA. Whatever else it does is outside the > |> |>> |> definition. > |> |>> |> |That I believe matches with what Christer is saying. > |> |>> |> | > |> |>> |> |If you want something that defines what it does with > |> media, then > |> |>> you > |> |>> |> |need something that defines that, but using the term > |> B2BUA to do > |> |>> that > |> |>> |> is > |> |>> |> |probably not the best choice. > |> |>> |> | > |> |>> |> |Regards > |> |>> |> | > |> |>> |> |Keith > |> |>> |> | > |> |>> |> |> -----Original Message----- > |> |>> |> |> From: mmusic-bounces@ietf.org > |> [mailto:mmusic-bounces@ietf.org] > |> On > |> |>> |> |> Behalf Of Parthasarathi R (partr) > |> |>> |> |> Sent: 15 March 2011 09:54 > |> |>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen > |> |>> |> |> (fandreas); mmusic > |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP > |> offer/answer > |> |>> with > |> |>> |> |> middleboxes? > |> |>> |> |> > |> |>> |> |> Christer, > |> |>> |> |> > |> |>> |> |> AFAIK, There is no restriction in terms of SIP > |> B2BUA to handle > |> |>> |> |> signaling only and it is upto the implementation to decide. > |> Also, > |> |>> |> this > |> |>> |> | > |> |>> |> |> draft does not have restriction that SIP B2BUA and media > |> server > |> |>> has > |> |>> |> to > |> |>> |> | > |> |>> |> |> be co-exist in the same device. The draft talks about the > |> |>> scenario > |> |>> |> |> wherein SIP B2BUA communicates with media server > |> using Megaco > |> |>> |> (H.248). > |> |>> |> |> > |> |>> |> |> As I mentioned in other mail thread, ALG does not look > |> |>> appropriate > |> |>> |> and > |> |>> |> | > |> |>> |> |> the draft is talking only about the specific type > |> of B2BUA. In > |> |>> real > |> |>> |> |> deployment, Few vendors named these sort of B2BUA > |> as "Session > |> |>> Border > |> |>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as > |> SBC > |> |>> does > |> |>> |> |> lot more. In case there is a need to have different name > for > |> |>> these > |> |>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us > work > |> it > |> |>> out. > |> |>> |> |> > |> |>> |> |> Thanks > |> |>> |> |> Partha > |> |>> |> |> > |> |>> |> |> -----Original Message----- > |> |>> |> |> From: mmusic-bounces@ietf.org > |> [mailto:mmusic-bounces@ietf.org] > |> On > |> |>> |> |> Behalf Of Christer Holmberg > |> |>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM > |> |>> |> |> To: Dan Wing (dwing); Flemming Andreasen > |> (fandreas); 'mmusic' > |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP > |> offer/answer > |> |>> with > |> |>> |> |> middleboxes? > |> |>> |> |> > |> |>> |> |> > |> |>> |> |> Hi Dan, > |> |>> |> |> > |> |>> |> |> In my definition of an ALG packets can be sent > |> directly to its > |> IP > |> |>> |> |> address. > |> |>> |> |> > |> |>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG > |> also > |> |>> |> |> focuses on other things, like media. A SIP ALG > |> contains a SIP > |> |>> B2BUA. > |> |>> |> |> > |> |>> |> |> Regards, > |> |>> |> |> > |> |>> |> |> Christer > |> |>> |> |> > |> |>> |> |> -----Original Message----- > |> |>> |> |> From: mmusic-bounces@ietf.org > |> [mailto:mmusic-bounces@ietf.org] > |> On > |> |>> |> |> Behalf Of Dan Wing > |> |>> |> |> Sent: 15. maaliskuuta 2011 4:39 > |> |>> |> |> To: 'Flemming Andreasen'; 'mmusic' > |> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP > |> offer/answer > |> |>> with > |> |>> |> |> middleboxes ? > |> |>> |> |> > |> |>> |> |> The draft uses the term "SIP ALG", which at least > |> does not fit > |> my > |> |>> |> |> definition of an ALG. An ALG doesn't have packets sent > |> directly > |> |>> to > |> |>> |> |> its IP address; it does its job stealthily without > awareness > |> of > |> |>> one > |> |>> |> |> (or > |> |>> |> |> both) of the sessoin endpoints. In contrast, the function > |> |>> described > |> |>> |> |> in draft-ietf-mmusic-media-path-middleboxes > |> |>> |> |> is different -- packets are always sent to the IP address > of > |> the > |> |>> SIP > |> |>> |> |> "ALG", and packets are sent from the IP address of the SIP > |> "ALG". > |> |>> |> |> This functionality is most often called a "server" > |> |>> |> |> or a "proxy" -- not an ALG. > |> |>> |> |> > |> |>> |> |> This distinction is important because this draft is closely > |> |>> related > |> |>> |> to > |> |>> |> | > |> |>> |> |> functions common in NATs, which _do_ sometimes have > |> SIP ALGs > |> |>> |> |> implemented in them. > |> |>> |> |> > |> |>> |> |> So ... can we change "SIP ALG" to something like "SIP > proxy" > |> |>> |> |> or "SIP user agent" or "SIP Back-to-Back User > |> Agent"? Really, > |> it > |> |>> is > |> |>> |> a > |> |>> |> | > |> |>> |> |> B2BUA, at least as best I understand the definition of a > |> B2BUA, > |> |>> so > |> |>> |> |> B2BUA seems best. > |> |>> |> |> > |> |>> |> |> d > |> |>> |> |> > |> |>> |> |> > |> |>> |> |> > -----Original Message----- > |> |>> |> |> > From: mmusic-bounces@ietf.org > |> [mailto:mmusic-bounces@ietf.org] > |> |>> On > |> |>> |> |> > Behalf Of Flemming Andreasen > |> |>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM > |> |>> |> |> > To: mmusic > |> |>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP > |> offer/answer > |> |>> with > |> |>> |> |> > middleboxes ? > |> |>> |> |> > > |> |>> |> |> > We currently have a MMUSIC milestone for > |> "considerations for > |> |>> using > |> |>> |> |> > SDP > |> |>> |> |> > |> |>> |> |> > offer/answer with middleboxes". The latest draft > |> for this WG > |> |>> item > |> |>> |> is > |> |>> |> |> > > |> |>> |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt > |> |>> |> |> > > |> |>> |> |> > which expired in January 2011. There hasn't been much > |> |>> discussion > |> |>> |> on > |> |>> |> |> > this topic for a while, and the current draft authors are > |> not > |> |>> |> |> > planning > |> |>> |> |> > |> |>> |> |> > continued work on the draft, so we need new authors if we > |> are > |> |>> to > |> |>> |> |> > continue with this WG item. Please let us know if > |> |>> |> |> > 1) You are still interested in this deliverable > |> |>> |> |> > 2) You are willing to actively contribute to and/or > author > |> this > |> |>> |> |> > document. > |> |>> |> |> > > |> |>> |> |> > Thanks > |> |>> |> |> > > |> |>> |> |> > Flemming & Miguel [MMUSIC chairs] > |> |>> |> |> > > |> |>> |> |> > > |> |>> |> |> > _______________________________________________ > |> |>> |> |> > 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 > |> |>> |> |> _______________________________________________ > |> |>> |> |> 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 > |> | > |> |_______________________________________________ > |> |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 ron.even.tlv@gmail.com Sat Apr 2 08:40:12 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECAA28C11D for ; Sat, 2 Apr 2011 08:40:12 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLRHIkoFo+vG for ; Sat, 2 Apr 2011 08:40:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BA51F28C0E7 for ; Sat, 2 Apr 2011 08:40:10 -0700 (PDT) Received: by wyb29 with SMTP id 29so4137677wyb.31 for ; Sat, 02 Apr 2011 08:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=rWaD6VmZNXi9PCvPsbI5L7IEiQTXFT1D6Qo70gIRYpc=; b=J3LxOu0KPGktf5Ii2+OKMcnRb5WTcdyzNMajRBQDvbHJcXPOZxRsAgzPFwZ/LDIWPw QyKLrFifW91xO9WIG0++ib3nH901ZwQHPkbEUprFETbMESq/Z9brI/BtRM/gDdBWs653 J2jiVOY2TBzQv+Uwgweb55N9vi3VAoutnR1eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=dLjtHccGwTgmS0EX2vqj2pOUpRDW810iweGQwUJxkzARjpeMSD0ZknRlHEQUQhqYRT APssGKNFRdXjX8t+Wce+qnF6MGjlamZMzVYIEQSQuAsQAVUxUKuEbzlw1wmMNWTkJm96 lXl24VZgJzoz7bjMhRq/psiRnSdQdj8E4dHk0= Received: by 10.216.161.205 with SMTP id w55mr715868wek.104.1301758911347; Sat, 02 Apr 2011 08:41:51 -0700 (PDT) Received: from windows8d787f9 ([109.66.5.106]) by mx.google.com with ESMTPS id g32sm1473222wej.3.2011.04.02.08.41.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 08:41:49 -0700 (PDT) From: "Roni Even" To: , "'Bert Greevenbosch'" References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> In-Reply-To: <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> Date: Sat, 2 Apr 2011 18:41:05 +0300 Message-ID: <4d9743bd.a08dd80a.7cb3.ffff9446@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvwak484qR4HuPjROCqT0su1YX5KwA4V0eA Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 15:40:12 -0000 Hi, This is why I suggested to create a payload format for it where the payload header will be the directory for the separate streams. This works good if the proposal is to let the answerer select all streams or none at all. My assumption is that all the 3D streams are using the same codec which simplifies the solution. If there is one of the streams that must be used by systems not supporting the multiple m-lines than need to define the offer using media capability negotiation. Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of lennox@cs.columbia.edu > Sent: Friday, April 01, 2011 3:41 PM > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Remarks from today > > On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" > saying: > > > Hi all, > > > > Thank you for your remarks during today's session. Here are the > remarks I received concerning the 3D Format and Parallax Signalling > drafts: > > > [...] > > > > Please let me know if I missed some questions/comments, or if you > have any new questions/comments on the drafts. > > I had one other question I was going to ask, but the line had been > closed. > > What is the backward-compability story here? It seems like a non-3D- > aware > endpoint receiving this SDP message is going to have a lot of problems > understanding what it means. (Remember that in SDP, unknown attributes > are > ignored.) > > Packed frames are obviously the most problematic case here, but even > the > simulcast and auxiliary modes are potentially unappealing. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Mon Apr 4 05:24:08 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A211128C116 for ; Mon, 4 Apr 2011 05:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gODdX0CkMRlA for ; Mon, 4 Apr 2011 05:24:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5C4F828B23E for ; Mon, 4 Apr 2011 05:24:01 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-c4-4d99b8c7f1a7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C5.07.09202.7C8B99D4; Mon, 4 Apr 2011 14:25:43 +0200 (CEST) Received: from [159.107.51.21] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Apr 2011 14:25:42 +0200 Message-ID: <4D99B8C5.2080901@ericsson.com> Date: Mon, 4 Apr 2011 14:25:41 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Magnus Westerlund References: <4D9443CB.7080705@ericsson.com> <4D958511.4040603@ericsson.com> In-Reply-To: <4D958511.4040603@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "DRAGE, Keith \(Keith\)" , mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 12:24:08 -0000 I had a chat with the IANA staff in Prague, and they said that they could create the missing registry from RFC 4566. I can take the action point of making sure the registry is created. Then, there were comments on the list advocating for the creation of a simple I-D adding the missing 'image' media type from RFC 4566. If Gonzalo or someone else can create this draft, we should be able to use to complete our plan. /Miguel On 01/04/2011 9:56, Magnus Westerlund wrote: > Gonzalo Salgueiro skrev 2011-03-31 15:52: >> Almost a year ago Kevin Fleming and I had this discussion. We ran into >> this issue in the course of working with the ITU-T on a SIP Forum FoIP >> TG initiated contribution to T.38. When updating references from RFC >> 2327 to RFC 4566, we came across the fact that in RFC 2327 the >> possible values for the 'media' type are documented as sharing the name >> space with the top-level media content types in the MIME (RFC 2048) >> registry, whereas in RFC 4566 this statement does not appear. RFC 4566 >> does contain language that would appear to include such top-level media >> content types as valid 'media' types in SDP, but also establishes a new >> SDP-specific 'media' type registry. The MIME top-level media content >> registry *does* have a registration for 'image'. As you correctly note, >> IANA does not appear to have >> actually created an SDP media type registry (and populated it with >> the values from RFC 4566). As a result of this we intended to write the >> I-D for consideration by MMUSIC to register the 'image' media type for >> SDP. We'll happily submit this if the group agrees. >> > > Isn't it simpler to just point at the media types registry in general. > Not indicate which of the existing media types that might or might not > be used in SDP. That way you don't have to change the SDP specification > if anyone creates a new top media level type. > > Cheers > > 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 > ---------------------------------------------------------------------- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gsalguei@cisco.com Mon Apr 4 06:42:54 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690B63A69F1 for ; Mon, 4 Apr 2011 06:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8CYL6saH70C for ; Mon, 4 Apr 2011 06:42:48 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id D86CD28C118 for ; Mon, 4 Apr 2011 06:42:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p34DiJx1023015; Mon, 4 Apr 2011 09:44:19 -0400 (EDT) Received: from rtp-gsalguei-8719.cisco.com (rtp-gsalguei-8719.cisco.com [10.116.61.58]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p34DiEma004056; Mon, 4 Apr 2011 09:44:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-128--652574787 From: Gonzalo Salgueiro In-Reply-To: <4D99B8C5.2080901@ericsson.com> Date: Mon, 4 Apr 2011 09:44:15 -0400 Message-Id: References: <4D9443CB.7080705@ericsson.com> <4D958511.4040603@ericsson.com> <4D99B8C5.2080901@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1084) Cc: Magnus Westerlund , "DRAGE, Keith \(Keith\)" , mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 13:42:54 -0000 --Apple-Mail-128--652574787 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Miguel - I'll get it submitted very soon. Gonzalo On Apr 4, 2011, at 8:25 AM, Miguel A. Garcia wrote: > I had a chat with the IANA staff in Prague, and they said that they = could create the missing registry from RFC 4566. I can take the action = point of making sure the registry is created. >=20 > Then, there were comments on the list advocating for the creation of a = simple I-D adding the missing 'image' media type from RFC 4566. If = Gonzalo or someone else can create this draft, we should be able to use = to complete our plan. >=20 > /Miguel >=20 > On 01/04/2011 9:56, Magnus Westerlund wrote: >> Gonzalo Salgueiro skrev 2011-03-31 15:52: >>> Almost a year ago Kevin Fleming and I had this discussion. We ran = into >>> this issue in the course of working with the ITU-T on a SIP Forum = FoIP >>> TG initiated contribution to T.38. When updating references from RFC >>> 2327 to RFC 4566, we came across the fact that in RFC 2327 the >>> possible values for the 'media' type are documented as sharing the = name >>> space with the top-level media content types in the MIME (RFC 2048) >>> registry, whereas in RFC 4566 this statement does not appear. RFC = 4566 >>> does contain language that would appear to include such top-level = media >>> content types as valid 'media' types in SDP, but also establishes a = new >>> SDP-specific 'media' type registry. The MIME top-level media content >>> registry *does* have a registration for 'image'. As you correctly = note, >>> IANA does not appear to have >>> actually created an SDP media type registry (and populated it with >>> the values from RFC 4566). As a result of this we intended to write = the >>> I-D for consideration by MMUSIC to register the 'image' media type = for >>> SDP. We'll happily submit this if the group agrees. >>>=20 >>=20 >> Isn't it simpler to just point at the media types registry in = general. >> Not indicate which of the existing media types that might or might = not >> be used in SDP. That way you don't have to change the SDP = specification >> if anyone creates a new top media level type. >>=20 >> Cheers >>=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 >> = ---------------------------------------------------------------------- >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain --Apple-Mail-128--652574787 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I had = a chat with the IANA staff in Prague, and they said that they could = create the missing registry from RFC 4566. I can take the action point = of making sure the registry is created.

Then, there were comments = on the list advocating for the creation of a simple I-D adding the = missing 'image' media type from RFC 4566. If Gonzalo or someone else can = create this draft, we should be able to use to complete our = plan.

/Miguel

On 01/04/2011 9:56, Magnus Westerlund = wrote:
Gonzalo Salgueiro skrev 2011-03-31 = 15:52:
Almost a year ago Kevin Fleming and I had this discussion. = We ran into
this issue in the course of = working with the ITU-T on a SIP Forum = FoIP
TG initiated contribution to T.38. When updating = references from RFC
2327  to RFC 4566, we came = across the fact that in RFC 2327 = the
possible values for the 'media' type are documented as = sharing the name
space with the top-level media = content types in the MIME (RFC = 2048)
registry, whereas in RFC 4566 this statement does not = appear. RFC 4566
does contain language that would = appear to include such top-level = media
content types as valid 'media' types in SDP, but also = establishes a new
SDP-specific 'media' type = registry. The MIME top-level media = content
registry *does* have a registration for 'image'. As you = correctly note,
IANA does not appear to = have
actually created an SDP media type registry (and populated = it with
the values from RFC 4566). As a result of this we = intended to write the
I-D for consideration by MMUSIC = to register the 'image' media type = for
SDP. We'll happily submit this if the group = agrees.


Isn't it = simpler to just point at the media types registry in = general.
Not indicate which of = the existing media types that might or might = not
be used in SDP. That way = you don't have to change the SDP = specification
if anyone = creates a new top media level type.

Cheers

Magnus = Westerlund

------------------------------------------------------------= ----------
Multimedia = Technologies, Ericsson Research EAB/TVM
------------------------------------------------------------= ----------
Ericsson AB =             &n= bsp;  | Phone  +46 10 7148287
F=E4r=F6gatan 6 =             &n= bsp;  | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.= com
------------------------------------------------------------= ----------
_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.org= /mailman/listinfo/mmusic


--
Miguel A. = Garcia
+34-91-339-3608
Ericsson = Spain

= --Apple-Mail-128--652574787-- From ron.even.tlv@gmail.com Mon Apr 4 08:33:10 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7959B28C100 for ; Mon, 4 Apr 2011 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO-IZbJ-RkQH for ; Mon, 4 Apr 2011 08:33:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 775663A69FA for ; Mon, 4 Apr 2011 08:33:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so5370796wyb.31 for ; Mon, 04 Apr 2011 08:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=+PXootv/qqoqivGiERxasJsaLmp3hdSNG0vBlqXAnRo=; b=skr9Rn+7RB3+WiBSUchZDdkl1yGyYeDr9b+Lh47g5FW0IQ213Q3Ea/HAQptgIBlUlG xdCZPo9+vaSrcllHEgApoPCpNGonEL6Z7TVKU/0n5vYyKfNqXW6H4AckhRDD7OhTUsgE lP2lGc+0mIP637O7NecAmG9bthc9t9mIbI8UU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=ZpPn0CUszxIezYFLDPKwvKbxGxVns5cdXLf04l5WRaHl9ph/JHIb4UAbsQK/CmgYOA 4YGSCdqU+Ln7UDBzZXBg8RjfKpWK3BxH0DEjg1KYY4Jv/OZ+GkVd4K2PmCbaCVgkrvKE g3p7qYFjy/UIdohHDJRqkN+xOb3Olcd9xTQhc= Received: by 10.216.144.166 with SMTP id n38mr3949350wej.75.1301931282378; Mon, 04 Apr 2011 08:34:42 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-1-169.red.bezeqint.net [79.182.1.169]) by mx.google.com with ESMTPS id l24sm2982692wbc.30.2011.04.04.08.34.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 08:34:40 -0700 (PDT) From: "Roni Even" To: "'Gonzalo Salgueiro'" , "'Miguel A. Garcia'" References: <4D9443CB.7080705@ericsson.com> <4D958511.4040603@ericsson.com> <4D99B8C5.2080901@ericsson.com> In-Reply-To: Date: Mon, 4 Apr 2011 18:33:34 +0300 Message-ID: <4d99e510.581ce30a.45c2.fffff842@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0133_01CBF2F6.D03C4B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvyzniOh/07HEm8Q6WrfWgS5mn0GwADeEeA Content-Language: en-us Cc: 'Magnus Westerlund' , "'DRAGE, Keith \(Keith\)'" , 'mmusic' Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 15:33:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0133_01CBF2F6.D03C4B00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0134_01CBF2F6.D03C4B00" ------=_NextPart_001_0134_01CBF2F6.D03C4B00 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This issue was discussed in 2005. Attached are some emails Roni =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Gonzalo Salgueiro Sent: Monday, April 04, 2011 4:44 PM To: Miguel A. Garcia Cc: Magnus Westerlund; DRAGE, Keith (Keith); mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP =20 Miguel - =20 I'll get it submitted very soon. =20 Gonzalo =20 =20 On Apr 4, 2011, at 8:25 AM, Miguel A. Garcia wrote: I had a chat with the IANA staff in Prague, and they said that they = could create the missing registry from RFC 4566. I can take the action point = of making sure the registry is created. Then, there were comments on the list advocating for the creation of a simple I-D adding the missing 'image' media type from RFC 4566. If = Gonzalo or someone else can create this draft, we should be able to use to = complete our plan. /Miguel On 01/04/2011 9:56, Magnus Westerlund wrote: Gonzalo Salgueiro skrev 2011-03-31 15:52: Almost a year ago Kevin Fleming and I had this discussion. We ran into this issue in the course of working with the ITU-T on a SIP Forum FoIP TG initiated contribution to T.38. When updating references from RFC 2327 to RFC 4566, we came across the fact that in RFC 2327 the possible values for the 'media' type are documented as sharing the name space with the top-level media content types in the MIME (RFC 2048) registry, whereas in RFC 4566 this statement does not appear. RFC 4566 does contain language that would appear to include such top-level media content types as valid 'media' types in SDP, but also establishes a new SDP-specific 'media' type registry. The MIME top-level media content registry *does* have a registration for 'image'. As you correctly note, IANA does not appear to have actually created an SDP media type registry (and populated it with the values from RFC 4566). As a result of this we intended to write the I-D for consideration by MMUSIC to register the 'image' media type for SDP. We'll happily submit this if the group agrees. =20 =20 Isn't it simpler to just point at the media types registry in general. Not indicate which of the existing media types that might or might not be used in SDP. That way you don't have to change the SDP specification if anyone creates a new top media level type. =20 Cheers =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 ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 --=20 Miguel A. Garcia +34-91-339-3608 Ericsson Spain =20 ------=_NextPart_001_0134_01CBF2F6.D03C4B00 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

This issue was discussed in 2005. Attached are some = emails

Roni

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Gonzalo Salgueiro
Sent: Monday, April 04, 2011 4:44 = PM
To: Miguel A. Garcia
Cc: Magnus Westerlund; = DRAGE, Keith (Keith); mmusic
Subject: Re: [MMUSIC] IANA = registration of the "image" media type in = SDP

 

Miguel = -

 

I'll = get it submitted very soon.

 

Gonzalo

 

 

On = Apr 4, 2011, at 8:25 AM, Miguel A. Garcia wrote:



I had = a chat with the IANA staff in Prague, and they said that they could = create the missing registry from RFC 4566. I can take the action point = of making sure the registry is created.

Then, there were comments = on the list advocating for the creation of a simple I-D adding the = missing 'image' media type from RFC 4566. If Gonzalo or someone else can = create this draft, we should be able to use to complete our = plan.

/Miguel

On 01/04/2011 9:56, Magnus Westerlund = wrote:

Gonzalo Salgueiro = skrev 2011-03-31 15:52:

Almost a year ago Kevin Fleming and I had this = discussion. We ran = into

this = issue in the course of working with the ITU-T on a SIP Forum = FoIP

TG = initiated contribution to T.38. When updating references from = RFC

2327 =  to RFC 4566, we came across the fact that in RFC 2327 = the

possible values for the 'media' type are documented as = sharing the name

space with the top-level media content types in the = MIME (RFC 2048)

registry, whereas in RFC 4566 this statement does not = appear. RFC 4566

does = contain language that would appear to include such top-level = media

content types as valid 'media' types in SDP, but also = establishes a new

SDP-specific 'media' type registry. The MIME top-level = media content

registry *does* have a registration for 'image'. As = you correctly note,

IANA = does not appear to = have

actually created an SDP media type registry (and = populated it with

the = values from RFC 4566). As a result of this we intended to write = the

I-D = for consideration by MMUSIC to register the 'image' media type = for

SDP. = We'll happily submit this if the group = agrees.

 

 

Isn't it simpler to just point at the media types = registry in general.

Not = indicate which of the existing media types that might or might = not

be = used in SDP. That way you don't have to change the SDP = specification

if = anyone creates a new top media level = type.

 

Cheers

 

Magnus = Westerlund

 

-------------------------------------------------------= ---------------

Multimedia Technologies, Ericsson Research = EAB/TVM

-------------------------------------------------------= ---------------

Ericsson AB =             &= nbsp;  | Phone  +46 10 = 7148287

F=E4r=F6gatan 6 =             &= nbsp;  | Mobile +46 73 = 0949079

SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson= .com

-------------------------------------------------------= ---------------

_______________________________________________

mmusic mailing = list

mmusic@ietf.org

https://www.ietf.or= g/mailman/listinfo/mmusic

 


--
Miguel A. = Garcia
+34-91-339-3608
Ericsson Spain

 

------=_NextPart_001_0134_01CBF2F6.D03C4B00-- ------=_NextPart_000_0133_01CBF2F6.D03C4B00 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcg3-0002Oc-6k for mmusic@megatron.ietf.org; Tue, 10 May 2005 17:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcg4-0002Oh-Fj; Tue, 10 May 2005 17:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25145 for ; Tue, 10 May 2005 17:54:04 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61075 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1DVcfj-0003uw-Lu; Tue, 10 May 2005 22:53:47 +0100 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcvQ-0002E9-PU for mmusic@ietf.org; Tue, 10 May 2005 18:10:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mailrelay with InterScan Messaging Security Suite; Wed, 11 May 2005 01:01:50 +0300 Received: from mailrelay ([212.179.41.34]) by isrexch01.israel.polycom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 00:57:36 +0300 Received: from mailrelay ([212.179.41.34]) by mailrelay with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 May 2005 01:01:51 +0300 From: "Colin Perkins" Sender: To: "Belling Thomas" Cc: Subject: Re: [MMUSIC] Media types in SDP new Date: Wed, 11 May 2005 00:53:43 +0300 Message-ID: <9bf8a6e7a49c7e00295e902ee53b70ce@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcVVq0ceJzNX4OQ4TLObirBb2aUfKQ== List-Unsubscribe: , List-Help: List-Subscribe: , Content-Language: en-us On 3 May 2005, at 17:42, Belling Thomas wrote: > perhaps the issue was not discussed as much as I thought. ... > =A0 > In any case, the media type image seems to be missing. > Read standard track RFC 3362 "Real-time Facsimile (T.38) - image/t38=20 > MIME Sub-type Registration" > =A0 > "=A0=A0 This document describes the registration of the MIME sub-type > =A0=A0 image/t38.=A0 The encoding is defined by [T.38] and is intended = for=20 > use > =A0=A0 as an SDP media descriptor." > > May I therefore request that "image" is added as media type in the=20 > next version of draft-ietf-mmusic-sdp-new? The revised SDP specification is with the IESG, and it's too late to=20 change it. If you wish to register the image media type for use with=20 SDP, you'll need to write it up as a separate draft, which we'll=20 progress in the usual manner. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_0133_01CBF2F6.D03C4B00 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDLZ-0006oM-Sb; Tue, 31 May 2005 16:28:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDLb-0006pF-M8; Tue, 31 May 2005 16:28:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28014; Tue, 31 May 2005 16:28:19 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62214 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1DdDLN-0005kA-5d; Tue, 31 May 2005 21:28:09 +0100 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdDfF-0004Ok-2U; Tue, 31 May 2005 16:48:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mailrelay with InterScan Messaging Security Suite; Tue, 31 May 2005 23:34:40 +0300 Received: from mailrelay ([212.179.41.34]) by isrexch01.israel.polycom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 23:34:59 +0300 Received: from mailrelay ([212.179.41.34]) by mailrelay with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 May 2005 23:34:42 +0300 From: "Colin Perkins" Sender: To: "IETF MMUSIC working group" Cc: "Jon Peterson" , "Allison Mankin" Subject: [MMUSIC] Fwd: I-D ACTION:draft-iesg-media-type-00.txt Date: Tue, 31 May 2005 23:28:04 +0300 Message-ID: <6263335E-82C7-4C9C-95F6-D40DD3194E83@csperkins.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_012D_01CBF2F6.D03A0110" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcVmIDcgVppwPRT1TWGOwVjjVsedoA== List-Unsubscribe: , List-Help: List-Subscribe: , Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_012D_01CBF2F6.D03A0110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_012E_01CBF2F6.D03A0110" ------=_NextPart_001_012E_01CBF2F6.D03A0110 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This is directly relevant to both AVT and MMUSIC, and relates to how RTP payload formats are named in SDP signalling. Since this is primarily a signalling issue, discussion on the MMUSIC list (or the main ietf@ietf.org list). Colin Begin forwarded message: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A question on Media Type Registrations Author(s) : T. Hardie Filename : draft-iesg-media-type-00.txt Pages : 9 Date : 2005-5-31 This document poses a question to the community on the future of the IANA Media Type Registry. It presents three potential future courses of development and asks that feedback on these be provided to the IESG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iesg-media-type-00.txt ------=_NextPart_001_012E_01CBF2F6.D03A0110 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable This is directly relevant to = both AVT and MMUSIC, and relates to how RTP payload formats are named in = SDP signalling. Since this is primarily a signalling issue, discussion = on the MMUSIC list (or the main ietf@ietf.org list).

Colin


Begin forwarded = message:
A New Internet-Draft is = available from the on-line Internet-Drafts = directories.

=A0 =A0 Title=A0 =A0 =A0 =A0 : A = question on Media Type Registrations
=A0 =A0 Author(s)=A0 =A0 = : T. Hardie
=A0 =A0 Filename=A0 =A0 : = draft-iesg-media-type-00.txt
=A0 =A0 Pages=A0 =A0 =A0 =A0 : = 9
=A0 =A0 Date=A0 =A0 =A0 =A0 : 2005-5-31
=A0=A0 = =A0
This document poses = a question to the community on the future of the
=A0=A0 IANA = Media Type Registry.=A0 It presents three potential future = courses
=A0=A0 of development and asks that feedback on these = be provided to the
=A0=A0 IESG.

A URL = for this Internet-Draft is:
------=_NextPart_001_012E_01CBF2F6.D03A0110-- ------=_NextPart_000_012D_01CBF2F6.D03A0110 Content-Type: text/plain; name="ATT1348489.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT1348489.txt" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_012D_01CBF2F6.D03A0110-- ------=_NextPart_000_0133_01CBF2F6.D03C4B00-- From fandreas@cisco.com Mon Apr 4 18:55:22 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D8E3A6821 for ; Mon, 4 Apr 2011 18:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P60bUmQKaAE for ; Mon, 4 Apr 2011 18:55:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AF2223A6840 for ; Mon, 4 Apr 2011 18:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=8275; q=dns/txt; s=iport; t=1301968623; x=1303178223; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tRwLOp9Ha9HQIsejCYcBwAI4v1m5GD946G0QH9Ck4R8=; b=IMZBeTq28GwnqNHKEgqyMrFuoW/QHUQnah+QHLi0Rif1ksqZ2YYeHPGa 3KQxmJNpcIiFdSuClqly3SyKCBYwCJDeQVvm+h/IXvtV8RBsxE1y5r2nV c785Bpx/hO7mvcNahBzT41OXSrxwVeWfoHfcmuLVQNPpIL4UeXsDfHw92 A=; X-IronPort-AV: E=Sophos;i="4.63,300,1299456000"; d="scan'208,217";a="228669778" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2011 01:57:02 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p351v1Gu006852; Tue, 5 Apr 2011 01:57:02 GMT Message-ID: <4D9A76EE.5000607@cisco.com> Date: Mon, 04 Apr 2011 21:57:02 -0400 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: Magnus Westerlund References: <4D9443CB.7080705@ericsson.com> <4D958511.4040603@ericsson.com> In-Reply-To: <4D958511.4040603@ericsson.com> Content-Type: multipart/alternative; boundary="------------010001080304090907070500" Cc: Colin Perkins , "DRAGE, Keith \(Keith\)" , mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 01:55:22 -0000 This is a multi-part message in MIME format. --------------010001080304090907070500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 4/1/11 3:56 AM, Magnus Westerlund wrote: > > Gonzalo Salgueiro skrev 2011-03-31 15:52: > > Almost a year ago Kevin Fleming and I had this discussion. We ran into > > this issue in the course of working with the ITU-T on a SIP Forum FoIP > > TG initiated contribution to T.38. When updating references from RFC > > 2327 to RFC 4566, we came across the fact that in RFC 2327 the > > possible values for the 'media' type are documented as sharing the name > > space with the top-level media content types in the MIME (RFC 2048) > > registry, whereas in RFC 4566 this statement does not appear. RFC 4566 > > does contain language that would appear to include such top-level media > > content types as valid 'media' types in SDP, but also establishes a new > > SDP-specific 'media' type registry. The MIME top-level media content > > registry *does* have a registration for 'image'. As you correctly note, > > IANA does not appear to have > > actually created an SDP media type registry (and populated it with > > the values from RFC 4566). As a result of this we intended to write the > > I-D for consideration by MMUSIC to register the 'image' media type for > > SDP. We'll happily submit this if the group agrees. > > > > Isn't it simpler to just point at the media types registry in general. > Not indicate which of the existing media types that might or might not > be used in SDP. > I was thinking the same thing, but there is the question of the "control" and "data" media types in the original SDP spec (RFC 2327) as noted in RFC 4566 and pointed out by Colin. Note that in the other direction, we also have more media types than currently defined in SDP (e.g. "multipart"). It would also be a change to RFC 4566, that effectively undoes a change from RFC 2327. Maybe Colin can clarify further, but in looking closer at RFC 4566 Section 5.14, and more specifically the text for the part, there is text saying that media type registrations should define the packet format when the transport is UDP. In other words, there are additional considerations above and beyond the media type registration procedure from RFC 4288 as far as I can tell. > That way you don't have to change the SDP specification > if anyone creates a new top media level type. > We don't need to change the SDP specification, but we do need to add a new registration to the SDP media types registry. Considering that top-level media types don't appear too often, that does seem manageable. Thanks -- Flemming [as an individual] > Cheers > > 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 > ---------------------------------------------------------------------- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------010001080304090907070500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 4/1/11 3:56 AM, Magnus Westerlund wrote:
Re: [MMUSIC] IANA registration of the "image" media type in SDP

Gonzalo Salgueiro skrev 2011-03-31 15:52:
> Almost a year ago Kevin Fleming and I had this discussion. We ran into
> this issue in the course of working with the ITU-T on a SIP Forum FoIP
> TG initiated contribution to T.38. When updating references from RFC
> 2327  to RFC 4566, we came across the fact that in RFC 2327 the
> possible values for the 'media' type are documented as sharing the name
> space with the top-level media content types in the MIME (RFC 2048)
> registry, whereas in RFC 4566 this statement does not appear. RFC 4566
> does contain language that would appear to include such top-level media
> content types as valid 'media' types in SDP, but also establishes a new
> SDP-specific 'media' type registry. The MIME top-level media content
> registry *does* have a registration for 'image'. As you correctly note,
> IANA does not appear to have
> actually created an SDP media type registry (and populated it with
> the values from RFC 4566). As a result of this we intended to write the
> I-D for consideration by MMUSIC to register the 'image' media type for
> SDP. We'll happily submit this if the group agrees.
>

Isn't it simpler to just point at the media types registry in general.
Not indicate which of the existing media types that might or might not
be used in SDP.

I was thinking the same thing, but there is the question of the "control" and "data" media types in the original SDP spec (RFC 2327) as noted in RFC 4566 and pointed out by Colin. Note that in the other direction, we also have more media types than currently defined in SDP (e.g. "multipart"). It would also be a change to RFC 4566, that effectively undoes a change from RFC 2327.

Maybe Colin can clarify further, but in looking closer at RFC 4566 Section 5.14, and more specifically the text for the <fmt> part, there is text saying that media type registrations should define the packet format when the transport is UDP. In other words, there are additional considerations above and beyond the media type registration procedure from RFC 4288 as far as I can tell.


That way you don't have to change the SDP specification
if anyone creates a new top media level type.

We don't need to change the SDP specification, but we do need to add a new registration to the SDP media types registry. Considering that top-level media types don't appear too often, that does seem manageable.

Thanks

-- Flemming [as an individual]




Cheers

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
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------010001080304090907070500-- From magnus.westerlund@ericsson.com Tue Apr 5 02:12:52 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D24128C0EA for ; Tue, 5 Apr 2011 02:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paHOI83pfHiB for ; Tue, 5 Apr 2011 02:12:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 400F93A68F8 for ; Tue, 5 Apr 2011 02:12:45 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-de-4d9add73947b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BE.E6.09202.37DDA9D4; Tue, 5 Apr 2011 11:14:27 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 5 Apr 2011 11:14:26 +0200 Message-ID: <4D9ADD72.4050404@ericsson.com> Date: Tue, 5 Apr 2011 11:14:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Flemming Andreasen References: <4D9443CB.7080705@ericsson.com> <4D958511.4040603@ericsson.com> <4D9A76EE.5000607@cisco.com> In-Reply-To: <4D9A76EE.5000607@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Colin Perkins , "DRAGE, Keith \(Keith\)" , mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 09:12:52 -0000 Hi, If we want to be clear on which top level media types that are possible in SDP, then I agree that we should have a registry that indicates the ones that the WG has considered and find to work. Cheers Magnus Flemming Andreasen skrev 2011-04-05 03:57: > > > On 4/1/11 3:56 AM, Magnus Westerlund wrote: >> >> Gonzalo Salgueiro skrev 2011-03-31 15:52: >> > Almost a year ago Kevin Fleming and I had this discussion. We ran into >> > this issue in the course of working with the ITU-T on a SIP Forum FoIP >> > TG initiated contribution to T.38. When updating references from RFC >> > 2327 to RFC 4566, we came across the fact that in RFC 2327 the >> > possible values for the 'media' type are documented as sharing the name >> > space with the top-level media content types in the MIME (RFC 2048) >> > registry, whereas in RFC 4566 this statement does not appear. RFC 4566 >> > does contain language that would appear to include such top-level media >> > content types as valid 'media' types in SDP, but also establishes a new >> > SDP-specific 'media' type registry. The MIME top-level media content >> > registry *does* have a registration for 'image'. As you correctly note, >> > IANA does not appear to have >> > actually created an SDP media type registry (and populated it with >> > the values from RFC 4566). As a result of this we intended to write the >> > I-D for consideration by MMUSIC to register the 'image' media type for >> > SDP. We'll happily submit this if the group agrees. >> > >> >> Isn't it simpler to just point at the media types registry in general. >> Not indicate which of the existing media types that might or might not >> be used in SDP. >> > I was thinking the same thing, but there is the question of the > "control" and "data" media types in the original SDP spec (RFC 2327) as > noted in RFC 4566 and pointed out by Colin. Note that in the other > direction, we also have more media types than currently defined in SDP > (e.g. "multipart"). It would also be a change to RFC 4566, that > effectively undoes a change from RFC 2327. > > Maybe Colin can clarify further, but in looking closer at RFC 4566 > Section 5.14, and more specifically the text for the part, there > is text saying that media type registrations should define the packet > format when the transport is UDP. In other words, there are additional > considerations above and beyond the media type registration procedure > from RFC 4288 as far as I can tell. > > >> That way you don't have to change the SDP specification >> if anyone creates a new top media level type. >> > We don't need to change the SDP specification, but we do need to add a > new registration to the SDP media types registry. Considering that > top-level media types don't appear too often, that does seem manageable. > > Thanks > > -- Flemming [as an individual] > > > > >> Cheers >> >> 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 >> ---------------------------------------------------------------------- >> _______________________________________________ >> 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 sato652@oki.com Tue Apr 5 23:20:50 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D4D3A689E for ; Tue, 5 Apr 2011 23:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzxD3qCnj05J for ; Tue, 5 Apr 2011 23:20:49 -0700 (PDT) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by core3.amsl.com (Postfix) with ESMTP id BF6EC3A688C for ; Tue, 5 Apr 2011 23:20:48 -0700 (PDT) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id D479BCF9C4; Wed, 6 Apr 2011 15:22:34 +0900 (JST) Received: from s111h121.dm1.oii.oki.co.jp [172.26.101.121] by gwf1.oki.co.jp with ESMTP id RAA04471; Wed, 6 Apr 2011 15:22:34 +0900 Received: from s111h121.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B9E3E39800B; Wed, 6 Apr 2011 15:22:31 +0900 (JST) Received: from s24c40.dm1.oii.oki.co.jp (s24c40.dm1.oii.oki.co.jp [172.26.76.90]) by s111h121.dm1.oii.oki.co.jp (Postfix) with ESMTP id A6AB239800A; Wed, 6 Apr 2011 15:22:31 +0900 (JST) Received: from PC26276 (wl10.kansai.oki.co.jp [10.173.11.10]) by s24c40.dm1.oii.oki.co.jp (Postfix) with ESMTP id 7559E25F6CE; Wed, 6 Apr 2011 15:22:31 +0900 (JST) From: "Noriyuki SATO" To: "'Gonzalo Salgueiro'" , "'Miguel A. Garcia'" References: <4D9443CB.7080705@ericsson.com> <4D958511.4040603@ericsson.com> <4D99B8C5.2080901@ericsson.com> Date: Wed, 6 Apr 2011 15:22:31 +0900 Message-ID: <84CA19EB6F714624960DB25ACEA338B6@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcvyznMxwXV9IYjGQWm54y8QZncvqwBUwLBw x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: 'Magnus Westerlund' , "'DRAGE, Keith \(Keith\)'" , 'mmusic' Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 06:20:50 -0000 Hi Gonzalo and MMUSIC chairs, On behalf of CIAJ folks - we expect and support this work. Thanks! --- OKI Electric Industry Co., Ltd. Noriyuki Sato (sato652@oki.com) Tel +81-6-6260-0700 Fax +81-6-6260-0770 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of > Gonzalo Salgueiro > Sent: Monday, April 04, 2011 10:44 PM > To: Miguel A. Garcia > Cc: Magnus Westerlund; DRAGE, Keith (Keith); mmusic > Subject: Re: [MMUSIC] IANA registration of the "image" media type in = SDP >=20 > Miguel - >=20 > I'll get it submitted very soon. >=20 > Gonzalo >=20 >=20 > On Apr 4, 2011, at 8:25 AM, Miguel A. Garcia wrote: >=20 >=20 > I had a chat with the IANA staff in Prague, and they said that they > could create the missing registry from RFC 4566. I can take the action point > of making sure the registry is created. >=20 > Then, there were comments on the list advocating for the creation of > a simple I-D adding the missing 'image' media type from RFC 4566. If Gonzalo > or someone else can create this draft, we should be able to use to complete > our plan. >=20 > /Miguel >=20 > On 01/04/2011 9:56, Magnus Westerlund wrote: >=20 >=20 > Gonzalo Salgueiro skrev 2011-03-31 15:52: >=20 >=20 > Almost a year ago Kevin Fleming and I had this > discussion. We ran into >=20 >=20 > this issue in the course of working with the ITU-T > on a SIP Forum FoIP >=20 >=20 > TG initiated contribution to T.38. When updating > references from RFC >=20 >=20 > 2327 to RFC 4566, we came across the fact that in > RFC 2327 the >=20 >=20 > possible values for the 'media' type are documented > as sharing the name >=20 >=20 > space with the top-level media content types in the > MIME (RFC 2048) >=20 >=20 > registry, whereas in RFC 4566 this statement does > not appear. RFC 4566 >=20 >=20 > does contain language that would appear to include > such top-level media >=20 >=20 > content types as valid 'media' types in SDP, but also > establishes a new >=20 >=20 > SDP-specific 'media' type registry. The MIME > top-level media content >=20 >=20 > registry *does* have a registration for 'image'. As > you correctly note, >=20 >=20 > IANA does not appear to have >=20 >=20 > actually created an SDP media type registry (and > populated it with >=20 >=20 > the values from RFC 4566). As a result of this we > intended to write the >=20 >=20 > I-D for consideration by MMUSIC to register the > 'image' media type for >=20 >=20 > SDP. We'll happily submit this if the group agrees. >=20 >=20 >=20 >=20 > Isn't it simpler to just point at the media types registry > in general. >=20 >=20 > Not indicate which of the existing media types that might or > might not >=20 >=20 > be used in SDP. That way you don't have to change the SDP > specification >=20 >=20 > if anyone creates a new top media level type. >=20 >=20 >=20 > Cheers >=20 >=20 >=20 > Magnus Westerlund >=20 >=20 >=20 >=20 > ----------------------------------------------------------------- > ----- >=20 >=20 > Multimedia Technologies, Ericsson Research EAB/TVM >=20 >=20 >=20 > ----------------------------------------------------------------- > ----- >=20 >=20 > Ericsson AB | Phone +46 10 7148287 >=20 >=20 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 >=20 >=20 > SE-164 80 Stockholm, Sweden| mailto: > magnus.westerlund@ericsson.com >=20 >=20 >=20 > ----------------------------------------------------------------- > ----- >=20 >=20 > _______________________________________________ >=20 >=20 > mmusic mailing list >=20 >=20 > mmusic@ietf.org >=20 >=20 > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain >=20 >=20 From mperumal@cisco.com Wed Apr 6 03:29:27 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA843A6902 for ; Wed, 6 Apr 2011 03:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owrAYkJZc0V4 for ; Wed, 6 Apr 2011 03:29:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2A75C3A68FE for ; Wed, 6 Apr 2011 03:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3670; q=dns/txt; s=iport; t=1302085870; x=1303295470; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=H0viAq1qr5Nmf1jW1He2Md2bAxLnq5Ni4Cz46TCc4HA=; b=IMzi1UYKHLSa/TYMDrdKSXG7h5H71MxmstWb1brpJkCUBB/VRnjzKEw7 0Ihc65zk6x1uv4Njr7D/0qNA1LkGlSFh/kJPMlt2hUYWQdwsgtg25T0mg +e9mDEIB2aClJVPz0xJ54Sa6mwGKsSIXLlh4yjMT2aYX7fSdfOZ0I0GWk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAIdAnE2Q/khLgWdsb2JhbACYLI1LFAEBFiYlpH+cH4VsBIVMi1k X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="82398661" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2011 10:31:09 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36AV7II006467; Wed, 6 Apr 2011 10:31:08 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 16:01:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 16:01:03 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020523BA1A@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? Thread-Index: AcvwZpf2DAHHvwOGRNGc8htfEXoaqQD2t3mQ References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com> <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 06 Apr 2011 10:31:07.0022 (UTC) FILETIME=[BCF402E0:01CBF445] Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 10:29:27 -0000 |When you say "to aid in firewall/NAT traversal", I assume=20 |you mean when the SIP+middlebox device *is* the firewall/NAT,=20 |right? You do NOT mean when a SIP+middlebox device is out in=20 |the network, helping the UA traverse a Firewall/NAT in-between=20 |it and the UA? (what is normally called "Hosted NAT Traversal"=20 |or "Far-end NAT traversal" by vendors) Yes, primarily the former use-case. However, the draft also described the later (see section 5). |I ask because the former case of being the NAT is not the same |as the latter case. Latching and most of the policies described |in this draft do not typically apply to the former case, but do=20 |to the latter. The draft does make this clear in section 5.1: If the middlebox supports the traversal of residential NATs, it applies a technique called "media latching": The destination IP address of packets forwarded by the middlebox in the outbound direction is derived from the source IP address of packets received in the inbound direction. This overrides a destination address possibly configured by the MIDCOM agent. Overall, IMHO the recommendations in the draft seem useful to the kind of architecture/problems it describes. However, whether it applies to current deployments is something I am not sure. The draft claims such middleboxes are for instance the TISPAN A-BGF/C-BGF/I-BGF and the 3GPP IMS Access Gateway..perhaps this was long ago? Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Friday, April 01, 2011 5:46 PM |To: Muthu ArulMozhi Perumal (mperumal) |Cc: mmusic |Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? | | |On Mar 31, 2011, at 10:48 PM, Muthu ArulMozhi Perumal (mperumal) wrote: | |> The main goal of the draft as it seems to claim is to describe the |> desirable behaviors of middleboxes and signaling protocols that operate |> on the media path, to aid in firewall/NAT traversal. It looks like an |> extension of RFC 3303 whose focus is also firewall and NAT traversal |> use-cases. The draft claims that the architecture/functions it describes |> is used in IMS and specified in 3GPP, TISPAN and PacketCable specs -- if |> it true, then this is where the recommendations in the draft would be |> useful I think. | |When you say "to aid in firewall/NAT traversal", I assume you mean when the SIP+middlebox device *is* |the firewall/NAT, right? You do NOT mean when a SIP+middlebox device is out in the network, helping |the UA traverse a Firewall/NAT in-between it and the UA? (what is normally called "Hosted NAT |Traversal" or "Far-end NAT traversal" by vendors) | |I ask because the former case of being the NAT is not the same as the latter case. Latching and most |of the policies described in this draft do not typically apply to the former case, but do to the |latter. ICE behaves differently for the two cases. SBCs, as well as the 3GPP and TISPAN variants, |are of the latter variety, not the former. And they don't need an RFC to tell them anything, because |it's not something they don't already know. What's worse, it's actually wrong or misleading in some |of its recommendations. | |The draft conflates the two cases, probably because RFC 3303 did as well because it is a really old |RFC from back when the whole SIP middlebox market began. And the draft is wrong about ICE because it |was written before ICE was published. "Extending" 3303 with this draft is useless at best, or harmful |at worst, unless it gets a serious re-write. My 2 cents anyway. | |-hadriel From albrecht.schwarz@alcatel-lucent.com Wed Apr 6 03:59:57 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450C03A68DC for ; Wed, 6 Apr 2011 03:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCkhLT9qBbmQ for ; Wed, 6 Apr 2011 03:59:55 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 83CB63A68C8 for ; Wed, 6 Apr 2011 03:59:55 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p36Axukw028339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Apr 2011 13:01:30 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 6 Apr 2011 13:01:20 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Muthu ArulMozhi Perumal (mperumal)" , Hadriel Kaplan Date: Wed, 6 Apr 2011 13:01:26 +0200 Thread-Topic: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? Thread-Index: AcvwZpf2DAHHvwOGRNGc8htfEXoaqQD2t3mQAAGdMAA= Message-ID: <5F7BCCF5541B7444830A2288ABBEBC961D5023F120@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com> <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020523BA1A@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020523BA1A@XMB-BGL-414.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 10:59:57 -0000 There's a basic issue with the draft related to lacking definitions. Fig.1 provides the considered network architecture, but the involved entiti= es/functions are not sufficiently defined. Thus, clause 2 should be extended by terminology for 1) Middlebox 2) MIDCOM agent 3) SIP ALG The first two terms are loosely defined by a reference to RFC 3234 in claus= e 1. However, RFC 3234 is rather a "catalogue" of all possible IP-IP gateway var= iants, other than an IP router. Such a high-level definition is inappropria= te in my understanding. And therefore: any comparison to TISPAN or 3GPP defined "middleboxes" will = fail. Their functionality is precisely given by H.248 profile specification= s. The reference to RFC 3234 could be replaced/extended by RFC 5189, the proto= col semantics. The defined content of the MIDCOM SNMP MIB provides then a more precise ref= erence to supported capabilities. [BTW: I'm not aware of any MIDCOM middlebox product in operation in IP netw= orks. Or does someone know an example?] With respect to "SIP ALG" (3), and due to the fact that this discussion is = about SDP Offer/Answer: I could imagine some value of this draft if e.g. the mapping/conversion of = SIP-embedded SDP elements to the MIDCOM-Middlebox protocol would be describ= ed. Support of remote NAT-traversal is just one example function. The existing signalling flows are too high level. Further: the SDP mapper between SIP call control signalling and MIDCOM midd= lebox signalling could be again a) concrete, i.e. specific to RFC 5189, thus a SIP/SDP-to-SNMP mapping func= tion; or b) generic, independent of any concrete middlebox control protocol. Albrecht =20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Muthu ArulMozhi=20 > Perumal (mperumal) > Sent: Mittwoch, 6. April 2011 12:31 > To: Hadriel Kaplan > Cc: mmusic > Subject: Re: [MMUSIC] Continued WG interest=20 > inSDPoffer/answerwithmiddleboxes? >=20 > |When you say "to aid in firewall/NAT traversal", I assume=20 > you mean when=20 > |the SIP+middlebox device *is* the firewall/NAT, right? You=20 > do NOT mean=20 > |when a SIP+middlebox device is out in the network, helping the UA=20 > |traverse a Firewall/NAT in-between it and the UA? (what is normally=20 > |called "Hosted NAT Traversal" > |or "Far-end NAT traversal" by vendors) >=20 > Yes, primarily the former use-case. However, the draft also=20 > described the later (see section 5). >=20 > |I ask because the former case of being the NAT is not the=20 > same as the=20 > |latter case. Latching and most of the policies described in=20 > this draft=20 > |do not typically apply to the former case, but do to the latter. >=20 > The draft does make this clear in section 5.1: >=20 > > If the middlebox supports the traversal of residential NATs,=20 > it applies a technique called "media latching": The=20 > destination IP address of packets forwarded by the middlebox=20 > in the outbound direction is derived from the source IP=20 > address of packets received in the inbound direction. > This overrides a destination address possibly configured by=20 > the MIDCOM agent. > >=20 > Overall, IMHO the recommendations in the draft seem useful to=20 > the kind of architecture/problems it describes. However,=20 > whether it applies to current deployments is something I am=20 > not sure. The draft claims such middleboxes are for instance=20 > the TISPAN A-BGF/C-BGF/I-BGF and the 3GPP IMS Access=20 > Gateway..perhaps this was long ago? >=20 > Muthu >=20 > |-----Original Message----- > |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |Sent: Friday, April 01, 2011 5:46 PM > |To: Muthu ArulMozhi Perumal (mperumal) > |Cc: mmusic > |Subject: Re: [MMUSIC] Continued WG interest > inSDPoffer/answerwithmiddleboxes? > | > | > |On Mar 31, 2011, at 10:48 PM, Muthu ArulMozhi Perumal=20 > (mperumal) wrote: > | > |> The main goal of the draft as it seems to claim is to describe the=20 > |> desirable behaviors of middleboxes and signaling protocols that > operate > |> on the media path, to aid in firewall/NAT traversal. It=20 > looks like an=20 > |> extension of RFC 3303 whose focus is also firewall and NAT=20 > traversal=20 > |> use-cases. The draft claims that the architecture/functions it > describes > |> is used in IMS and specified in 3GPP, TISPAN and=20 > PacketCable specs -- > if > |> it true, then this is where the recommendations in the=20 > draft would be=20 > |> useful I think. > | > |When you say "to aid in firewall/NAT traversal", I assume=20 > you mean when > the SIP+middlebox device *is* > |the firewall/NAT, right? You do NOT mean when a SIP+middlebox device > is out in the network, helping > |the UA traverse a Firewall/NAT in-between it and the UA? (what is > normally called "Hosted NAT > |Traversal" or "Far-end NAT traversal" by vendors) > | > |I ask because the former case of being the NAT is not the same as the > latter case. Latching and most > |of the policies described in this draft do not typically apply to the > former case, but do to the > |latter. ICE behaves differently for the two cases. SBCs, as well as > the 3GPP and TISPAN variants, > |are of the latter variety, not the former. And they don't=20 > need an RFC > to tell them anything, because > |it's not something they don't already know. What's worse, it's > actually wrong or misleading in some > |of its recommendations. > | > |The draft conflates the two cases, probably because RFC 3303 did as > well because it is a really old > |RFC from back when the whole SIP middlebox market began. =20 > And the draft > is wrong about ICE because it > |was written before ICE was published. "Extending" 3303 with=20 > this draft > is useless at best, or harmful > |at worst, unless it gets a serious re-write. My 2 cents anyway. > | > |-hadriel >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From Bert.Greevenbosch@huawei.com Thu Apr 7 20:08:27 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31B13A69EA for ; Thu, 7 Apr 2011 20:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLSUQhevNA-c for ; Thu, 7 Apr 2011 20:08:26 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DE39C3A6838 for ; Thu, 7 Apr 2011 20:08:25 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJB009J2CRIII@szxga05-in.huawei.com> for mmusic@ietf.org; Fri, 08 Apr 2011 11:09:18 +0800 (CST) Received: from szxeml201-edg.china.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 <0LJB006TQCRA52@szxga05-in.huawei.com> for mmusic@ietf.org; Fri, 08 Apr 2011 11:09:18 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 08 Apr 2011 11:09:04 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 08 Apr 2011 11:09:00 +0800 Date: Fri, 08 Apr 2011 03:08:59 +0000 From: Bert Greevenbosch In-reply-to: <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> X-Originating-IP: [10.70.109.52] To: "lennox@cs.columbia.edu" Message-id: <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-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: [MMUSIC] Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 03:08:27 -0000 Hi Jonathan, all, Interesting question! Here are some considerations: For frame compatible 3D video, the backwards compatibility issue consists mainly in that the receiving legacy device will display the both L/R views, in the way they were packed into the video stream. This is not a very pleasing for the eye, but it should not lead to big technical problems. However, in the simulcast and 2D+aux transmitted as two streams case, the problem is bigger, as there are two "m=video ..." lines, and a choice needs to be made which video to show. In the simulcast case, any of the L- and R-streams can do. But in the 2D+aux case, it would be best if the receiver showed the 2D stream, rather than the auxiliary stream. In case of SDP offer/answer, the problem is similar to the problem described in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on what will happen when the answerer does not understand the "group" attribute, in which case client behaviour is not clear. According to that text, the client might refuse the offer, in which case it is easy for the offerer to offer a 2D session instead. But if the client does not refuse the offer, it is up to the client to decide how to process the multiple video lines. Related is the fact, that the "3DS" grouping semantics will not be understood by legacy devices. This is not a new problem, for example, RFC 4756 about Forward Error Correction (FEC) grouping, also describes the problem. In that RFC, there are listed two possible responses: (1) The answerer returns an answer that ignores the grouping attribute. (2) The answerer sends a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP). In the first case, the offerer understands "3DS" grouping is not supported and can send a new offer for only a 2D connection. In the second case, the offerer can also try to send a new offer advertising for only a 2D connection, although it cannot be sure that the failure was caused by the "3DS" grouping beforehand. RFC 5583, about the Media Decoding Dependency "MDD" grouping, lists similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addresses the case in which a session is advertised using RTSP. and the legacy device does not understand "MDD" grouping. They differentiate the following cases: (1) If at least one of the media types included in the SDP is within the receiver's capabilities, it selects among those candidates according to implementation specific criteria for setup, as usual. (2) If none of the media types included in the SDP can be processed, then obviously no setup can occur. This would mean, that in case of simulcast L/R streams the receiver will most likely display one of the two streams, which is OK. But in the 2D+aux case, the receiver might either display the 2D stream or the auxiliary stream. Best regards, Bert -----Original Message----- From: lennox@cs.columbia.edu [mailto:lennox@cs.columbia.edu] Sent: 01 April 2011 20:41 To: Bert Greevenbosch Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" saying: > Hi all, > > Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts: > [...] > > Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts. I had one other question I was going to ask, but the line had been closed. What is the backward-compability story here? It seems like a non-3D-aware endpoint receiving this SDP message is going to have a lot of problems understanding what it means. (Remember that in SDP, unknown attributes are ignored.) Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing. -- Jonathan Lennox lennox@cs.columbia.edu From ted.ietf@gmail.com Fri Apr 8 10:49:20 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD363A699C for ; Fri, 8 Apr 2011 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNwfN8Ivb3hJ for ; Fri, 8 Apr 2011 10:49:18 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id D33F93A68BD for ; Fri, 8 Apr 2011 10:49:18 -0700 (PDT) Received: by pwi5 with SMTP id 5so1663004pwi.31 for ; Fri, 08 Apr 2011 10:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AB/5L6Nq0H3bav/anxuhG0GrhlEmLhwETNanUiEt4YE=; b=h4ScTSYTVnYWSpP5or4yxvx+2PUxCrzo+d2WWKakV2rROf5YwMjRT95sCti6Ur9wvE bCR22BDlXM5kK7D9o+elFmMYDeL7G8k8eZqt1vXfzYH+eK8Q/9i8JLfQh2q/weQOPtcQ zaOSt9z82wjR+12mTQSfVOj8m8JieLi3zsbCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KLIfPx8Taw/40Cj7Lc3/QoyYo+dTXpkjJieJ2IIwRmciiU59+UX7YfyKjvQxpuQJ0K L6K4kJ6XYvOhgUh5TDLVdrZcCh8u8etwaiuPC4RBniPGtYW9a8hbZWocPQeizlWxxOb9 2ZUH+KylTpcDWh44WVqMKXEDfmeWqLEg5eWfs= MIME-Version: 1.0 Received: by 10.142.237.20 with SMTP id k20mr2095020wfh.170.1302285064105; Fri, 08 Apr 2011 10:51:04 -0700 (PDT) Received: by 10.68.50.202 with HTTP; Fri, 8 Apr 2011 10:51:04 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> Date: Fri, 8 Apr 2011 10:51:04 -0700 Message-ID: From: Ted Hardie To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=000e0cd32e0aa4710704a06bde57 Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 17:49:20 -0000 --000e0cd32e0aa4710704a06bde57 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi Jonathan, all, > > Interesting question! Here are some considerations: > > For frame compatible 3D video, the backwards compatibility issue consists > mainly in that the receiving legacy device will display the both L/R views, > in the way they were packed into the video stream. This is not a very > pleasing for the eye, but it should not lead to big technical problems. > > Can you clarify this further, or provide a reference? I'm curious in particular about what you think a legacy device will use as a display framerate when it's getting signal originally intended for use with shutter glasses. regards, Ted > However, in the simulcast and 2D+aux transmitted as two streams case, the > problem is bigger, as there are two "m=video ..." lines, and a choice needs > to be made which video to show. In the simulcast case, any of the L- and > R-streams can do. But in the 2D+aux case, it would be best if the receiver > showed the 2D stream, rather than the auxiliary stream. > > In case of SDP offer/answer, the problem is similar to the problem > described in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an > overview on what will happen when the answerer does not understand the > "group" attribute, in which case client behaviour is not clear. According to > that text, the client might refuse the offer, in which case it is easy for > the offerer to offer a 2D session instead. But if the client does not refuse > the offer, it is up to the client to decide how to process the multiple > video lines. > > Related is the fact, that the "3DS" grouping semantics will not be > understood by legacy devices. This is not a new problem, for example, RFC > 4756 about Forward Error Correction (FEC) grouping, also describes the > problem. In that RFC, there are listed two possible responses: > (1) The answerer returns an answer that ignores the grouping attribute. > (2) The answerer sends a refusal to the request (e.g., 488 Not acceptable > here or 606 Not acceptable in SIP). > > In the first case, the offerer understands "3DS" grouping is not supported > and can send a new offer for only a 2D connection. > In the second case, the offerer can also try to send a new offer > advertising for only a 2D connection, although it cannot be sure that the > failure was caused by the "3DS" grouping beforehand. > > RFC 5583, about the Media Decoding Dependency "MDD" grouping, lists similar > behaviour for SDP offer/answer (section 6.1). Section 6.2 addresses the case > in which a session is advertised using RTSP. and the legacy device does not > understand "MDD" grouping. They differentiate the following cases: > (1) If at least one of the media types included in the SDP is within the > receiver's capabilities, it selects among those candidates according to > implementation specific criteria for setup, as usual. > (2) If none of the media types included in the SDP can be processed, then > obviously no setup can occur. > > This would mean, that in case of simulcast L/R streams the receiver will > most likely display one of the two streams, which is OK. > > But in the 2D+aux case, the receiver might either display the 2D stream or > the auxiliary stream. > > Best regards, > Bert > > -----Original Message----- > From: lennox@cs.columbia.edu [mailto:lennox@cs.columbia.edu] > Sent: 01 April 2011 20:41 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Remarks from today > > On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" > saying: > > > Hi all, > > > > Thank you for your remarks during today's session. Here are the remarks I > received concerning the 3D Format and Parallax Signalling drafts: > > > [...] > > > > Please let me know if I missed some questions/comments, or if you have > any new questions/comments on the drafts. > > I had one other question I was going to ask, but the line had been closed. > > What is the backward-compability story here? It seems like a non-3D-aware > endpoint receiving this SDP message is going to have a lot of problems > understanding what it means. (Remember that in SDP, unknown attributes are > ignored.) > > Packed frames are obviously the most problematic case here, but even the > simulcast and auxiliary modes are potentially unappealing. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000e0cd32e0aa4710704a06bde57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:
Hi Jonathan, all,

Interesting question! Here are some considerations:

For frame compatible 3D video, the backwards compatibility issue consists m= ainly in that the receiving legacy device will display the both L/R views, = in the way they were packed into the video stream. This is not a very pleas= ing for the eye, but it should not lead to big technical problems.


Can you clarify this further, or provide a refere= nce? I'm curious in particular about what you think a legacy device wil= l use as a display framerate when it's getting signal originally intend= ed for use with shutter glasses.

regards,

Ted


=A0
However, in the simulcast and 2D+aux transmitted as two streams case, the p= roblem is bigger, as there are two "m=3Dvideo ..." lines, and a c= hoice needs to be made which video to show. In the simulcast case, any of t= he L- and R-streams can do. But in the 2D+aux case, it would be best if the= receiver showed the 2D stream, rather than the auxiliary stream.

In case of SDP offer/answer, the problem is similar to the problem describe= d in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on w= hat will happen when the answerer does not understand the "group"= attribute, in which case client behaviour is not clear. According to that = text, the client might refuse the offer, in which case it is easy for the o= fferer to offer a 2D session instead. But if the client does not refuse the= offer, it is up to the client to decide how to process the multiple video = lines.

Related is the fact, that the "3DS" grouping semantics will not b= e understood by legacy devices. This is not a new problem, for example, RFC= 4756 about Forward Error Correction (FEC) grouping, also describes the pro= blem. In that RFC, there are listed two possible responses:
(1) The answerer returns an answer that ignores the grouping attribute.
(2) The answerer sends a refusal to the request (e.g., 488 Not acceptable h= ere or 606 Not acceptable in SIP).

In the first case, the offerer understands "3DS" grouping is not = supported and can send a new offer for only a 2D connection.
In the second case, the offerer can also try to send a new offer advertisin= g for only a 2D connection, although it cannot be sure that the failure was= caused by the "3DS" grouping beforehand.

RFC 5583, about the Media Decoding Dependency "MDD" grouping, lis= ts similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addres= ses the case in which a session is advertised using RTSP. and the legacy de= vice does not understand "MDD" grouping. They differentiate the f= ollowing cases:
(1) If at least one of the media types included in the SDP is within the re= ceiver's capabilities, it selects among those candidates according to i= mplementation specific criteria for setup, as usual.
(2) If none of the media types included in the SDP can be processed, then o= bviously no setup can occur.

This would mean, that in case of simulcast L/R streams the receiver will mo= st likely display one of the two streams, which is OK.

But in the 2D+aux case, the receiver might either display the 2D stream or = the auxiliary stream.

Best regards,
Bert

-----Original Message-----
From: lennox@cs.columbia.edu = [mailto:lennox@cs.columbia.edu]
Sent: 01 April 2011 20:41
To: Bert Greevenbosch
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

On Friday, April 1 2011, "Bert= Greevenbosch" wrote to "mmusi= c@ietf.org" saying:

> Hi all,
>
> Thank you for your remarks during today's session. Here are the re= marks I received concerning the 3D Format and Parallax Signalling drafts: >
[...]
>
> Please let me know if I missed some questions/comments, or if you have= any new questions/comments on the drafts.

I had one other question I was going to ask, but the line had been closed.<= br>
What is the backward-compability story here? =A0It seems like a non-3D-awar= e
endpoint receiving this SDP message is going to have a lot of problems
understanding what it means. =A0(Remember that in SDP, unknown attributes a= re
ignored.)

Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing.

--
Jonathan Lennox
lennox@cs.columbia.edu
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--000e0cd32e0aa4710704a06bde57-- From ari.keranen@nomadiclab.com Mon Apr 11 07:52:13 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074273A69C6 for ; Mon, 11 Apr 2011 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbEow1NnWjfO for ; Mon, 11 Apr 2011 07:52:12 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0C58E3A6933 for ; Mon, 11 Apr 2011 07:52:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 824B04E6DA for ; Mon, 11 Apr 2011 17:52:06 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BifbKjfF3Dbv for ; Mon, 11 Apr 2011 17:52:05 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 191A74E6D1 for ; Mon, 11 Apr 2011 17:52:05 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <4D95CB84.9050201@nomadiclab.com> Date: Mon, 11 Apr 2011 17:52:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6CC57766-80EA-4C45-ABDE-D2AD3F17349D@nomadiclab.com> References: <4D95CB84.9050201@nomadiclab.com> To: mmusic X-Mailer: Apple Mail (2.1082) Subject: Re: [MMUSIC] ICE TCP final fixes (and WGLC) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 14:52:13 -0000 On Apr 1, 2011, at 3:56 PM, Ari Keranen wrote: > Jonathan Lennox's review pointed out a few small things worth fixing = before the WGLC so I'm planning to post a new version containing these = fixes (as discussed on that thread) soon. The updated version is now available: http://www.ietf.org/id/draft-ietf-mmusic-ice-tcp-13.txt Cheers, Ari From Internet-Drafts@ietf.org Mon Apr 11 08:00:04 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E826E3A6B03; Mon, 11 Apr 2011 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG6jkl1OdHXt; Mon, 11 Apr 2011 08:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525913A6A67; Mon, 11 Apr 2011 08:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110411150002.12612.66258.idtracker@localhost> Date: Mon, 11 Apr 2011 08:00:02 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 15:00:04 -0000 --NextPart 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 : TCP Candidates with Interactive Connectivity Establishment (ICE) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-mmusic-ice-tcp-13.txt Pages : 29 Date : 2011-04-11 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-tcp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-11074944.I-D@ietf.org> --NextPart-- From Bert.Greevenbosch@huawei.com Mon Apr 11 19:48:10 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E035EE0692 for ; Mon, 11 Apr 2011 19:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAAgCzA8dFCG for ; Mon, 11 Apr 2011 19:48:09 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 58945E0675 for ; Mon, 11 Apr 2011 19:48:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJI00D0XQD331@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 12 Apr 2011 10:46:15 +0800 (CST) Received: from szxeml204-edg.china.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 <0LJI00FQCQD12Z@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 12 Apr 2011 10:46:15 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 12 Apr 2011 10:46:00 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 12 Apr 2011 10:45:57 +0800 Date: Tue, 12 Apr 2011 02:45:56 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.52] To: Ted Hardie Message-id: <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_D4DcVIeOXturewxsTkShnQ)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUCAFPgEAP/7eJRw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 12 Apr 2011 02:48:11 -0000 --Boundary_(ID_D4DcVIeOXturewxsTkShnQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ted, Jonathan, all, I see your point. It depends on the parameters that are chosen for the 3D stream, and how the legacy device responds to these parameters. The parameters are frame width, frame height and frame rate. I think the main advantage of frame packing is that the 3D video can be carried as a regular 2D video stream. Therefore, we can distinguish the following cases: 1. The 3D frame packed video is transmitted through a 2D video stream with fixed (prescribed) resolution/frame rate. 2. The 3D frame packed video is transmitted through a 2D video stream with flexible resolution/frame rate. In case the 3D frame packed video is transmitted through a 2D video stream with a fixed resolution/frame rate, the streaming server has to obey the restrictions of the 2D streaming system. For example, if the 2D streaming system has 1280x720 pixel^2 frames, and a frequency of 60Hz, the 3D video stream can have a resolution of 640x720 pixel^2, 60 Hz in case of side-by-side packing, or 1280x720 pixel^2, 30 Hz in case of frame sequential packing. In either case, there is no problem for a legacy 2D device receiving and displaying the stream, although it will not look good to the spectator. If the 3D frame packed video is transmitted through a 2D video stream with flexible resolution/frame rate, there is more freedom in choosing the resolution/frame rate of the 3D stream too. The 3D streaming server could choose a higher resolution or frame rate of the 2D video stream, such that the corresponding 3D video has better quality. For example, if a resolution of 1280x720 pixel^2, 60 Hz is required for the 3D stream, the server could give the carrying 2D stream a resolution of 2560x720 pixel^2, 60Hz or 1280x720 pixel^2, 120Hz. In either case, the legacy 2D receiver needs to understand the parameters of the carrying 2D video stream. It will go wrong when the parameters of the carrying 2D stream do not match the legacy 2D device's capabilities. But this is normal in the 2D case too; for example, if the system has fixed 1280x720 pixel^2, 60Hz, the server will have a problem attempting to the stream with any other resolution or frame rate. I think this issue is independent on whether the signal contains frame packed 3D video or not. With a flexible resolution/frame rate, problems can still occur, for example when the server trespasses some upper limits in what the system can process. But this, too, I see as independent from the frame packing. To come back to your question on shutter glasses: I think you mean a situation where a 3D video is frame sequential packed, with a frame rate that matches the frequency of the shutter glasses. Here the above two cases still hold: if the carrying 2D video stream has a fixed frame rate, the 3D video frame rate and shutter glass frequency can only be half the allowed 2D video stream frame rate. Otherwise the 3D stream cannot be carried in the 2D video stream. But if the restrictions on the 2D video stream are met, the 2D device will have no problem with displaying it. What's your opinion? Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 09 April 2011 01:51 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch > wrote: Hi Jonathan, all, Interesting question! Here are some considerations: For frame compatible 3D video, the backwards compatibility issue consists mainly in that the receiving legacy device will display the both L/R views, in the way they were packed into the video stream. This is not a very pleasing for the eye, but it should not lead to big technical problems. Can you clarify this further, or provide a reference? I'm curious in particular about what you think a legacy device will use as a display framerate when it's getting signal originally intended for use with shutter glasses. regards, Ted However, in the simulcast and 2D+aux transmitted as two streams case, the problem is bigger, as there are two "m=video ..." lines, and a choice needs to be made which video to show. In the simulcast case, any of the L- and R-streams can do. But in the 2D+aux case, it would be best if the receiver showed the 2D stream, rather than the auxiliary stream. In case of SDP offer/answer, the problem is similar to the problem described in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on what will happen when the answerer does not understand the "group" attribute, in which case client behaviour is not clear. According to that text, the client might refuse the offer, in which case it is easy for the offerer to offer a 2D session instead. But if the client does not refuse the offer, it is up to the client to decide how to process the multiple video lines. Related is the fact, that the "3DS" grouping semantics will not be understood by legacy devices. This is not a new problem, for example, RFC 4756 about Forward Error Correction (FEC) grouping, also describes the problem. In that RFC, there are listed two possible responses: (1) The answerer returns an answer that ignores the grouping attribute. (2) The answerer sends a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP). In the first case, the offerer understands "3DS" grouping is not supported and can send a new offer for only a 2D connection. In the second case, the offerer can also try to send a new offer advertising for only a 2D connection, although it cannot be sure that the failure was caused by the "3DS" grouping beforehand. RFC 5583, about the Media Decoding Dependency "MDD" grouping, lists similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addresses the case in which a session is advertised using RTSP. and the legacy device does not understand "MDD" grouping. They differentiate the following cases: (1) If at least one of the media types included in the SDP is within the receiver's capabilities, it selects among those candidates according to implementation specific criteria for setup, as usual. (2) If none of the media types included in the SDP can be processed, then obviously no setup can occur. This would mean, that in case of simulcast L/R streams the receiver will most likely display one of the two streams, which is OK. But in the 2D+aux case, the receiver might either display the 2D stream or the auxiliary stream. Best regards, Bert -----Original Message----- From: lennox@cs.columbia.edu [mailto:lennox@cs.columbia.edu] Sent: 01 April 2011 20:41 To: Bert Greevenbosch Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" saying: > Hi all, > > Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts: > [...] > > Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts. I had one other question I was going to ask, but the line had been closed. What is the backward-compability story here? It seems like a non-3D-aware endpoint receiving this SDP message is going to have a lot of problems understanding what it means. (Remember that in SDP, unknown attributes are ignored.) Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --Boundary_(ID_D4DcVIeOXturewxsTkShnQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Ted, Jonathan, all,

 

I see your point. It depends on the parameters that are chosen for the 3D stream, and how the legacy device responds to these parameters. The parameters are frame width, frame height and frame rate.

 

I think the main advantage of frame packing is that the 3D video can be carried as a regular 2D video stream. Therefore, we can distinguish the following cases:

 

1.       The 3D frame packed video is transmitted through a 2D video stream with fixed (prescribed) resolution/frame rate.

2.       The 3D frame packed video is transmitted through a 2D video stream with flexible resolution/frame rate.

 

In case the 3D frame packed video is transmitted through a 2D video stream with a fixed resolution/frame rate, the streaming server has to obey the restrictions of the 2D streaming system. For example, if the 2D streaming system has 1280x720 pixel^2 frames, and a frequency of 60Hz, the 3D video stream can have a resolution of 640x720 pixel^2, 60 Hz in case of side-by-side packing, or 1280x720 pixel^2, 30 Hz in case of frame sequential packing. In either case, there is no problem for a legacy 2D device receiving and displaying the stream, although it will not look good to the spectator.

 

If the 3D frame packed video is transmitted through a 2D video stream with flexible resolution/frame rate, there is more freedom in choosing the resolution/frame rate of the 3D stream too. The 3D streaming server could choose a higher resolution or frame rate of the 2D video stream, such that the corresponding 3D video has better quality. For example, if a resolution of 1280x720 pixel^2, 60 Hz is required for the 3D stream, the server could give the carrying 2D stream a resolution of 2560x720 pixel^2, 60Hz or 1280x720 pixel^2, 120Hz.

 

In either case, the legacy 2D receiver needs to understand the parameters of the carrying 2D video stream. It will go wrong when the parameters of the carrying 2D stream do not match the legacy 2D device's capabilities. But this is normal in the 2D case too; for example, if the system has fixed 1280x720 pixel^2, 60Hz, the server will have a problem attempting to the stream with any other resolution or frame rate. I think this issue is independent on whether the signal contains frame packed 3D video or not.

 

With a flexible resolution/frame rate, problems can still occur, for example when the server trespasses some upper limits in what the system can process. But this, too, I see as independent from the frame packing.

 

To come back to your question on shutter glasses: I think you mean a situation where a 3D video is frame sequential packed, with a frame rate that matches the frequency of the shutter glasses. Here the above two cases still hold: if the carrying 2D video stream has a fixed frame rate, the 3D video frame rate and shutter glass frequency can only be half the allowed 2D video stream frame rate. Otherwise the 3D stream cannot be carried in the 2D video stream. But if the restrictions on the 2D video stream are met, the 2D device will have no problem with displaying it.

 

What's your opinion?

 

Best regards,

Bert

 

 

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: 09 April 2011 01:51
To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

 

On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:

Hi Jonathan, all,

Interesting question! Here are some considerations:

For frame compatible 3D video, the backwards compatibility issue consists mainly in that the receiving legacy device will display the both L/R views, in the way they were packed into the video stream. This is not a very pleasing for the eye, but it should not lead to big technical problems.


Can you clarify this further, or provide a reference? I'm curious in particular about what you think a legacy device will use as a display framerate when it's getting signal originally intended for use with shutter glasses.

regards,

Ted


 

However, in the simulcast and 2D+aux transmitted as two streams case, the problem is bigger, as there are two "m=video ..." lines, and a choice needs to be made which video to show. In the simulcast case, any of the L- and R-streams can do. But in the 2D+aux case, it would be best if the receiver showed the 2D stream, rather than the auxiliary stream.

In case of SDP offer/answer, the problem is similar to the problem described in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on what will happen when the answerer does not understand the "group" attribute, in which case client behaviour is not clear. According to that text, the client might refuse the offer, in which case it is easy for the offerer to offer a 2D session instead. But if the client does not refuse the offer, it is up to the client to decide how to process the multiple video lines.

Related is the fact, that the "3DS" grouping semantics will not be understood by legacy devices. This is not a new problem, for example, RFC 4756 about Forward Error Correction (FEC) grouping, also describes the problem. In that RFC, there are listed two possible responses:
(1) The answerer returns an answer that ignores the grouping attribute.
(2) The answerer sends a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP).

In the first case, the offerer understands "3DS" grouping is not supported and can send a new offer for only a 2D connection.
In the second case, the offerer can also try to send a new offer advertising for only a 2D connection, although it cannot be sure that the failure was caused by the "3DS" grouping beforehand.

RFC 5583, about the Media Decoding Dependency "MDD" grouping, lists similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addresses the case in which a session is advertised using RTSP. and the legacy device does not understand "MDD" grouping. They differentiate the following cases:
(1) If at least one of the media types included in the SDP is within the receiver's capabilities, it selects among those candidates according to implementation specific criteria for setup, as usual.
(2) If none of the media types included in the SDP can be processed, then obviously no setup can occur.

This would mean, that in case of simulcast L/R streams the receiver will most likely display one of the two streams, which is OK.

But in the 2D+aux case, the receiver might either display the 2D stream or the auxiliary stream.

Best regards,
Bert


-----Original Message-----
From: lennox@cs.columbia.edu [mailto:lennox@cs.columbia.edu]
Sent: 01 April 2011 20:41
To: Bert Greevenbosch
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" saying:

> Hi all,
>
> Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts:
>
[...]
>
> Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts.

I had one other question I was going to ask, but the line had been closed.

What is the backward-compability story here?  It seems like a non-3D-aware
endpoint receiving this SDP message is going to have a lot of problems
understanding what it means.  (Remember that in SDP, unknown attributes are
ignored.)

Packed frames are obviously the most problematic case here, but even the
simulcast and auxiliary modes are potentially unappealing.

--
Jonathan Lennox
lennox@cs.columbia.edu
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 

--Boundary_(ID_D4DcVIeOXturewxsTkShnQ)-- From gonzalo.camarillo@ericsson.com Tue Apr 12 04:24:49 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D615E07AE for ; Tue, 12 Apr 2011 04:24:49 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lISHCnFWHPd9 for ; Tue, 12 Apr 2011 04:24:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 10B70E078E for ; Tue, 12 Apr 2011 04:24:47 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-35-4da4367e510b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0E.D6.09202.E7634AD4; Tue, 12 Apr 2011 13:24:47 +0200 (CEST) Received: from [131.160.126.135] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 12 Apr 2011 13:24:45 +0200 Message-ID: <4DA4367C.9010104@ericsson.com> Date: Tue, 12 Apr 2011 14:24:44 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Flemming Andreasen References: <4D933186.2030804@erg.abdn.ac.uk> <4D94E5F6.90004@cisco.com> <4D94F905.4070307@cisco.com> In-Reply-To: <4D94F905.4070307@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Gorry Fairhurst , Jonathan Lennox , "mmusic@ietf.org" , Pasi Sarolahti Subject: Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.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: Tue, 12 Apr 2011 11:24:49 -0000 Hi, >> This is the one point on which I disagree -- this is a choice of >> alternate transports, so it's more like ICE than CapNeg, it seems to me. >> > I think it depends on what you are trying to do: Negotiate use of a > mechanism that both sides support or find a mechanism that can establish > connectivity as verified by ICE. It's probably quite reasonable to > support both scenarios. RFC 5939 Section 3.7 has a bit more text around > this btw. > > More discussion/opinions on this point would be useful. theoretically, I agree there are two scenarios. However, in practice, endpoints are interested in establishing the best possible connection. ICE allows the endpoints to decide what "the best" means to them. It may be the connection that can be established the fastest, or the connection with the lowest delay, or whatever. Therefore, endpoints will try every possible path until they find the best according to their definition. Why would two endpoints want to limit themselves to only try DCCP-over-IP paths or DCCP-over-UDP paths when they can try both and pick the best? Do you have any scenario in mind where endpoints are constrained to only try one type of path for some reason? Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Tue Apr 12 05:00:31 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0FE21E06C6 for ; Tue, 12 Apr 2011 05:00:31 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-9-hxw+T-U0 for ; Tue, 12 Apr 2011 05:00:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 30D4DE066B for ; Tue, 12 Apr 2011 05:00:30 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-c7-4da43edd66cf Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 43.9C.09202.DDE34AD4; Tue, 12 Apr 2011 14:00:29 +0200 (CEST) Received: from [131.160.126.135] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 12 Apr 2011 14:00:28 +0200 Message-ID: <4DA43EDC.5060006@ericsson.com> Date: Tue, 12 Apr 2011 15:00:28 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mmusic X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] NAT traversal in draft-loreto-mmusic-sctp-sdp X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:00:31 -0000 Folks, [with my individual contributor hat on] In our session in Prague, we discussed whether or not the following draft needs to specify an ICE-based NAT traversal mechanism, which would include support for UDP-encapsulated SCTP traffic. https://datatracker.ietf.org/doc/draft-loreto-mmusic-sctp-sdp/ SCTP has its own association establishment and address management mechanisms. SCTP supports, among other things, multihomed endpoints. It is clear that while some SCTP associations may be established using SDP (as described in the draft above), many SCTP associations will be established and managed without using SDP. Defining SDP-based ICE procedures for SCTP would require the specification of extensions to SCTP (e.g., a UDP encapsulation of SCTP or how to perform initial connectivity checks when the UDP encapsulation is not used). Additionally, even if we defined SDP-based ICE procedures for SCTP, they would need to be redefined for SCTP associations that are established without using SDP anyway. Therefore, I believe we should not be including ICE procedures in the draft above at this point. If the SCTP community decides to include ICE procedures in SCTP itself in the future, specifying how to use them in SDP will be easy enough, though. With respect to whether or not the draft above needs to specify a way to describe SCTP over UDP streams, this discussion is related to the DCCP over UDP discussion also on this mailing list. I also believe we should stick to ICE instead of defining a new specific attribute. In summary, I would leave the draft above as is. It would only define the 'SCTP' and 'SCTP/DTLS' protocol identifiers for SDP. In this way, the mechanism for establishing an SCTP association would be identical to the mechanism used to establish a regular SCTP association. Address management would be performed by SCTP, and not at the SDP level, as in any regular SCTP association. If or when the SCTP community decides to extend SCTP to support UDP encapsulation (there is a draft on that) or ICE-based procedures, we can add SDP-based support if needed. Cheers, Gonzalo From ted.ietf@gmail.com Tue Apr 12 08:53:55 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1551FE0821 for ; Tue, 12 Apr 2011 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFsubHLcyOnv for ; Tue, 12 Apr 2011 08:53:52 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 81795E081D for ; Tue, 12 Apr 2011 08:53:51 -0700 (PDT) Received: by pwi5 with SMTP id 5so3061411pwi.31 for ; Tue, 12 Apr 2011 08:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vQcwlxgKPTT8Q8QIi8CzjcorY0iNANZTptISamYaH3c=; b=Ds1lN4209WT8KXjnJbOtXM5qbXPNCcBO5AgLCym/r78FIZEr/ztdwASnDfi1jHlQt4 o2ZKshAJIAZatArGAojOAYrBwoiX+wvxC1LWX8VkPaRNLgFeTsF4spkAOALikCJnX1oj 2nQLna11XR40FaGXN40rIZX7y89tY3gUIurFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XUSlMfkxKE+B6a0wtQaZX+uif3IoPgPdjxECSQIuaixd3w56qK5wDMuBK5FBALD2V7 YiUITfv8LhuiQT4VvPFRw0TAeNjkaWHRt7wXUqt4LQ5xpBaBieZ4j+cJipytmShBZQWz WtTmX+MFY1kicNI0Oahq/Tkx2Sfryow3NdZWo= MIME-Version: 1.0 Received: by 10.143.47.6 with SMTP id z6mr6368737wfj.227.1302623629910; Tue, 12 Apr 2011 08:53:49 -0700 (PDT) Received: by 10.68.50.202 with HTTP; Tue, 12 Apr 2011 08:53:49 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> Date: Tue, 12 Apr 2011 08:53:49 -0700 Message-ID: From: Ted Hardie To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=000e0cd480ecbca4ce04a0bab2fe Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 12 Apr 2011 15:53:55 -0000 --000e0cd480ecbca4ce04a0bab2fe Content-Type: text/plain; charset=ISO-8859-1 Hi Bert, Thanks for taking the time to craft such a detailed response. Some further questions and comments in-line. On Mon, Apr 11, 2011 at 7:45 PM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi Ted, Jonathan, all, > > > > I see your point. It depends on the parameters that are chosen for the 3D > stream, and how the legacy device responds to these parameters. The > parameters are frame width, frame height and frame rate. > > > > I think the main advantage of frame packing is that the 3D video can be > carried as a regular 2D video stream. Therefore, we can distinguish the > following cases: > > > > 1. The 3D frame packed video is transmitted through a 2D video > stream with fixed (prescribed) resolution/frame rate. > > 2. The 3D frame packed video is transmitted through a 2D video > stream with flexible resolution/frame rate. > > > > In case the 3D frame packed video is transmitted through a 2D video stream > with a fixed resolution/frame rate, the streaming server has to obey the > restrictions of the 2D streaming system. For example, if the 2D streaming > system has 1280x720 pixel^2 frames, and a frequency of 60Hz, the 3D video > stream can have a resolution of 640x720 pixel^2, 60 Hz in case of > side-by-side packing, or 1280x720 pixel^2, 30 Hz in case of frame sequential > packing. In either case, there is no problem for a legacy 2D device > receiving and displaying the stream, although it will not look good to the > spectator. > > > It seems like the 30Hz case is pretty unlikely, at least in systems designed for use with shutter-glasses, since they will halve that rate to show a different frame to each eye. In the usual case, the 3D systems use double the frame rate of the 2D system. I'm wondering whether even in the 60 Hz case this will look substantially lower quality to the 3D viewer. > If the 3D frame packed video is transmitted through a 2D video stream with > flexible resolution/frame rate, there is more freedom in choosing the > resolution/frame rate of the 3D stream too. The 3D streaming server could > choose a higher resolution or frame rate of the 2D video stream, such that > the corresponding 3D video has better quality. For example, if a resolution > of 1280x720 pixel^2, 60 Hz is required for the 3D stream, the server could > give the carrying 2D stream a resolution of 2560x720 pixel^2, 60Hz or > 1280x720 pixel^2, 120Hz. > > > > In either case, the legacy 2D receiver needs to understand the parameters > of the carrying 2D video stream. It will go wrong when the parameters of the > carrying 2D stream do not match the legacy 2D device's capabilities. But > this is normal in the 2D case too; for example, if the system has fixed > 1280x720 pixel^2, 60Hz, the server will have a problem attempting to the > stream with any other resolution or frame rate. I think this issue is > independent on whether the signal contains frame packed 3D video or not. > > > > With a flexible resolution/frame rate, problems can still occur, for > example when the server trespasses some upper limits in what the system can > process. But this, too, I see as independent from the frame packing. > > > > To come back to your question on shutter glasses: I think you mean a > situation where a 3D video is frame sequential packed, with a frame rate > that matches the frequency of the shutter glasses. Here the above two cases > still hold: if the carrying 2D video stream has a fixed frame rate, the 3D > video frame rate and shutter glass frequency can only be half the allowed 2D > video stream frame rate. Otherwise the 3D stream cannot be carried in the 2D > video stream. But if the restrictions on the 2D video stream are met, the 2D > device will have no problem with displaying it. > > > Do you know what the minimum shutter glass speed is? I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates. Are there glasses which can modify the rate substantially as well? regards, Ted Hardie > What's your opinion? > > > > Best regards, > > Bert > > > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* 09 April 2011 01:51 > *To:* Bert Greevenbosch > *Cc:* lennox@cs.columbia.edu; mmusic@ietf.org > > *Subject:* Re: [MMUSIC] Remarks from today > > > > On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > > Hi Jonathan, all, > > Interesting question! Here are some considerations: > > For frame compatible 3D video, the backwards compatibility issue consists > mainly in that the receiving legacy device will display the both L/R views, > in the way they were packed into the video stream. This is not a very > pleasing for the eye, but it should not lead to big technical problems. > > > Can you clarify this further, or provide a reference? I'm curious in > particular about what you think a legacy device will use as a display > framerate when it's getting signal originally intended for use with shutter > glasses. > > regards, > > Ted > > > > > However, in the simulcast and 2D+aux transmitted as two streams case, the > problem is bigger, as there are two "m=video ..." lines, and a choice needs > to be made which video to show. In the simulcast case, any of the L- and > R-streams can do. But in the 2D+aux case, it would be best if the receiver > showed the 2D stream, rather than the auxiliary stream. > > In case of SDP offer/answer, the problem is similar to the problem > described in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an > overview on what will happen when the answerer does not understand the > "group" attribute, in which case client behaviour is not clear. According to > that text, the client might refuse the offer, in which case it is easy for > the offerer to offer a 2D session instead. But if the client does not refuse > the offer, it is up to the client to decide how to process the multiple > video lines. > > Related is the fact, that the "3DS" grouping semantics will not be > understood by legacy devices. This is not a new problem, for example, RFC > 4756 about Forward Error Correction (FEC) grouping, also describes the > problem. In that RFC, there are listed two possible responses: > (1) The answerer returns an answer that ignores the grouping attribute. > (2) The answerer sends a refusal to the request (e.g., 488 Not acceptable > here or 606 Not acceptable in SIP). > > In the first case, the offerer understands "3DS" grouping is not supported > and can send a new offer for only a 2D connection. > In the second case, the offerer can also try to send a new offer > advertising for only a 2D connection, although it cannot be sure that the > failure was caused by the "3DS" grouping beforehand. > > RFC 5583, about the Media Decoding Dependency "MDD" grouping, lists similar > behaviour for SDP offer/answer (section 6.1). Section 6.2 addresses the case > in which a session is advertised using RTSP. and the legacy device does not > understand "MDD" grouping. They differentiate the following cases: > (1) If at least one of the media types included in the SDP is within the > receiver's capabilities, it selects among those candidates according to > implementation specific criteria for setup, as usual. > (2) If none of the media types included in the SDP can be processed, then > obviously no setup can occur. > > This would mean, that in case of simulcast L/R streams the receiver will > most likely display one of the two streams, which is OK. > > But in the 2D+aux case, the receiver might either display the 2D stream or > the auxiliary stream. > > Best regards, > Bert > > > -----Original Message----- > From: lennox@cs.columbia.edu [mailto:lennox@cs.columbia.edu] > Sent: 01 April 2011 20:41 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Remarks from today > > On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" > saying: > > > Hi all, > > > > Thank you for your remarks during today's session. Here are the remarks I > received concerning the 3D Format and Parallax Signalling drafts: > > > [...] > > > > Please let me know if I missed some questions/comments, or if you have > any new questions/comments on the drafts. > > I had one other question I was going to ask, but the line had been closed. > > What is the backward-compability story here? It seems like a non-3D-aware > endpoint receiving this SDP message is going to have a lot of problems > understanding what it means. (Remember that in SDP, unknown attributes are > ignored.) > > Packed frames are obviously the most problematic case here, but even the > simulcast and auxiliary modes are potentially unappealing. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --000e0cd480ecbca4ce04a0bab2fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bert,

Thanks for taking the time to craft such a detailed respons= e.=A0 Some further questions and comments in-line.

On Mon, Apr 11, 2011 at 7:45 PM, Bert Greevenbosch <Bert.Greevenbosch@h= uawei.com> wrote:

Hi Ted, Jonathan, all,

=A0

I see your point. It depends on the parameters that are chosen for th= e 3D stream, and how the legacy device responds to these parameters. The pa= rameters are frame width, frame height and frame rate.

=A0

I think the main advantage of frame packing is that the 3D video can = be carried as a regular 2D video stream. Therefore, we can distinguish the = following cases:

=A0

1.=A0=A0=A0=A0=A0=A0 The 3D frame packed video is transmitted through a 2D video stream with= fixed (prescribed) resolution/frame rate.

2.=A0=A0=A0=A0=A0=A0 The 3D frame packed video is transmitted through a 2D video stream with= flexible resolution/frame rate.

=A0

In case the 3D frame packed video is transmitted through a 2D video s= tream with a fixed resolution/frame rate, the streaming server has to obey = the restrictions of the 2D streaming system. For example, if the 2D streaming system has 12= 80x720 pixel^2 frames, and a frequency of 60Hz, the 3D video stream can hav= e a resolution of 640x720 pixel^2, 60 Hz in case of side-by-side packing, o= r 1280x720 pixel^2, 30 Hz in case of frame sequential packing. In either case, there is no problem for a leg= acy 2D device receiving and displaying the stream, although it will not loo= k good to the spectator.

=A0


It seems=A0 like the = 30Hz case is pretty unlikely, at least in systems designed for use with shu= tter-glasses, since they will halve that rate to show a different frame to = each eye.=A0 In the usual case, the 3D systems use double the frame rate of= the 2D system.=A0 I'm wondering whether even in the 60 Hz case this wi= ll look substantially lower quality to the 3D viewer.
=A0

If the 3D frame packed video is transmitted through a 2D video stream= with flexible resolution/frame rate, there is more freedom in choosing the= resolution/frame rate of the 3D stream too. The 3D streaming server could choose a higher r= esolution or frame rate of the 2D video stream, such that the corresponding= 3D video has better quality. For example, if a resolution of 1280x720 pixe= l^2, 60 Hz is required for the 3D stream, the server could give the carrying 2D stream a resolution of 2560x= 720 pixel^2, 60Hz or 1280x720 pixel^2, 120Hz.

=A0

In either case, the legacy 2D receiver needs to understand the parame= ters of the carrying 2D video stream. It will go wrong when the parameters = of the carrying 2D stream do not match the legacy 2D device's capabilities. But this i= s normal in the 2D case too; for example, if the system has fixed 1280x720 = pixel^2, 60Hz, the server will have a problem attempting to the stream with= any other resolution or frame rate. I think this issue is independent on whether the signal contains frame pac= ked 3D video or not.

=A0

With a flexible resolution/frame rate, problems can still occur, for = example when the server trespasses some upper limits in what the system can= process. But this, too, I see as independent from the frame packing.

=A0

To come back to your question on shutter glasses: I think you mean a = situation where a 3D video is frame sequential packed, with a frame rate th= at matches the frequency of the shutter glasses. Here the above two cases still hold:= if the carrying 2D video stream has a fixed frame rate, the 3D video frame= rate and shutter glass frequency can only be half the allowed 2D video str= eam frame rate. Otherwise the 3D stream cannot be carried in the 2D video stream. But if the restrictions o= n the 2D video stream are met, the 2D device will have no problem with disp= laying it.

=A0


Do you know what the = minimum shutter glass speed is?=A0 I know only know one manufacturer's = system at all well, and my understanding is that the timing signals which s= ynchronize them are really matching the frame start times to the shuttering= , but don't adjust the frame rates.=A0 Are there glasses which can modi= fy the rate substantially as well?

regards,

Ted Hardie
=

What's your opinion?

=A0

Best regards,

Bert

=A0

=A0

F= rom: Ted Hardie = [mailto:ted.ietf@gm= ail.com]
Sent: 09 April 2011 01:51
To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org


Subject: Re: [MMUSIC] Remarks from today

=A0

On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch &l= t;Bert.Gr= eevenbosch@huawei.com> wrote:

Hi Jonathan, all,

Interesting question! Here are some considerations:

For frame compatible 3D video, the backwards compatibility issue consists m= ainly in that the receiving legacy device will display the both L/R views, = in the way they were packed into the video stream. This is not a very pleas= ing for the eye, but it should not lead to big technical problems.


Can you clarify this further, or provide a reference? I'm curious in pa= rticular about what you think a legacy device will use as a display framera= te when it's getting signal originally intended for use with shutter gl= asses.

regards,

Ted


=A0

However, in the simulcast and 2D+aux transmitted as = two streams case, the problem is bigger, as there are two "m=3Dvideo .= .." lines, and a choice needs to be made which video to show. In the s= imulcast case, any of the L- and R-streams can do. But in the 2D+aux case, it would be best if the receiver showed the 2D= stream, rather than the auxiliary stream.

In case of SDP offer/answer, the problem is similar to the problem describe= d in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on w= hat will happen when the answerer does not understand the "group"= attribute, in which case client behaviour is not clear. According to that text, the client might refuse the offer, i= n which case it is easy for the offerer to offer a 2D session instead. But = if the client does not refuse the offer, it is up to the client to decide h= ow to process the multiple video lines.

Related is the fact, that the "3DS" grouping semantics will not b= e understood by legacy devices. This is not a new problem, for example, RFC= 4756 about Forward Error Correction (FEC) grouping, also describes the pro= blem. In that RFC, there are listed two possible responses:
(1) The answerer returns an answer that ignores the grouping attribute.
(2) The answerer sends a refusal to the request (e.g., 488 Not acceptable h= ere or 606 Not acceptable in SIP).

In the first case, the offerer understands "3DS" grouping is not = supported and can send a new offer for only a 2D connection.
In the second case, the offerer can also try to send a new offer advertisin= g for only a 2D connection, although it cannot be sure that the failure was= caused by the "3DS" grouping beforehand.

RFC 5583, about the Media Decoding Dependency "MDD" grouping, lis= ts similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addres= ses the case in which a session is advertised using RTSP. and the legacy de= vice does not understand "MDD" grouping. They differentiate the following cases:
(1) If at least one of the media types included in the SDP is within the re= ceiver's capabilities, it selects among those candidates according to i= mplementation specific criteria for setup, as usual.
(2) If none of the media types included in the SDP can be processed, then o= bviously no setup can occur.

This would mean, that in case of simulcast L/R streams the receiver will mo= st likely display one of the two streams, which is OK.

But in the 2D+aux case, the receiver might either display the 2D stream or = the auxiliary stream.

Best regards,
Bert


-----Original Message-----
From: lennox@cs= .columbia.edu [mailto:lennox@cs.columbia.edu]
Sent: 01 April 2011 20:41
To: Bert Greevenbosch
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

On Friday, April 1 2011, "Bert Greevenbosch&quo= t; wrote to "mmus= ic@ietf.org" saying:

> Hi all,
>
> Thank you for your remarks during today's session. Here are the re= marks I received concerning the 3D Format and Parallax Signalling drafts: >
[...]
>
> Please let me know if I missed some questions/comments, or if you have= any new questions/comments on the drafts.

I had one other question I was going to ask, but the line had been closed.<= br>
What is the backward-compability story here? =A0It seems like a non-3D-awar= e
endpoint receiving this SDP message is going to have a lot of problems
understanding what it means. =A0(Remember that in SDP, unknown attributes a= re
ignored.)

Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing.

--
Jonathan Lennox
lennox@cs.colum= bia.edu
_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

=A0


--000e0cd480ecbca4ce04a0bab2fe-- From miguel.a.garcia@ericsson.com Wed Apr 13 07:11:57 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D7C5E0752 for ; Wed, 13 Apr 2011 07:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUrZhJBzfTzc for ; Wed, 13 Apr 2011 07:11:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id A46EAE06FC for ; Wed, 13 Apr 2011 07:11:56 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-c5-4da5af2b081d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0C.53.09202.B2FA5AD4; Wed, 13 Apr 2011 16:11:55 +0200 (CEST) Received: from [159.107.24.215] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Apr 2011 16:11:55 +0200 Message-ID: <4DA5AF2A.1050509@ericsson.com> Date: Wed, 13 Apr 2011 16:11:54 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] Proposed milestone update 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, 13 Apr 2011 14:11:57 -0000 The chairs have been drafting a proposal for updating the current list of milestones in MMUSIC, which is a bit out of date. Please take a look at the proposal below. If you have comments, now is the time to air them. Just a brief reminder that we can always submit documents before the date stated in the milestone, but we shouldn't sleep and send documents after that date. Apr 2011 Submit ICE Options Registry as a Proposed Standard June 2011 Submit SDP Image Attribute as Proposed Standard June 2011 Submit ICE-TCP draft as a Proposed Standard June 2011 Submit SDP extensions for audio media streams over Circuit- Switched bearers as Proposed Standard June 2011 Submit revised RTSP spec for Proposed or Draft Standard (as appropriate) Aug 2011 Submit RTSP NAT considerations draft Sep 2011 Submit Considerations for using SDP offer/answer with middleboxes for BCP Oct 2011 Submit SDP extensions for Media Loopback for Proposed Standard Dec 2011 Submit SCTP-Based Media Transport in SDP as Proposed Standard. Jan 2012 SDP extensions for Media Capability Negotiations Jan 2012 Submit SDP extensions for Media Titles and Media Bandwidth Capability Negotiations as Proposed Standard Feb 2012 Submit revised SDP specification to IETF for Proposed Standard July 2012 Submit Offer/Answer Examples as Informational Cheers, Miguel and Flemming. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Bert.Greevenbosch@huawei.com Wed Apr 13 22:45:05 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4BE37E0670 for ; Wed, 13 Apr 2011 22:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=3.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfCIJ8JYSdmw for ; Wed, 13 Apr 2011 22:45:02 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id C9D5EE07FF for ; Wed, 13 Apr 2011 22:45:01 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00JODNZ0QY@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 14 Apr 2011 13:45:00 +0800 (CST) Received: from szxeml206-edg.china.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 <0LJM00M2QNYZFL@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 14 Apr 2011 13:45:00 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 13:44:56 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 13:44:58 +0800 Date: Thu, 14 Apr 2011 05:44:58 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.52] To: Ted Hardie Message-id: <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/UAT23TixwNhfLr6wA4QRA)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUCAFPgEAP/7eJRwgAqv/YD//mkrcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 14 Apr 2011 05:45:05 -0000 --Boundary_(ID_/UAT23TixwNhfLr6wA4QRA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ted, all, Thank you for your feedback. Here are my thoughts: >It seems like the 30Hz case is pretty unlikely, at least in systems designed for use with shutter-glasses, since they will halve that rate to show a different frame to each eye. In the usual case, the 3D systems use double the frame rate of the 2D system. I'm wondering whether even in the 60 Hz case this will look substantially lower quality to the 3D viewer. >Do you know what the minimum shutter glass speed is? I agree, the 30Hz (per view) case would give a flickering effect. Since normal TVs have a frequency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. But the receiver can also upsample the received signal to a higher display rate. For example, if it receives the following frame sequence at 30Hz/view: L1,R1,L2,R2,L3,R3,..., then it could display at 60Hz/view: L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... The receiver can also use some interpolation technique to generate the frames between Lk and L(k+1). I think that in praxis the receiving device will process the received stream to make it fit the display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It also allows other display types such as polarisation or autostereoscopic displays. >I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates. Are there glasses which can modify the rate substantially as well? Can you please explain a bit more about the system you are referring too, especially about not modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) or the frame rate of the video stream as it is received before it is decoded (by the codec)? Do you think we need to add some text about this to the draft? Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 12 April 2011 23:54 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today Hi Bert, Thanks for taking the time to craft such a detailed response. Some further questions and comments in-line. On Mon, Apr 11, 2011 at 7:45 PM, Bert Greevenbosch > wrote: Hi Ted, Jonathan, all, I see your point. It depends on the parameters that are chosen for the 3D stream, and how the legacy device responds to these parameters. The parameters are frame width, frame height and frame rate. I think the main advantage of frame packing is that the 3D video can be carried as a regular 2D video stream. Therefore, we can distinguish the following cases: 1. The 3D frame packed video is transmitted through a 2D video stream with fixed (prescribed) resolution/frame rate. 2. The 3D frame packed video is transmitted through a 2D video stream with flexible resolution/frame rate. In case the 3D frame packed video is transmitted through a 2D video stream with a fixed resolution/frame rate, the streaming server has to obey the restrictions of the 2D streaming system. For example, if the 2D streaming system has 1280x720 pixel^2 frames, and a frequency of 60Hz, the 3D video stream can have a resolution of 640x720 pixel^2, 60 Hz in case of side-by-side packing, or 1280x720 pixel^2, 30 Hz in case of frame sequential packing. In either case, there is no problem for a legacy 2D device receiving and displaying the stream, although it will not look good to the spectator. It seems like the 30Hz case is pretty unlikely, at least in systems designed for use with shutter-glasses, since they will halve that rate to show a different frame to each eye. In the usual case, the 3D systems use double the frame rate of the 2D system. I'm wondering whether even in the 60 Hz case this will look substantially lower quality to the 3D viewer. If the 3D frame packed video is transmitted through a 2D video stream with flexible resolution/frame rate, there is more freedom in choosing the resolution/frame rate of the 3D stream too. The 3D streaming server could choose a higher resolution or frame rate of the 2D video stream, such that the corresponding 3D video has better quality. For example, if a resolution of 1280x720 pixel^2, 60 Hz is required for the 3D stream, the server could give the carrying 2D stream a resolution of 2560x720 pixel^2, 60Hz or 1280x720 pixel^2, 120Hz. In either case, the legacy 2D receiver needs to understand the parameters of the carrying 2D video stream. It will go wrong when the parameters of the carrying 2D stream do not match the legacy 2D device's capabilities. But this is normal in the 2D case too; for example, if the system has fixed 1280x720 pixel^2, 60Hz, the server will have a problem attempting to the stream with any other resolution or frame rate. I think this issue is independent on whether the signal contains frame packed 3D video or not. With a flexible resolution/frame rate, problems can still occur, for example when the server trespasses some upper limits in what the system can process. But this, too, I see as independent from the frame packing. To come back to your question on shutter glasses: I think you mean a situation where a 3D video is frame sequential packed, with a frame rate that matches the frequency of the shutter glasses. Here the above two cases still hold: if the carrying 2D video stream has a fixed frame rate, the 3D video frame rate and shutter glass frequency can only be half the allowed 2D video stream frame rate. Otherwise the 3D stream cannot be carried in the 2D video stream. But if the restrictions on the 2D video stream are met, the 2D device will have no problem with displaying it. Do you know what the minimum shutter glass speed is? I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates. Are there glasses which can modify the rate substantially as well? regards, Ted Hardie What's your opinion? Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 09 April 2011 01:51 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch > wrote: Hi Jonathan, all, Interesting question! Here are some considerations: For frame compatible 3D video, the backwards compatibility issue consists mainly in that the receiving legacy device will display the both L/R views, in the way they were packed into the video stream. This is not a very pleasing for the eye, but it should not lead to big technical problems. Can you clarify this further, or provide a reference? I'm curious in particular about what you think a legacy device will use as a display framerate when it's getting signal originally intended for use with shutter glasses. regards, Ted However, in the simulcast and 2D+aux transmitted as two streams case, the problem is bigger, as there are two "m=video ..." lines, and a choice needs to be made which video to show. In the simulcast case, any of the L- and R-streams can do. But in the 2D+aux case, it would be best if the receiver showed the 2D stream, rather than the auxiliary stream. In case of SDP offer/answer, the problem is similar to the problem described in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on what will happen when the answerer does not understand the "group" attribute, in which case client behaviour is not clear. According to that text, the client might refuse the offer, in which case it is easy for the offerer to offer a 2D session instead. But if the client does not refuse the offer, it is up to the client to decide how to process the multiple video lines. Related is the fact, that the "3DS" grouping semantics will not be understood by legacy devices. This is not a new problem, for example, RFC 4756 about Forward Error Correction (FEC) grouping, also describes the problem. In that RFC, there are listed two possible responses: (1) The answerer returns an answer that ignores the grouping attribute. (2) The answerer sends a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP). In the first case, the offerer understands "3DS" grouping is not supported and can send a new offer for only a 2D connection. In the second case, the offerer can also try to send a new offer advertising for only a 2D connection, although it cannot be sure that the failure was caused by the "3DS" grouping beforehand. RFC 5583, about the Media Decoding Dependency "MDD" grouping, lists similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addresses the case in which a session is advertised using RTSP. and the legacy device does not understand "MDD" grouping. They differentiate the following cases: (1) If at least one of the media types included in the SDP is within the receiver's capabilities, it selects among those candidates according to implementation specific criteria for setup, as usual. (2) If none of the media types included in the SDP can be processed, then obviously no setup can occur. This would mean, that in case of simulcast L/R streams the receiver will most likely display one of the two streams, which is OK. But in the 2D+aux case, the receiver might either display the 2D stream or the auxiliary stream. Best regards, Bert -----Original Message----- From: lennox@cs.columbia.edu [mailto:lennox@cs.columbia.edu] Sent: 01 April 2011 20:41 To: Bert Greevenbosch Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Friday, April 1 2011, "Bert Greevenbosch" wrote to "mmusic@ietf.org" saying: > Hi all, > > Thank you for your remarks during today's session. Here are the remarks I received concerning the 3D Format and Parallax Signalling drafts: > [...] > > Please let me know if I missed some questions/comments, or if you have any new questions/comments on the drafts. I had one other question I was going to ask, but the line had been closed. What is the backward-compability story here? It seems like a non-3D-aware endpoint receiving this SDP message is going to have a lot of problems understanding what it means. (Remember that in SDP, unknown attributes are ignored.) Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --Boundary_(ID_/UAT23TixwNhfLr6wA4QRA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Ted, all,

 

Thank you for your feedback. Here are my = thoughts:

 

>It seems  like the 30Hz case is pretty unlikely, at= least in systems designed for use with shutter-glasses, since they will ha= lve that rate to show a different frame to each eye.  In the usual case, the 3D systems use double the = frame rate of the 2D system.  I'm wondering whether even in the 60 Hz = case this will look substantially lower quality to the 3D viewer.

 

>Do you know what the minimum shutter glass speed is?&nbs= p;

 

I agree, the 30Hz (per view) case would g= ive a flickering effect. Since normal TVs have a frequency of 60Hz or more,= for a similar quality with shutter glasses the frame rate should be 120Hz (=3D60 Hz/view) or more.

 

But the receiver can also upsample the re= ceived signal to a higher display rate. For example, if it receives the fol= lowing frame sequence at 30Hz/view:

 

L1,R1,L2,R2,L3,R3,...= ,

 

then it could display at 60Hz/view:<= /o:p>

 

L1,R1,L1,R1,L2,R2,L2,= R2,L3,R3,L3,R3,....

 

The receiver can also use some interpolat= ion technique to generate the frames between Lk and L(k+1= ).

 

I think that in praxis the receiving devi= ce will process the received stream to make it fit the display system. This= allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It= also allows other display types such as polarisation or autostereoscopic d= isplays.

 

>I know only know one manufacturer's system at all well, = and my understanding is that the timing signals which synchronize them are = really matching the frame start times to the shuttering, but don't adjust the frame rates.  Are= there glasses which can modify the rate substantially as well?<= /span>

 

Can you please explain a bit more about t= he system you are referring too, especially about not modifying the frame r= ate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) o= r the frame rate of the video stream as it is received before it is decoded= (by the codec)?

 

Do you think we need to add some text abo= ut this to the draft?

 

Best regards,

Bert

 

 

From: Ted Hardie [mailto:= ted.ietf@gmail.com]
Sent: 12 April 2011 23:54
To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

 

Hi Bert,

Thanks for taking the time to craft such a detailed response.  Some fu= rther questions and comments in-line.

On Mon, Apr 11, 2011 at 7:45 PM, Bert Greevenbosch &= lt;Bert.Greevenbosch@huawei= .com> wrote:

Hi Ted, Jonathan, a= ll,

 <= /o:p>

I see your point. I= t depends on the parameters that are chosen for the 3D stream, and how the = legacy device responds to these parameters. The parameters are frame width, frame height and frame rate.

 <= /o:p>

I think the main ad= vantage of frame packing is that the 3D video can be carried as a regular 2= D video stream. Therefore, we can distinguish the following cases:

 <= /o:p>

1.       The 3D frame packed v= ideo is transmitted through a 2D video stream with fixed (prescribed) resol= ution/frame rate.

2.       The 3D frame packed v= ideo is transmitted through a 2D video stream with flexible resolution/fram= e rate.

 <= /o:p>

In case the 3D fram= e packed video is transmitted through a 2D video stream with a fixed resolu= tion/frame rate, the streaming server has to obey the restrictions of the 2D streaming system. For example, if t= he 2D streaming system has 1280x720 pixel^2 frames, and a frequency of 60Hz= , the 3D video stream can have a resolution of 640x720 pixel^2, 60 Hz in ca= se of side-by-side packing, or 1280x720 pixel^2, 30 Hz in case of frame sequential packing. In either case, there = is no problem for a legacy 2D device receiving and displaying the stream, a= lthough it will not look good to the spectator.

 <= /o:p>


It seems  like the 30Hz case is pretty unlikely, at least in systems d= esigned for use with shutter-glasses, since they will halve that rate to sh= ow a different frame to each eye.  In the usual case, the 3D systems u= se double the frame rate of the 2D system.  I'm wondering whether even in the 60 Hz case this will look substantially = lower quality to the 3D viewer.
 

If the 3D frame pac= ked video is transmitted through a 2D video stream with flexible resolution= /frame rate, there is more freedom in choosing the resolution/frame rate of the 3D stream too. The 3D streaming = server could choose a higher resolution or frame rate of the 2D video strea= m, such that the corresponding 3D video has better quality. For example, if= a resolution of 1280x720 pixel^2, 60 Hz is required for the 3D stream, the server could give the carrying 2D= stream a resolution of 2560x720 pixel^2, 60Hz or 1280x720 pixel^2, 120Hz.<= /span>

 <= /o:p>

In either case, the= legacy 2D receiver needs to understand the parameters of the carrying 2D v= ideo stream. It will go wrong when the parameters of the carrying 2D stream do not match the legacy 2D device's c= apabilities. But this is normal in the 2D case too; for example, if the sys= tem has fixed 1280x720 pixel^2, 60Hz, the server will have a problem attemp= ting to the stream with any other resolution or frame rate. I think this issue is independent on whether the= signal contains frame packed 3D video or not.

 <= /o:p>

With a flexible res= olution/frame rate, problems can still occur, for example when the server t= respasses some upper limits in what the system can process. But this, too, I see as independent from the frame pac= king.

 <= /o:p>

To come back to you= r question on shutter glasses: I think you mean a situation where a 3D vide= o is frame sequential packed, with a frame rate that matches the frequency of the shutter glasses. Here the above two= cases still hold: if the carrying 2D video stream has a fixed frame rate, = the 3D video frame rate and shutter glass frequency can only be half the al= lowed 2D video stream frame rate. Otherwise the 3D stream cannot be carried in the 2D video stream. But if t= he restrictions on the 2D video stream are met, the 2D device will have no = problem with displaying it.

 <= /o:p>


Do you know what the minimum shutter glass speed is?  I know only know= one manufacturer's system at all well, and my understanding is that the ti= ming signals which synchronize them are really matching the frame start tim= es to the shuttering, but don't adjust the frame rates.  Are there glasses which can modify the rate substan= tially as well?

regards,

Ted Hardie

What's your opinion= ?

 <= /o:p>

Best regards,

Bert

 <= /o:p>

 <= /o:p>

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: 09 April 2011 01:51
To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org


Subject: Re: [MMUSIC] Remarks from today

 

On Thu, Apr 7, 2011 at 8:08 PM, Bert Greevenbosch <Bert.Greevenbosch@hua= wei.com> wrote:

Hi Jonathan, all,

Interesting question! Here are some considerations:

For frame compatible 3D video, the backwards compatibility issue consists m= ainly in that the receiving legacy device will display the both L/R views, = in the way they were packed into the video stream. This is not a very pleas= ing for the eye, but it should not lead to big technical problems.


Can you clarify this further, or provide a reference? I'm curious in partic= ular about what you think a legacy device will use as a display framerate w= hen it's getting signal originally intended for use with shutter glasses.
regards,

Ted


 

However, in the simulcast and 2D+aux transmitted as two stream= s case, the problem is bigger, as there are two "m=3Dvideo ..." l= ines, and a choice needs to be made which video to show. In the simulcast case, any of the L- and R-streams can do. But in the 2D&#= 43;aux case, it would be best if the receiver showed the 2D stream, rather = than the auxiliary stream.

In case of SDP offer/answer, the problem is similar to the problem describe= d in the SDP grouping spec (RFC 5888). Section 9.4.2 gives an overview on w= hat will happen when the answerer does not understand the "group"= attribute, in which case client behaviour is not clear. According to that text, the client might refuse the offer, i= n which case it is easy for the offerer to offer a 2D session instead. But = if the client does not refuse the offer, it is up to the client to decide h= ow to process the multiple video lines.

Related is the fact, that the "3DS" grouping semantics will not b= e understood by legacy devices. This is not a new problem, for example, RFC= 4756 about Forward Error Correction (FEC) grouping, also describes the pro= blem. In that RFC, there are listed two possible responses:
(1) The answerer returns an answer that ignores the grouping attribute.
(2) The answerer sends a refusal to the request (e.g., 488 Not acceptable h= ere or 606 Not acceptable in SIP).

In the first case, the offerer understands "3DS" grouping is not = supported and can send a new offer for only a 2D connection.
In the second case, the offerer can also try to send a new offer advertisin= g for only a 2D connection, although it cannot be sure that the failure was= caused by the "3DS" grouping beforehand.

RFC 5583, about the Media Decoding Dependency "MDD" grouping, lis= ts similar behaviour for SDP offer/answer (section 6.1). Section 6.2 addres= ses the case in which a session is advertised using RTSP. and the legacy de= vice does not understand "MDD" grouping. They differentiate the following cases:
(1) If at least one of the media types included in the SDP is within the re= ceiver's capabilities, it selects among those candidates according to imple= mentation specific criteria for setup, as usual.
(2) If none of the media types included in the SDP can be processed, then o= bviously no setup can occur.

This would mean, that in case of simulcast L/R streams the receiver will mo= st likely display one of the two streams, which is OK.

But in the 2D+aux case, the receiver might either display the 2D stream= or the auxiliary stream.

Best regards,
Bert


-----Original Message-----
From: lennox@cs= .columbia.edu [mailto:lennox@cs.columbia.edu]
Sent: 01 April 2011 20:41
To: Bert Greevenbosch
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

On Friday, April 1 2011, "Bert Greevenbosch" wrote to &q= uot;mmusic@ietf.org" saying:

> Hi all,
>
> Thank you for your remarks during today's session. Here are the remark= s I received concerning the 3D Format and Parallax Signalling drafts:
>
[...]
>
> Please let me know if I missed some questions/comments, or if you have= any new questions/comments on the drafts.

I had one other question I was going to ask, but the line had been closed.<= br>
What is the backward-compability story here?  It seems like a non-3D-a= ware
endpoint receiving this SDP message is going to have a lot of problems
understanding what it means.  (Remember that in SDP, unknown attribute= s are
ignored.)

Packed frames are obviously the most problematic case here, but even the simulcast and auxiliary modes are potentially unappealing.

--
Jonathan Lennox
lennox@cs.colum= bia.edu
_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

 

 

--Boundary_(ID_/UAT23TixwNhfLr6wA4QRA)-- From miguel.a.garcia@ericsson.com Wed Apr 13 23:01:45 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C6DDE07A3 for ; Wed, 13 Apr 2011 23:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i07Tx3KmkDrC for ; Wed, 13 Apr 2011 23:01:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 0E2D9E06FB for ; Wed, 13 Apr 2011 23:01:42 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-b1-4da68dc58d88 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8B.7B.09202.5CD86AD4; Thu, 14 Apr 2011 08:01:42 +0200 (CEST) Received: from [159.107.24.215] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 08:01:41 +0200 Message-ID: <4DA68DC5.2060608@ericsson.com> Date: Thu, 14 Apr 2011 08:01:41 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] IETF #80 (Prague): draft MoM MMUSIC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:01:45 -0000 The chairs want to share the draft minutes of the MMUSIC meeting that took place in Prague. We are still trying to verify a couple of unclear sentences. Please review it and send comments and amendments. Minutes of the Meeting: MMUSIC working group at IETF 80 -------------------------------------------------------------------------------------- The MMUSIC working group of the IETF met at IETF #80 in Prague, Check Republic. The WG met on April 1st, 2011 from 9 to 11.30. The meeting was chaired by Flemming Andreasen and Miguel A. Garcia. Christer Holmberg and Paul Kyzivat took notes. Wolfgang Weck acted as a jabber scribe. The chairs presented the agenda. No agenda bashing was needed. The chairs presented the status of the working group (see slides). On a call for volunteers to do a last review of RTSP 2.0, Peiyu Yue indicated willingness to review the draft. The chairs presented the proposed new milestones. On RTSP 2.0, Magnus Westerlund indicated that as soon as RTSP 2.0 is submitted for publication to the IESG, we can move forward with the related RTSP extensions. On the forthcoming rfc4566bis, Colin Perkins indicated that he has the XML source of the current rfc4566bis, included some errata fixing, and he will send them to the new editor (Ali Begen). SDP Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The PSTN ---------------------------------------------------------------------------------------------------- Presenter: Simo Veikkolainen Draft: draft-ietf-mmusic-sdp-cs-06 Listed the comments by Paul Kyzivat, and plans to address them. Jonathan Lennox suggested the ABNF change for UUI should not use raw bytes in the SDP – suggested hex for discriminator byte.Flemming recently sent a bunch of comments to the list (not addressed in the presentation). Simo proposed to fix the open issues, submit a new version of that the draft, and then be able to initiate WGLC by June. Title and Bandwidth Capabilities Negotiation in the Session Description ----------------------------------------------------------------------- Presenter: Simo Veikkolainen Draft: draft-mmusic-sdp-icap-bcap-01 John Elwell asked if session-level versus media-level issue isn't already handled by RFC 5939. Simo clarified that RFC 5939 allows extensions to change the default behavior, however the current does not change it – Elwell agreed with that. Charles Eckel questioned about the need and use-cases for the bandwidth capability attribute. A use-case needs to be added to the draft. ICE Updated Offer Problematic ----------------------------- Presenter: Tomas Stach Draft: draft-elwell-mmusic-ice-updated-offer-00 The issues described in the draft, and mechanism proposals on how to solve those, were presented. - ISSUE 1: UPDATE race conditions -- Jonathan Lennox commented that an ICE entity should always know whether an updated offer is expected. So the fax machine should know this and behave appropriately. John Elwell answered that even in this case it doesn’t know how long it might have to wait for it. Flemming asked for more feedback on ICE in general. Hadriel commented that this isn’t really just an ICE problem – it is a general update problem. Response: yes, but this makes it worse. - ISSUE 2: Interaction with 3PCC Discussion of what is meant by “middlebox”. Conclusion that it does not mean arbitrary B2BUA. Rather the concern is boxes that get media. Indicated that middle boxes that modify SDP will terminate ICE. Chair query if there is an issue for WG to address – not specifically this one, but general problems with ICE. A poll reveals that about 15-20 people have read the draft. Christer is concerned with the restrictions being imposed on the form of the solution. Christer said he felt that if you are going to implement ICE then implementing 100rel isn’t that much more. Cullen sees many reasons not to require 100rel, etc. Cullen noted that while not every product implements ICE, there are many ICE implementations available today. Cullen stated that maybe we don’t need the extra O/A cycle at all for ICE (some implementations do not do it) – the cases where it is required are places where ICE does not work for other reasons and is not needed. Cullen is concerned with raising the bar for existing implementations. John Elwell noted that there are classes of devices where ICE is not widely implemented today, and there are barriers to implementing ICE for certain types of applications, and we should address those. Elwell agreed that we should not raise the bar for other implementations (incl. e.g. RTCWeb). Conclusions: more discussions are required, including clarification on scope of what we are looking at. Media level ice-options SDP attribute ------------------------------------- Presenter: Marc Petit-Huguenin Draft: draft-petithuguenin-mmusic-ice-attributes-level-00 Marc indicated that this draft has come from implementation experiences. J. Lennox questioned whether aggregation works when if you have two m= lines, one of which supports ICE and the other does not. John Elwell suggested that if SPLICES is the only motivation for this, then perhaps we should wait for SPLICES to get further. Marc clarified that this isn’t only related to SPLICES. Andrew Allen indicated that 3GPP has already specified a SPLICES-like mechanism, so they are likely going to have this problem, presumably with ECN, and he is interested in seen the work progressing. Paul Kyzivat and Magnus Westerlund indicated that this draft is important. Conclusion: There was interest in working with the problem defined in the document. DCCP Encapsulation for NAT Traversal (DCCP-UDP) ----------------------------------------------- Presenter: Colin Perkins Draft: draft-ietf-dccp-udpencap-07 The main issue is how to signal the support of DCCP encapsulated in UDP in SDP. -- Alt 1: Attribute with port number -- Alt 2: New m= proto type Various alternatives presented from floor. Jonathan Lennox said this is likely to be used in conjunction with ICE, so could offer ICE candidates of both types and let the ice negotiation sort out which one works. Cullen thinks it is complicated to have two port numbersbecause many APIs etc only support one port number. He says that when doing this, should require UDP port and DCCP port to be the same. Flemming supported Cullen – do not introduce two ports into SDP for this. Flemming advocated for the usa of existing frameworks (CapNeg, ICE). Hadriel said aligning the port numbers is not feasible with SBCs, they will change the UDP port but not the DCCP port. Lennox noted that SDP transport protocol field covers both transport protocol and higher level profile (e.g. RTP); we are looking at pure transport protocol here and hence should use ICE. Christer indicated yet a third mechanism: grouping framework. Gonzalo indicated that the same issue exists for SCTP, as it is likely to be encapsulated in UDP, so we should do the same thing. Conclusion: - Different mechanisms were proposed: ICE, SDP CapNeg, SDP grouping framework. - Indicated that a similar issue exists for SCTP, and that we should aim to come up with a generic solution that can be used also for that. SCTP-Based Media Transport in the SDP ------------------------------------- Presenter: Salvatore Loreto Draft: draft-loreto-mmusic-sctp-sdp-07 Salvatore addressed comments by Paul Kyzivat that didn't go to the list. Only plan to use one media stream per connection. Propose to always use stream 0. Jonathan Lennox says there are similar issues in “multi-path RTP” in AVTCORE. Should align efforts. Hadriel asks if there is a use case for this – why use SCTP for media? He says it is a huge amount of work to extend ICE to do multiple connectivity checks and have more than one being used. He points out that SCTP doesn’t go through NATs at all right now. Cullen asks what is advantage of this compared to TCP if you can only use one stream. Cullen furthermore noted that anything that will get to multi-stream support will greatly complicate ICE. Magnus Westerlund indicated that SCTP solves framing and the head of line blocking. Gonzalo Camarillo had heard of use cases for setting up SCTP streams via SDP, and then do signaling on top of them. Conclusion: - Further discussions are needed in order to clarify the scope of the proposed work (including whether NAT and/or UDP is in scope or not). Grouping of Adjacent Media in the SDP ------------------------------------- Presenter: Cullen Jennings Draft: draft-jennings-mmusic-adjacent-grouping-03 Cullen highlighted differences from CLUE WG cases, that the mechanism is purely declarative, and that the draft should not talk about telepresence. Christer says it is not negotiation – it is declaration, and so he thinks it should not be SDP. Someone suggested the word “declarative”. Brian Rosen agreed it is a different problem, but clue has a similar issue – what goes on left, middle, right. So he suggests we want to end up with some common mechanisms. He asked if we could hold off a little bit. Steve Bosco is also concerned with overlap. Cullen is concerned that timeframes are incompatible. Peter Musgrave doesn’t want to couple it to CLUE and noted he likes it. Magnus had some technical issues, but Cullen is not concerned about technical details – just if this is work we want to do. Charles thought CLUE WG might be able to use this. Hadriel, after some historical grumbling, agreed this should go and not block waiting for CLUE. Allyn sees difference – thinks clue will not be able to use SDP for its comparable function. But she disagreed with Cullen’s description of CLUE. Conclusion: continue list discussion. Updated draft needs to clarify relationship (or lack of) with CLUE. SDP 'trafficclass' Attribute ---------------------------- Presenter: James Polk Draft: draft-polk-mmusic-traffic-class-for-sdp-01 This work has been hummed in TSVWG but not yet an official WG. James asks for cooperative work between the areas on this. James thinks transport needs to be involved – either chairs working together or ADs working together. Indicated that the meaning of different attribute values needs to be defined. Lots of discussion over definitions of these labels, e.g. - Should not have more labels than clear use cases - Some labels are not always clear-cut, leaving the implementer with ambiguity. Need more clarity on this. - Confusion on hierarchical aspect – not clear the categories are really hierarchical Christer suggests a framework where other groups define specific trafficclass values. It is indicated that there needs to be e.g. some global registry (e.g., IANA), where values are defined, so that everyone has the same understanding on what the value means. Conclusion: - Continue list discussion. - Chairs to investigate cooperation with transport. SDP attribute to signal parallax -------------------------------------- Presenter: Bert Greevenbosch Draft: draft-greevenbosch-mmusic-parallax-attribute-00 Jonathan Lennox commented that there is nothing in SDP that indicates the different streams are overlapped on display. Steve Bosco concerned that units are pixels but without info about the resolution of the displays. Conclusion: continue list discussion Signal 3D format ----------------------- Presenter: Bert Greevenbosch Draft: draft-greevenbosch-mmusic-signal-3d-format-00 Comment on 3d format that three types are mentioned but there is a 4th type of note that is not mentioned. Why? Thomas Schierl questions on the AVC codec, whether it fits here. Roni Even is concerned about having different ways of conveying this info – whether this should be handled by the codec, vs. multiple RDP requiring multiple codecs, etc. Andrew Allen asked if this could use Cullen’s grid stuff to describe arrangement of streams. Conclusion: continue list discussion. Temporal Interleaving Attribute SDP --------------------------------------------- Presenter: Ali Begen Draft:draft-begen-mmusic-temporal-interleaving-01 Colin Perkins questioned terminology – ‘interleaving’ vs. ‘delay’. Agreement that ‘delay’ is more precise. Conclusion: continue list discussion. Redundancy Grouping Semantics in SDP ------------------------------------------------- Presenter: Ali Begen Draft:draft-begen-mmusic-redundancy-grouping-00 Comment from Colin that the redundancy impacts RTCP statistics, and generally breaks RTCP – should be brought to one of the AVT groups. Conclusion: continue list discussion. Cheers, Flemming and Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gorry@erg.abdn.ac.uk Thu Apr 14 08:52:41 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3408CE0663 for ; Thu, 14 Apr 2011 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyX09fhDN+Is for ; Thu, 14 Apr 2011 08:52:40 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfc.amsl.com (Postfix) with ESMTP id 4E511E06A4 for ; Thu, 14 Apr 2011 08:52:40 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk ([IPv6:2001:630:241:207:21f:5bff:fe38:7354]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p3EFqVra011126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Apr 2011 16:52:31 +0100 (BST) Message-ID: <4DA71840.90906@erg.abdn.ac.uk> Date: Thu, 14 Apr 2011 16:52:32 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4D933186.2030804@erg.abdn.ac.uk> <4D94E5F6.90004@cisco.com> <4D94F905.4070307@cisco.com> <4DA4367C.9010104@ericsson.com> In-Reply-To: <4DA4367C.9010104@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Thu, 14 Apr 2011 09:35:52 -0700 Cc: Flemming Andreasen , Jonathan Lennox , "mmusic@ietf.org" , Pasi Sarolahti Subject: Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:52:41 -0000 On 12/04/2011 12:24, Gonzalo Camarillo wrote: > Hi, > >>> This is the one point on which I disagree -- this is a choice of >>> alternate transports, so it's more like ICE than CapNeg, it seems to me. >>> >> I think it depends on what you are trying to do: Negotiate use of a >> mechanism that both sides support or find a mechanism that can establish >> connectivity as verified by ICE. It's probably quite reasonable to >> support both scenarios. RFC 5939 Section 3.7 has a bit more text around >> this btw. >> >> More discussion/opinions on this point would be useful. > > theoretically, I agree there are two scenarios. However, in practice, > endpoints are interested in establishing the best possible connection. > ICE allows the endpoints to decide what "the best" means to them. It may > be the connection that can be established the fastest, or the connection > with the lowest delay, or whatever. Therefore, endpoints will try every > possible path until they find the best according to their definition. > > Why would two endpoints want to limit themselves to only try > DCCP-over-IP paths or DCCP-over-UDP paths when they can try both and > pick the best? Do you have any scenario in mind where endpoints are > constrained to only try one type of path for some reason? > > Cheers, > > Gonzalo > From a transport perspective, there could be things that are not immediately apparent: e.g. you may prefer IP encaps in some cases, if the app wanted to use ECN support, DCCP's Path MTU Discovery, Partial Checksum, etc these may all offer complete functionality via IP, but may not work (well) via UDP. Gorry From ted.ietf@gmail.com Thu Apr 14 11:49:01 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D82FE073F for ; Thu, 14 Apr 2011 11:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODbJ17t2y2QJ for ; Thu, 14 Apr 2011 11:49:00 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id E526FE073E for ; Thu, 14 Apr 2011 11:48:59 -0700 (PDT) Received: by pwi5 with SMTP id 5so927230pwi.31 for ; Thu, 14 Apr 2011 11:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aBeTRR9ix1iHJNtk2SFux3MykpxKAcnGVSMww77Mdf4=; b=gBLdiomkDmjJaXXLXOnJA4IqCDUVe7XtGSgHIpY7e2kY6Qy6iuIkp9sUFKKvE6VTlJ 3BKudr3BTc2cnpfcvF6uFNlYSgyGyRifDDY5MQj5+C8++3Se2Xrh0UKrhslzu6ummVsl qY7cDw1jKkn5feutk2CiQMjs9i4DPhSyQiBR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nXd0kEEe8E+6QrRzSYFJMxarSeh1YBWUU1Q9lZso7umICxArQNJppEWhU8ISTT9CXP 6XvSBclhnNg0HCAn+dnyRklAe24dIyER8jZGT99RnVFIdtmNHhxQH9Ugd2bFHElzu7L6 KIgasPcHq2BMMaNuaAVcfuwBBpqPfwv4ybO58= MIME-Version: 1.0 Received: by 10.68.22.1 with SMTP id z1mr404117pbe.36.1302806939317; Thu, 14 Apr 2011 11:48:59 -0700 (PDT) Received: by 10.68.50.202 with HTTP; Thu, 14 Apr 2011 11:48:59 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> Date: Thu, 14 Apr 2011 11:48:59 -0700 Message-ID: From: Ted Hardie To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=bcaec5216359d434d704a0e56092 Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 14 Apr 2011 18:49:01 -0000 --bcaec5216359d434d704a0e56092 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > I agree, the 30Hz (per view) case would give a flickering effect. Since > normal TVs have a frequency of 60Hz or more, for a similar quality with > shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. > > > > But the receiver can also upsample the received signal to a higher display > rate. For example, if it receives the following frame sequence at 30Hz/view: > > > > L1,R1,L2,R2,L3,R3,..., > > > > then it could display at 60Hz/view: > > > > L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... > > > > The receiver can also use some interpolation technique to generate the > frames between L*k* and L(*k*+1). > > > > I think that in praxis the receiving device will process the received > stream to make it fit the display system. This allows different > types/standards of shutter glasses to be used, independent on the format in > which the 3D stream was received. It also allows other display types such as > polarisation or autostereoscopic displays. > > > My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz *>I know only know one manufacturer's system at all well, and my > understanding is that the timing signals which synchronize them are really > matching the frame start times to the shuttering, but don't adjust the frame > rates. Are there glasses which can modify the rate substantially as well? > * > > > > Can you please explain a bit more about the system you are referring too, > especially about not modifying the frame rate? Do you mean the frame rate > between the TV screen and the signalling device (that transmits the signal > to the shutter glasses) or the frame rate of the video stream as it is > received before it is decoded (by the codec)? > > > I probably should have said "shuttering rate", sorry. I mean that it matches the shutters to the alternating left and right view, but that the shuttering rate is consistent (resulting in 60Hz per view, in this case). regards, Ted Hardie --bcaec5216359d434d704a0e56092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch <<= a href=3D"mailto:Bert.Greevenbosch@huawei.com">Bert.Greevenbosch@huawei.com= > wrote:

I agree, the 30Hz (= per view) case would give a flickering effect. Since normal TVs have a freq= uency of 60Hz or more, for a similar quality with shutter glasses the frame= rate should be 120Hz (=3D60 Hz/view) or more.

=A0

But the receiver ca= n also upsample the received signal to a higher display rate. For example, = if it receives the following frame sequence at 30Hz/view:

=A0

L1,R1,L2,R2,L3,R3,...,

=A0

then it could displ= ay at 60Hz/view:

=A0

L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....

=A0

The receiver can al= so use some interpolation technique to generate the frames between Lk and L(k+1).

=A0

I think that in pra= xis the receiving device will process the received stream to make it fit th= e display system. This allows different types/standards of shutter glasses = to be used, independent on the format in which the 3D stream was received. It= also allows other display types such as polarisation or autostereoscopic d= isplays.

=A0


My suspicion is that there are probably = practical limits to some system's ability to either upsample or interpo= late.=A0 Would it make sense to add something to the 3dFormat line to indic= ate what the resulting per-view rate will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFo= rmat:FP SbS 30Hz



>I know only know one manufacturer's system at all well, an= d my understanding is that the timing signals which synchronize them are re= ally matching the frame start times to the shuttering, but don't adjust the frame rates.=A0 Ar= e there glasses which can modify the rate substantially as well?=

=A0

Can you pleas= e explain a bit more about the system you are referring too, especially abo= ut not modifying the frame rate? Do you mean the frame rate between the TV = screen and the signalling device (that transmits the signal to the shutter glasses) o= r the frame rate of the video stream as it is received before it is decoded= (by the codec)?

=A0


I probably should have said "shuttering r= ate", sorry.=A0 I mean that it matches the shutters to the alternating= left and right view, but that the shuttering rate is consistent (resulting= in 60Hz per view, in this case).

regards,

Ted Hardie
--bcaec5216359d434d704a0e56092-- From fandreas@cisco.com Thu Apr 14 19:44:04 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1E320E07EA for ; Thu, 14 Apr 2011 19:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q9hlvFprTxL for ; Thu, 14 Apr 2011 19:44:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id D3C31E07BD for ; Thu, 14 Apr 2011 19:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=5730; q=dns/txt; s=iport; t=1302835442; x=1304045042; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=KEUuaI6l5Hh3zp6QEbZ+Pgb1/hOQGxZCrmcyjkBrgSE=; b=IeNCQEDbRwX5EXAIEBy2M9qpS5ZfkCK9qS2LKoxYsm0bXbzdQOF/C2JW FM76LYv44yoHDnzOk7o/4bdFCBIUJmXv3wIzttMTK7GgHrYniUs/k5UGW uhOd30ve2nYGn6PLT0UPiD3xkvOyAVA9gpLVFeyAQyx/+Q2jOUf8suCb5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB6wp02tJXG9/2dsb2JhbAClfneIb58RnQ+FbgSNbw X-IronPort-AV: E=Sophos;i="4.64,215,1301875200"; d="scan'208,217";a="681816430" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 02:44:01 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3F2i09W017607; Fri, 15 Apr 2011 02:44:01 GMT Message-ID: <4DA7B0F0.6050307@cisco.com> Date: Thu, 14 Apr 2011 22:44:00 -0400 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: Gonzalo Camarillo References: <4D933186.2030804@erg.abdn.ac.uk> <4D94E5F6.90004@cisco.com> <4D94F905.4070307@cisco.com> <4DA4367C.9010104@ericsson.com> In-Reply-To: <4DA4367C.9010104@ericsson.com> Content-Type: multipart/alternative; boundary="------------020303000104000204040301" Cc: Gorry Fairhurst , Jonathan Lennox , mmusic@ietf.org, Pasi Sarolahti Subject: Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.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, 15 Apr 2011 02:44:04 -0000 This is a multi-part message in MIME format. --------------020303000104000204040301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/12/11 7:24 AM, Gonzalo Camarillo wrote: > > Hi, > > >> This is the one point on which I disagree -- this is a choice of > >> alternate transports, so it's more like ICE than CapNeg, it seems > to me. > >> > > I think it depends on what you are trying to do: Negotiate use of a > > mechanism that both sides support or find a mechanism that can establish > > connectivity as verified by ICE. It's probably quite reasonable to > > support both scenarios. RFC 5939 Section 3.7 has a bit more text around > > this btw. > > > > More discussion/opinions on this point would be useful. > > theoretically, I agree there are two scenarios. However, in practice, > endpoints are interested in establishing the best possible connection. > ICE allows the endpoints to decide what "the best" means to them. It may > be the connection that can be established the fastest, or the connection > with the lowest delay, or whatever. Therefore, endpoints will try every > possible path until they find the best according to their definition. > > Why would two endpoints want to limit themselves to only try > DCCP-over-IP paths or DCCP-over-UDP paths when they can try both and > pick the best? Do you have any scenario in mind where endpoints are > constrained to only try one type of path for some reason? > I can make similar arguments for any choice of SDP "transport protocol", e.g. middleboxes may allow some transports/profiles, but not others, and hence we should always use ICE to just pick one that works. However we have recent examples that do not require ICE to negotiate different transports, e.g DTLS-SRTP (per RFC 5763), not to mention that CapNeg (RFC 5939) was motivated in large part by this use case. At the end of the day, the question is whether we want to always mandate that ICE is implemented in order to negotiate different transports, or whether we stick with recommendations based on the scenario you are concerned with (negotiation or verified connectivity). RFC 5939 Section 3.7 describes this trade-off, and I still believe it to be the correct one, and hence do not think we should mandate one way or the other. Thanks -- Flemming > Cheers, > > Gonzalo > --------------020303000104000204040301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 4/12/11 7:24 AM, Gonzalo Camarillo wrote:
Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.txt

Hi,

>> This is the one point on which I disagree -- this is a choice of
>> alternate transports, so it's more like ICE than CapNeg, it seems to me.
>>
> I think it depends on what you are trying to do: Negotiate use of a
> mechanism that both sides support or find a mechanism that can establish
> connectivity as verified by ICE. It's probably quite reasonable to
> support both scenarios. RFC 5939 Section 3.7 has a bit more text around
> this btw.
>
> More discussion/opinions on this point would be useful.

theoretically, I agree there are two scenarios. However, in practice,
endpoints are interested in establishing the best possible connection.
ICE allows the endpoints to decide what "the best" means to them. It may
be the connection that can be established the fastest, or the connection
with the lowest delay, or whatever. Therefore, endpoints will try every
possible path until they find the best according to their definition.

Why would two endpoints want to limit themselves to only try
DCCP-over-IP paths or DCCP-over-UDP paths when they can try both and
pick the best? Do you have any scenario in mind where endpoints are
constrained to only try one type of path for some reason?

I can make similar arguments for any choice of SDP "transport protocol", e.g. middleboxes may allow some transports/profiles, but not others, and hence we should always use ICE to just pick one that works. However we have recent examples that do not require ICE to negotiate different transports, e.g DTLS-SRTP (per RFC 5763), not to mention that CapNeg (RFC 5939) was motivated in large part by this use case.

At the end of the day, the question is whether we want to always mandate that ICE is implemented in order to negotiate different transports, or whether we stick with recommendations based on the scenario you are concerned with (negotiation or verified connectivity). RFC 5939 Section 3.7 describes this trade-off, and I still believe it to be the correct one, and hence do not think we should mandate one way or the other.

Thanks

-- Flemming

Cheers,

Gonzalo

--------------020303000104000204040301-- From Bert.Greevenbosch@huawei.com Thu Apr 14 23:21:37 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5E20E069D for ; Thu, 14 Apr 2011 23:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=2.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqghj8hjDPWM for ; Thu, 14 Apr 2011 23:21:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id A09FCE0693 for ; Thu, 14 Apr 2011 23:21:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO001W5KBQIT@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 15 Apr 2011 14:21:26 +0800 (CST) Received: from szxeml203-edg.china.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 <0LJO00CQMKBQWI@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 15 Apr 2011 14:21:26 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 14:21:09 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 14:21:24 +0800 Date: Fri, 15 Apr 2011 06:21:24 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.52] To: Ted Hardie Message-id: <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_S0ZqtuDCI19y4dUVviax7g)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUCAFPgEAP/7eJRwgAqv/YD//mkrcACdjgWA//69IJA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 15 Apr 2011 06:21:38 -0000 --Boundary_(ID_S0ZqtuDCI19y4dUVviax7g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ted, My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz We could also consider using the SDP attribute "framerate" (RFC 4566). This attribute would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per view is half of it. Or do you want to indicate the target shutter glass frequency? Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 15 April 2011 02:49 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch > wrote: I agree, the 30Hz (per view) case would give a flickering effect. Since normal TVs have a frequency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. But the receiver can also upsample the received signal to a higher display rate. For example, if it receives the following frame sequence at 30Hz/view: L1,R1,L2,R2,L3,R3,..., then it could display at 60Hz/view: L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... The receiver can also use some interpolation technique to generate the frames between Lk and L(k+1). I think that in praxis the receiving device will process the received stream to make it fit the display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It also allows other display types such as polarisation or autostereoscopic displays. My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz >I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates. Are there glasses which can modify the rate substantially as well? Can you please explain a bit more about the system you are referring too, especially about not modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) or the frame rate of the video stream as it is received before it is decoded (by the codec)? I probably should have said "shuttering rate", sorry. I mean that it matches the shutters to the alternating left and right view, but that the shuttering rate is consistent (resulting in 60Hz per view, in this case). regards, Ted Hardie --Boundary_(ID_S0ZqtuDCI19y4dUVviax7g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Ted,

 

My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate.  Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be?  So that

a=3dFormat:FP SbS

had an additional parameter:

a=3dFormat:FP SbS 30Hz

We could also consider using the SDP attribute "framerate" (RFC 4566). This attribute would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per view is half of it.  Or do you want to indicate the target shutter glass frequency?

 

Best regards,

Bert

 

 

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: 15 April 2011 02:49
To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

 

On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:

I agree, the 30Hz (per view) case would give a flickering effect. Since normal TVs have a frequency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more.

 

But the receiver can also upsample the received signal to a higher display rate. For example, if it receives the following frame sequence at 30Hz/view:

 

L1,R1,L2,R2,L3,R3,...,

 

then it could display at 60Hz/view:

 

L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....

 

The receiver can also use some interpolation technique to generate the frames between Lk and L(k+1).

 

I think that in praxis the receiving device will process the received stream to make it fit the display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It also allows other display types such as polarisation or autostereoscopic displays.

 


My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate.  Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be?  So that

a=3dFormat:FP SbS

had an additional parameter:

a=3dFormat:FP SbS 30Hz


>I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates.  Are there glasses which can modify the rate substantially as well?

 

Can you please explain a bit more about the system you are referring too, especially about not modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) or the frame rate of the video stream as it is received before it is decoded (by the codec)?

 


I probably should have said "shuttering rate", sorry.  I mean that it matches the shutters to the alternating left and right view, but that the shuttering rate is consistent (resulting in 60Hz per view, in this case).

regards,

Ted Hardie

--Boundary_(ID_S0ZqtuDCI19y4dUVviax7g)-- From fandreas@cisco.com Fri Apr 15 08:54:51 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F34C130011; Fri, 15 Apr 2011 08:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlfJf6WNROPV; Fri, 15 Apr 2011 08:54:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 702F2130012; Fri, 15 Apr 2011 08:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=8378; q=dns/txt; s=iport; t=1302882886; x=1304092486; h=message-id:date:from:mime-version:to:cc:subject; bh=bTF00KPrFU/Fic1DhMJl5i09mIdMXDlBXgDqPXyf0DA=; b=kt10TMdoPJC4vKwUiseGc5yq6cZcW4xOx8dya8C2hnCeY7Jl8gCBffh2 wkui2pxUm0Fl/jlonjpmg5xuduQL0Mw63mOVxmqUa/IIsO8CsDgF23Qpv E+F0ubHUdyh0kRmogeG2/+gDJG44ledRHwJkTIyk6S/qh+mOTjLWEc53L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEJpqE2tJV2Z/2dsb2JhbACmBHenSpx+hW4EjXg X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208,217";a="682274216" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 15:54:45 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFsiJG011676; Fri, 15 Apr 2011 15:54:44 GMT Message-ID: <4DA86A44.9040909@cisco.com> Date: Fri, 15 Apr 2011 11:54:44 -0400 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="------------060106050208090804010006" Cc: mmusic-chairs@ietf.org, draft-ietf-mmusic-ice-tcp@tools.ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 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, 15 Apr 2011 15:54:51 -0000 This is a multi-part message in MIME format. --------------060106050208090804010006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-ice-tcp-13 as Proposed Standard. Please review and provide any comments you may have on the document before Monday, May 2nd, 2011. Comments should be sent to the document authors and the MMUSIC WG list. Thanks Flemming & Miguel Draft Info: Title : TCP Candidates with Interactive Connectivity Establishment (ICE) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-mmusic-ice-tcp-13.txt Pages : 29 Date : 2011-04-11 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-13.txt --------------060106050208090804010006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for

    draft-ietf-mmusic-ice-tcp-13

as Proposed Standard. Please review and provide any comments you may have on the document before Monday, May 2nd, 2011. Comments should be sent to the document authors and the MMUSIC WG list.


Thanks

    Flemming & Miguel



Draft Info:

 
	Title           : TCP Candidates with Interactive Connectivity Establishment (ICE)
	Author(s)       : J. Rosenberg, et al.
	Filename        : draft-ietf-mmusic-ice-tcp-13.txt
	Pages           : 29
	Date            : 2011-04-11

Interactive Connectivity Establishment (ICE) defines a mechanism for
NAT traversal for multimedia communication protocols based on the
offer/answer model of session negotiation.  ICE works by providing a
set of candidate transport addresses for each media stream, which are
then validated with peer-to-peer connectivity checks based on Session
Traversal Utilities for NAT (STUN).  ICE provides a general framework
for describing candidates, but only defines UDP-based transport
protocols.  This specification extends ICE to TCP-based media,
including the ability to offer a mix of TCP and UDP-based candidates
for a single stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-13.txt

--------------060106050208090804010006-- From ted.ietf@gmail.com Fri Apr 15 17:35:50 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F8A8E067E for ; Fri, 15 Apr 2011 17:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQdqaZ+uuapZ for ; Fri, 15 Apr 2011 17:35:49 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 10681E0665 for ; Fri, 15 Apr 2011 17:35:48 -0700 (PDT) Received: by pzk30 with SMTP id 30so1517679pzk.31 for ; Fri, 15 Apr 2011 17:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cZkG4l6ZY1Fi1FBxvidOBJ6xmIyDz2zhyPiem+ZEE58=; b=HQ8FhHoY6nr2/FSsfg/OnuP87+sCYfUTfVa5q+fXUy5Qh9lwpmninH1ZdJGCjNzOxG k+TLPA+l8M0ZYt1sydcbpOmEovegyHairb+vzXZl6RoUrcwozPiZzbMY6Je0JMGEN6Bf Fzqi4n3nKy2M+zH6m/HhL8dgdrpebGuGcRJa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AzFrvJ/qXKyR+EHZwsqco4sXE1pKjtbxUDwd63L8zFyZwYppUMUbU8d54CEYpb6K2d OnjYbV1C1maMxyZfVp7gxuMJBpih2O+d3UJfU+qMRC+2rX1CbmwUrc70WJV+HXeQo1Gy 1n+dny7frvkTkDQ2PuzOHpZFMsxdnkx8wPylo= MIME-Version: 1.0 Received: by 10.68.40.38 with SMTP id u6mr2790645pbk.371.1302914148019; Fri, 15 Apr 2011 17:35:48 -0700 (PDT) Received: by 10.68.50.202 with HTTP; Fri, 15 Apr 2011 17:35:47 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> Date: Fri, 15 Apr 2011 17:35:47 -0700 Message-ID: From: Ted Hardie To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=bcaec539634ef72f8904a0fe56d8 Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 16 Apr 2011 00:35:50 -0000 --bcaec539634ef72f8904a0fe56d8 Content-Type: text/plain; charset=ISO-8859-1 Hi, Some further comments in-line. On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi Ted, > > > > My suspicion is that there are probably practical limits to some system's > ability to either upsample or interpolate. Would it make sense to add > something to the 3dFormat line to indicate what the resulting per-view rate > will be? So that > > a=3dFormat:FP SbS > > had an additional parameter: > > a=3dFormat:FP SbS 30Hz > > We could also consider using the SDP attribute "framerate" (RFC 4566). > This attribute would give the frame rate of the 2D channel stream, but we > can write in the draft that in the frame sequential case the frame rate per > view is half of it. > The relevant text from RFC 4566 is: a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "." are allowed. It is a media-level attribute, defined only for video media, and it is not dependent on charset. While I think it could be re-used here, it seems to me to make more sense to use a separate indicator. This is partly because it is more for the decoder/upsampler/interpolation check (Can I upsample this to something reasonable? If not, don't select this choice). And it's partly because I worry a bit about the interaction with existing code. > Or do you want to indicate the target shutter glass frequency? > > > No, I think you're right that it's more likely that things will get adjusted to a standard shutter speed by upsampling than they will change the shutter speed. regards, Ted Hardie > Best regards, > > Bert > > > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* 15 April 2011 02:49 > > *To:* Bert Greevenbosch > *Cc:* lennox@cs.columbia.edu; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Remarks from today > > > > On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > > I agree, the 30Hz (per view) case would give a flickering effect. Since > normal TVs have a frequency of 60Hz or more, for a similar quality with > shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. > > > > But the receiver can also upsample the received signal to a higher display > rate. For example, if it receives the following frame sequence at 30Hz/view: > > > > L1,R1,L2,R2,L3,R3,..., > > > > then it could display at 60Hz/view: > > > > L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... > > > > The receiver can also use some interpolation technique to generate the > frames between L*k* and L(*k*+1). > > > > I think that in praxis the receiving device will process the received > stream to make it fit the display system. This allows different > types/standards of shutter glasses to be used, independent on the format in > which the 3D stream was received. It also allows other display types such as > polarisation or autostereoscopic displays. > > > > > My suspicion is that there are probably practical limits to some system's > ability to either upsample or interpolate. Would it make sense to add > something to the 3dFormat line to indicate what the resulting per-view rate > will be? So that > > a=3dFormat:FP SbS > > had an additional parameter: > > a=3dFormat:FP SbS 30Hz > > > *>I know only know one manufacturer's system at all well, and my > understanding is that the timing signals which synchronize them are really > matching the frame start times to the shuttering, but don't adjust the frame > rates. Are there glasses which can modify the rate substantially as well? > * > > > > Can you please explain a bit more about the system you are referring too, > especially about not modifying the frame rate? Do you mean the frame rate > between the TV screen and the signalling device (that transmits the signal > to the shutter glasses) or the frame rate of the video stream as it is > received before it is decoded (by the codec)? > > > > > I probably should have said "shuttering rate", sorry. I mean that it > matches the shutters to the alternating left and right view, but that the > shuttering rate is consistent (resulting in 60Hz per view, in this case). > > regards, > > Ted Hardie > --bcaec539634ef72f8904a0fe56d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Some further comments in-line.

On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch <= Bert.Greevenbosch@huawei.co= m> wrote:

Hi Ted,

<= div class=3D"im">

=A0

My suspicion is that there are probably practical limits to some syst= em's ability to either upsample or interpolate.=A0 Would it make sense = to add something to the 3dFormat line to indicate what the resulting per-view rate will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz

We could also= consider using the SDP attribute "framerate" (RFC 4566). This at= tribute would give the frame rate of the 2D channel stream, but we can writ= e in the draft that in the frame sequential case the frame rate per view is half of it.=


The relevant text from RFC 4566 is:
a=3Dframerate:<frame rate>

      =
   This gives the maximum video frame rate in frames/sec.  It is

         intended as a recommendation for the encoding of video data.
  =
       Decimal representations of fractional values using the notation
 =
        "<integer>.<fraction>" are allowed.  It is a =
media-level

         attribute, defined only for video media, and it is not
        =
 dependent on charset.
While I think it could be re-used here, it = seems to me to make more sense to use a separate indicator.=A0 This is part= ly because it is more for the decoder/upsampler/interpolation check (Can I = upsample this to something reasonable?=A0 If not, don't select this cho= ice).=A0 And it's partly because I worry a bit about the interaction wi= th existing code.

=A0

= =A0Or do you want to indicate the target = shutter glass frequency?

=A0


No, I think you're right that it's mor= e likely that things will get adjusted to a standard shutter speed by upsam= pling than they will change the shutter speed.

regards,

Ted Hardie
=A0

Best regards,

Bert

=A0

=A0

F= rom: Ted Hardie = [mailto:ted.ietf@gm= ail.com]
Sent: 15 April 2011 02:49


To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

=A0

On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch = <Bert.= Greevenbosch@huawei.com> wrote:

I agree, the 30Hz (= per view) case would give a flickering effect. Since normal TVs have a freq= uency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=3D60 Hz/view) or more.

=A0

But the receiver ca= n also upsample the received signal to a higher display rate. For example, = if it receives the following frame sequence at 30Hz/view:

=A0

L1,R1,L2,R2,L3,R3,...,

=A0

then it could displ= ay at 60Hz/view:

=A0

L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....

=A0

The receiver can al= so use some interpolation technique to generate the frames between Lk and L(k+1).

=A0

I think that in pra= xis the receiving device will process the received stream to make it fit th= e display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D s= tream was received. It also allows other display types such as polarisation= or autostereoscopic displays.

=A0


My suspicion is that there are probably practical limits to some system'= ;s ability to either upsample or interpolate.=A0 Would it make sense to add= something to the 3dFormat line to indicate what the resulting per-view rat= e will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz


>I know only know one manufacturer's system at all well, an= d my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adj= ust the frame rates.=A0 Are there glasses which can modify the rate substan= tially as well?

=A0

Can you please expl= ain a bit more about the system you are referring too, especially about not= modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal= to the shutter glasses) or the frame rate of the video stream as it is rec= eived before it is decoded (by the codec)?

=A0


I probably should have said "shuttering rate", sorry.=A0 I mean t= hat it matches the shutters to the alternating left and right view, but tha= t the shuttering rate is consistent (resulting in 60Hz per view, in this ca= se).

regards,

Ted Hardie


--bcaec539634ef72f8904a0fe56d8-- From miguel.a.garcia@ericsson.com Sun Apr 17 23:58:25 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 95B69E0655 for ; Sun, 17 Apr 2011 23:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWbwKlasYTpe for ; Sun, 17 Apr 2011 23:58:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 61FBDE06C1 for ; Sun, 17 Apr 2011 23:58:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-7a-4dabe10b49eb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.1E.11171.B01EBAD4; Mon, 18 Apr 2011 08:58:20 +0200 (CEST) Received: from [159.107.24.190] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Apr 2011 08:58:19 +0200 Message-ID: <4DABE10B.4000801@ericsson.com> Date: Mon, 18 Apr 2011 08:58:19 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Missing IANA "media" registry in SDP 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: Mon, 18 Apr 2011 06:58:25 -0000 Hi, IANA has just created the "media" in SDP registry. This was created by RFC 4566, but somehow it never got it to IANA. The initial set of registered value are those included in RFC 4566. URL: http://www.iana.org/assignments/sdp-parameters /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Bert.Greevenbosch@huawei.com Mon Apr 18 18:35:50 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 27D3DE0692 for ; Mon, 18 Apr 2011 18:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxSfrt80rQWg for ; Mon, 18 Apr 2011 18:35:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 32AF2E0679 for ; Mon, 18 Apr 2011 18:35:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV000GOLQUJ6@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 19 Apr 2011 09:35:19 +0800 (CST) Received: from szxeml203-edg.china.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 <0LJV006PKLQTS7@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 19 Apr 2011 09:35:18 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 09:35:14 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 09:35:15 +0800 Date: Tue, 19 Apr 2011 01:35:15 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.52] To: "lennox@cs.columbia.edu" Message-id: <46A1DF3F04371240B504290A071B4DB6012C556A@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RKcMbPL6JruM3/fByUunHQ)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: About overlaying subtitles with the "ParallaxInfo" attribute Thread-index: Acv+MggEO/CD8l0vSMyQ2KlrNLs+eQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mmusic@ietf.org" Subject: [MMUSIC] About overlaying subtitles with the "ParallaxInfo" attribute 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, 19 Apr 2011 01:35:50 -0000 --Boundary_(ID_RKcMbPL6JruM3/fByUunHQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Jonathan, During the Prague meeting on the draft-greevenbosch-mmusic-parallax-attribute-00 draft, you commented that there were some issues about the overlay of the subtitles and the video, and how to indicate which overlays which. In the RFC that defines 3GPP timed text streaming over RTP (RFC 4396), an attribute "layer" is defined. It defines the render hierarchy of timed text, i.e. when two timed text streams overlap, the one with the more negative "layer" value will be rendered over the one with the less negative value. This means that the first perceived stream as being in front of the second stream. The "layer" attribute is optional, and specific to RFC 4396. For streams with the "ParallaxInfo" attribute, I have always thought of them as overlapping the main video content. I hinted at this in the informative section, but maybe we should write this more explicitly in the draft. There is also a relationship between parallax and layers, especially since a more negative parallax value also indicates positioning nearer to the viewer. However, the "ParallaxInfo" contains more information than the "layer" attribute, as the first describes the exact positioning in the virtual 3D space, whereas the second only defines whether the stream is closer or further away than other streams. But in general we could say that if the "ParallaxInfo" attribute of one stream is more negative than of another stream, the "layer" attribute of the first should be more negative than the "layer" attribute of the second too. What do you think? Best regards, Bert --Boundary_(ID_RKcMbPL6JruM3/fByUunHQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Jonathan,

 

During the Prague meeting on the draft-greevenbosch-mmusic-parallax-attribute-00 draft, you commented that there were some issues about the overlay of the subtitles and the video, and how to indicate which overlays which.

 

In the RFC that defines 3GPP timed text streaming over RTP (RFC 4396), an attribute "layer" is defined. It defines the render hierarchy of timed text, i.e. when two timed text streams overlap, the one with the more negative "layer" value will be rendered over the one with the less negative value. This means that the first perceived stream as being in front of the second stream. The "layer" attribute is optional, and specific to RFC 4396.

 

For streams with the "ParallaxInfo" attribute, I have always thought of them as overlapping the main video content. I hinted at this in the informative section, but maybe we should write this more explicitly in the draft.

 

There is also a relationship between parallax and layers, especially since a more negative parallax value also indicates positioning nearer to the viewer. However, the "ParallaxInfo" contains more information than the "layer" attribute, as the first describes the exact positioning in the virtual 3D space, whereas the second only defines whether the stream is closer or further away than other streams. But in general we could say that if the "ParallaxInfo" attribute of one stream is more negative than of another stream, the "layer" attribute of the first should be more negative than the "layer" attribute of the second too.

 

What do you think?

 

Best regards,

Bert

--Boundary_(ID_RKcMbPL6JruM3/fByUunHQ)-- From Bert.Greevenbosch@huawei.com Mon Apr 18 19:52:52 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF973E0710 for ; Mon, 18 Apr 2011 19:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[AWL=1.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mdCNTvjghWf for ; Mon, 18 Apr 2011 19:52:51 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 4A952E06AB for ; Mon, 18 Apr 2011 19:52:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00KGSPBZUX@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 19 Apr 2011 10:52:47 +0800 (CST) Received: from szxeml206-edg.china.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 <0LJV00AWSPBZT8@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 19 Apr 2011 10:52:47 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 10:52:43 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 10:52:41 +0800 Date: Tue, 19 Apr 2011 02:52:40 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.52] To: Ted Hardie Message-id: <46A1DF3F04371240B504290A071B4DB6012C55AA@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Gve/8m/6UHVvPY+NQx/xXA)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUCAFPgEAP/7eJRwgAqv/YD//mkrcACdjgWA//69IJD//MnmgP/0M8AA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 19 Apr 2011 02:52:52 -0000 --Boundary_(ID_Gve/8m/6UHVvPY+NQx/xXA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ted, If I understand you well, you would like to be able to negotiate the video frequency, such that it can easily be converted to the shutter glass frequency. So for example, if the shutter glass frequency is 120Hz (60Hz/view), then reasonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of 60Hz (or in the Frame Sequential case, 120Hz). In this case it is easy to upsample the signal by repeating each frame sequence {Lk Rk} an integer number of times. I have a preference to use the "framerate" attribute for this, as adding another rather similar parameter to the "3dFormat" attribute seems somehow double. However, I also see your point in that the "framerate" attribute only indicates a maximum frequency, not a guaranteed frequency. We could solve this in the draft by mandating that in case of 3D streaming, the frequency the video MUST equal the value of the "framerate" attribute, in case the "framerate" attribute is included. What do you think? Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 16 April 2011 08:36 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today Hi, Some further comments in-line. On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch > wrote: Hi Ted, My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz We could also consider using the SDP attribute "framerate" (RFC 4566). This attribute would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per view is half of it. The relevant text from RFC 4566 is: a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "." are allowed. It is a media-level attribute, defined only for video media, and it is not dependent on charset. While I think it could be re-used here, it seems to me to make more sense to use a separate indicator. This is partly because it is more for the decoder/upsampler/interpolation check (Can I upsample this to something reasonable? If not, don't select this choice). And it's partly because I worry a bit about the interaction with existing code. Or do you want to indicate the target shutter glass frequency? No, I think you're right that it's more likely that things will get adjusted to a standard shutter speed by upsampling than they will change the shutter speed. regards, Ted Hardie Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 15 April 2011 02:49 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch > wrote: I agree, the 30Hz (per view) case would give a flickering effect. Since normal TVs have a frequency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. But the receiver can also upsample the received signal to a higher display rate. For example, if it receives the following frame sequence at 30Hz/view: L1,R1,L2,R2,L3,R3,..., then it could display at 60Hz/view: L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... The receiver can also use some interpolation technique to generate the frames between Lk and L(k+1). I think that in praxis the receiving device will process the received stream to make it fit the display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It also allows other display types such as polarisation or autostereoscopic displays. My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz >I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates. Are there glasses which can modify the rate substantially as well? Can you please explain a bit more about the system you are referring too, especially about not modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) or the frame rate of the video stream as it is received before it is decoded (by the codec)? I probably should have said "shuttering rate", sorry. I mean that it matches the shutters to the alternating left and right view, but that the shuttering rate is consistent (resulting in 60Hz per view, in this case). regards, Ted Hardie --Boundary_(ID_Gve/8m/6UHVvPY+NQx/xXA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Ted,

 

If I understand you well, you would like to be able to negotiate the video frequency, such that it can easily be converted to the shutter glass frequency.

 

So for example, if the shutter glass frequency is 120Hz (60Hz/view), then reasonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of 60Hz (or in the Frame Sequential case, 120Hz). In this case it is easy to upsample the signal by repeating each frame sequence {Lk Rk} an integer number of times.

 

I have a preference to use the "framerate" attribute for this, as adding another rather similar parameter to the "3dFormat" attribute seems somehow double. However, I also see your point in that the "framerate" attribute only indicates a maximum frequency, not a guaranteed frequency. We could solve this in the draft by mandating that in case of 3D streaming, the frequency the video MUST equal the value of the "framerate" attribute, in case the "framerate" attribute is included.

 

What do you think?

 

Best regards,

Bert

 

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: 16 April 2011 08:36
To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

 

Hi,

Some further comments in-line.

On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:

Hi Ted,

 

My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate.  Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be?  So that

a=3dFormat:FP SbS

had an additional parameter:

a=3dFormat:FP SbS 30Hz

We could also consider using the SDP attribute "framerate" (RFC 4566). This attribute would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per view is half of it.


The relevant text from RFC 4566 is:

a=framerate:<frame rate>



         This gives the maximum video frame rate in frames/sec.  It is




         intended as a recommendation for the encoding of video data.

         Decimal representations of fractional values using the notation

         "<integer>.<fraction>" are allowed.  It is a media-level




         attribute, defined only for video media, and it is not

         dependent on charset.

While I think it could be re-used here, it seems to me to make more sense to use a separate indicator.  This is partly because it is more for the decoder/upsampler/interpolation check (Can I upsample this to something reasonable?  If not, don't select this choice).  And it's partly because I worry a bit about the interaction with existing code.

 

 Or do you want to indicate the target shutter glass frequency?

 


No, I think you're right that it's more likely that things will get adjusted to a standard shutter speed by upsampling than they will change the shutter speed.

regards,

Ted Hardie
 

Best regards,

Bert

 

 

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: 15 April 2011 02:49


To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

 

On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:

I agree, the 30Hz (per view) case would give a flickering effect. Since normal TVs have a frequency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more.

 

But the receiver can also upsample the received signal to a higher display rate. For example, if it receives the following frame sequence at 30Hz/view:

 

L1,R1,L2,R2,L3,R3,...,

 

then it could display at 60Hz/view:

 

L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....

 

The receiver can also use some interpolation technique to generate the frames between Lk and L(k+1).

 

I think that in praxis the receiving device will process the received stream to make it fit the display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It also allows other display types such as polarisation or autostereoscopic displays.

 


My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate.  Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be?  So that

a=3dFormat:FP SbS

had an additional parameter:

a=3dFormat:FP SbS 30Hz

>I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates.  Are there glasses which can modify the rate substantially as well?

 

Can you please explain a bit more about the system you are referring too, especially about not modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) or the frame rate of the video stream as it is received before it is decoded (by the codec)?

 


I probably should have said "shuttering rate", sorry.  I mean that it matches the shutters to the alternating left and right view, but that the shuttering rate is consistent (resulting in 60Hz per view, in this case).

regards,

Ted Hardie

 

--Boundary_(ID_Gve/8m/6UHVvPY+NQx/xXA)-- From Bert.Greevenbosch@huawei.com Tue Apr 19 00:31:03 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ABE6FE06B0 for ; Tue, 19 Apr 2011 00:31:03 -0700 (PDT) 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.649, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kPh-tmKrihH for ; Tue, 19 Apr 2011 00:31:03 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id D4667E0674 for ; Tue, 19 Apr 2011 00:31:02 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJW00FOU256W1@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 19 Apr 2011 15:29:30 +0800 (CST) Received: from szxeml206-edg.china.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 <0LJW00DUM254BH@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 19 Apr 2011 15:29:30 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 15:29:25 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 15:29:26 +0800 Date: Tue, 19 Apr 2011 07:29:25 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.52] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012C561F@SZXEML501-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: About measurement unit for ParallaxInfo Thread-index: Acv+Y4J+ebyiU5SZQi2ABUx1WJDcBA== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [MMUSIC] About measurement unit for ParallaxInfo 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, 19 Apr 2011 07:31:03 -0000 Hi all, During the Prague meeting, there was a question about the measurement unit of the "ParallaxInfo" attribute. Currently, this unit is pixels, but I was asked if it would make sense to use another unit, for example cm, to cater for different screen sizes and resolutions. As many before me, I did some calculations. The results match similar calculations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the parallax P is a hyperbolic function of the depth Z (where Z=0 corresponds to the position of the screen itself). The function P(Z) has a zero at screen depth, a vertical asymptote at the viewing distance and a horizontal asymptote of the distance between the eyes. Near to the screen, P(Z) can be approximated by a line, that goes trough (Z=0,P=0). It has the form (1) P(Z) ~= A*Z, where A depends on the x- and z-positions of the left and right eyes. (In the calculations, I have neglected y, leading to a small bias.) Since formula (1) is linear, near to the screen, multiplying the parallax by a certain factor results in increasing the depth by approximately the same factor. This is desirable, since if in one representation the horizontal and vertical distances are twice as big as in another, it is natural that the depth is twice as big as well. If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, then the parallax in pixels will be smaller on a small screen than on a big screen. But since the rest of the video is equally smaller, through (1) the complete picture remains in sync (assuming the depth range is not too large). So I think the unit "pixels" is appropriate for the ParallaxInfo attribute. We might want to add some text clarifying that the parallax suits the pixel width and height of the video. Any opinions on this? Best regards, Bert From stephen.botzko@gmail.com Tue Apr 19 03:17:28 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3FD1DE0680 for ; Tue, 19 Apr 2011 03:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfv4k1aZGOti for ; Tue, 19 Apr 2011 03:17:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 45287E0665 for ; Tue, 19 Apr 2011 03:17:27 -0700 (PDT) Received: by vws12 with SMTP id 12so5234544vws.31 for ; Tue, 19 Apr 2011 03:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g/QjIYKDfx/VBpv7sxb6Y//rKSah5lRnb7nr3JTgcbQ=; b=gvBoSyN8CqNONP7xlDNxcJafr++fU2JDqi5e8Hy05G/M9S4BcewCXTivpTtOGcEapI miwiE5rErukzErQORiXqOfw2POlJU9soQk53ELDAj5FOb5dcK/ESMsE4ji54E3S14W+v qTZiseJ+Gz9dVrYoNMpjRRqEmEcTuNnbtTyXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CVN6q24ooJhV3po9VEGWY/N0QmSIo1lc+3n2Oqi5Pq4D5RxN+pXtraNuTjXANsN90f MD/sBhuP8o8/c0SEMYamEnfRU75erb+3doCFnY1cKFTI0dllwjOEKeq05vDxGqv4uoY5 gVgyEWKhSZ46soL3LG6nbu1DQgo7Sa7UAIbb4= MIME-Version: 1.0 Received: by 10.52.91.232 with SMTP id ch8mr1510336vdb.85.1303208246820; Tue, 19 Apr 2011 03:17:26 -0700 (PDT) Received: by 10.52.168.6 with HTTP; Tue, 19 Apr 2011 03:17:26 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C561F@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012C561F@SZXEML501-MBS.china.huawei.com> Date: Tue, 19 Apr 2011 06:17:26 -0400 Message-ID: From: Stephen Botzko To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=20cf307c9c3c9ebe1304a142d0b9 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] About measurement unit for ParallaxInfo 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, 19 Apr 2011 10:17:28 -0000 --20cf307c9c3c9ebe1304a142d0b9 Content-Type: text/plain; charset=ISO-8859-1 Thx for the formula / followup. The screen resolution is not known though. With H.264 all you know is the profile/level. Regards, Stephen Botzko On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi all, > > During the Prague meeting, there was a question about the measurement unit > of the "ParallaxInfo" attribute. Currently, this unit is pixels, but I was > asked if it would make sense to use another unit, for example cm, to cater > for different screen sizes and resolutions. > > As many before me, I did some calculations. The results match similar > calculations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the > parallax P is a hyperbolic function of the depth Z (where Z=0 corresponds to > the position of the screen itself). The function P(Z) has a zero at screen > depth, a vertical asymptote at the viewing distance and a horizontal > asymptote of the distance between the eyes. > > Near to the screen, P(Z) can be approximated by a line, that goes trough > (Z=0,P=0). It has the form > > (1) P(Z) ~= A*Z, > > where A depends on the x- and z-positions of the left and right eyes. (In > the calculations, I have neglected y, leading to a small bias.) > > Since formula (1) is linear, near to the screen, multiplying the parallax > by a certain factor results in increasing the depth by approximately the > same factor. This is desirable, since if in one representation the > horizontal and vertical distances are twice as big as in another, it is > natural that the depth is twice as big as well. > > If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, then > the parallax in pixels will be smaller on a small screen than on a big > screen. But since the rest of the video is equally smaller, through (1) the > complete picture remains in sync (assuming the depth range is not too > large). > > So I think the unit "pixels" is appropriate for the ParallaxInfo attribute. > We might want to add some text clarifying that the parallax suits the pixel > width and height of the video. > > Any opinions on this? > > Best regards, > Bert > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --20cf307c9c3c9ebe1304a142d0b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thx for the formula / followup.

The screen resolution is not known t= hough.=A0 With H.264 all you know is the profile/level.

Regards,
= Stephen Botzko

On Tue, Apr 19, 2011 at 3:= 29 AM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:
Hi all,

During the Prague meeting, there was a question about the measurement unit = of the "ParallaxInfo" attribute. Currently, this unit is pixels, = but I was asked if it would make sense to use another unit, for example cm,= to cater for different screen sizes and resolutions.

As many before me, I did some calculations. The results match similar calcu= lations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the parallax P= is a hyperbolic function of the depth Z (where Z=3D0 corresponds to the po= sition of the screen itself). The function P(Z) has a zero at screen depth,= a vertical asymptote at the viewing distance and a horizontal asymptote of= the distance between the eyes.

Near to the screen, P(Z) can be approximated by a line, that goes trough (Z= =3D0,P=3D0). It has the form

(1) =A0 =A0 P(Z) ~=3D A*Z,

where A depends on the x- and z-positions of the left and right eyes. (In t= he calculations, I have neglected y, leading to a small bias.)

Since formula (1) is linear, near to the screen, multiplying the parallax b= y a certain factor results in increasing the depth by approximately the sam= e factor. This is desirable, since if in one representation the horizontal = and vertical distances are twice as big as in another, it is natural that t= he depth is twice as big as well.

If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, then = the parallax in pixels will be smaller on a small screen than on a big scre= en. But since the rest of the video is equally smaller, through (1) the com= plete picture remains in sync (assuming the depth range is not too large).<= br>
So I think the unit "pixels" is appropriate for the ParallaxInfo = attribute. We might want to add some text clarifying that the parallax suit= s the pixel width and height of the video.

Any opinions on this?

Best regards,
Bert
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--20cf307c9c3c9ebe1304a142d0b9-- From huiyu@huawei.com Tue Apr 19 22:45:38 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 62AFBE0713 for ; Tue, 19 Apr 2011 22:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=2.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6skZWYxmgO2 for ; Tue, 19 Apr 2011 22:45:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id B6CC2E06ED for ; Tue, 19 Apr 2011 22:45:35 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00DUMRZW1U@szxga03-in.huawei.com> for mmusic@ietf.org; Wed, 20 Apr 2011 13:45:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00DTIRZWF3@szxga03-in.huawei.com> for mmusic@ietf.org; Wed, 20 Apr 2011 13:45:32 +0800 (CST) Received: from h45037b ([10.138.73.44]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJX009UURZVK8@szxml06-in.huawei.com> for mmusic@ietf.org; Wed, 20 Apr 2011 13:45:32 +0800 (CST) Date: Wed, 20 Apr 2011 13:45:27 +0800 From: huiyu In-reply-to: To: 'Stephen Botzko' Message-id: <001101cbff1e$2914ec90$7b3ec5b0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HGybl5JerisJUzxDDamdOw)" Content-language: zh-cn Thread-index: Acv+exNkEQnZN7AqR1eFolWYY2C+owAjwe4w References: <46A1DF3F04371240B504290A071B4DB6012C561F@SZXEML501-MBS.china.huawei.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] About measurement unit for ParallaxInfo 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, 20 Apr 2011 05:45:38 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HGybl5JerisJUzxDDamdOw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi,all =20 The SDP "ParallaxInfo" attribute is actually computed relative to a reference screen, which has a fixed screen resolution . The reference screen has a screen resolution of 11520 horizontal = pixels . The number has been standardized by the SMPTE . =20 The SDP "ParallaxInfo" attribute indicates the parallax in units of = pixels related to reference screen with 11,520 horizontal pixels. =20 The transformation from the reference parallax in pixels to the actual parallax in pixels for different display sizes shall be as follows: PARALLAX=3D parallax/[11520/ W_pix] =20 PARALLAX means the parallax in the actual screen in units of pixels. W_pix means the horizontal pixels of the actual screen solution. parallax is the 'parallax' value in the SDP "ParallaxInfo" attribute = line in units of pixels. =20 Because there may be master spatial resolutions for which [PARALLAX ] = cannot be readily derived by dividing by an integer. so the resulting [PARALLAX = ] value shall be appropriately rounded to the nearest integer value." = Here =A1=AE[11520/ W_pix]=A1=AF means the resulting value shall be rounded = to the nearest integer. =20 =20 As for 11520, SMPTE provide the following reasoning: The reason for this particular reference display value is that the = native parallax Value of the three most popular standards for horizontal = resolution can be readily derived from the display value by dividing by an integer, = as follows: o 1920 horizontal pixels =3D 11,520 / 6 o 1440 horizontal pixels =3D 11,520 / 8 o 1280 horizontal pixels =3D 11,520 / 9 =20 =20 =20 The following illustrates the processing of deducing the = transformation. =20 In MPEG-C part 3, ISO/IEC 23002-3=A3=ACthe formula P/P_ref=3DW/W_ref = demonstrates the transformation of parallax from a reference screen to a actual = screen, although it is just approximate.=20 =20 The unit of all parameters can be 'cm'.=20 'W_ref' means the horizontal screen size of the reference screen. 'w' means the horizontal screen size of the actual screen. 'P_ref' means the parallax in the reference screen. 'P' means the parallax in the actual screen. =20 According to the physical size of each pixel in screen, we can change = the unit of 'cm' to the unit of 'pixel' . the parallax of the reference screen in units of pixels can be = expressed as P_refpix, the horizontal screen size of the reference screen in units of pixels = can be expressed as W_refpix, =20 the parallax in the actual screen in units of pixels can be expressed = as P_pix, the horizontal screen size of the actual screen in units of pixels = can be expressed as W_pix, =20 so it has : W_refpix/P_refpix=3DW_ref/P_ref; W_pix/P_pix=3DW/P; =20 According to the above formulas, it has: P_pix=3D P_refpix/( = W_refpix / W_pix) . =20 Correspondingly,=20 the value of W_refpix is 11520,=20 P_refpix is the 'parallax' value in the SDP "ParallaxInfo" = attribute line .=20 the value of W_pix is the horizontal pixels of actual screen = solution. then P_pix is the actual parallax in actual screen, it can also be transformed to cm according to the physical size of each pixel. =20 So this formula P_pix=3D P_refpix/( W_refpix / W_pix) corresponds to = the previous transformation formula. In summary, we reference the SMPTE standard , and choose 11520 as = the horizontal pixels of the reference screen solution , and define the transformation. we will add some text clarifying the transformation of parallax. =20 =20 Best regards, HuiYu =20 =20 =20 =B7=A2=BC=FE=C8=CB: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] =B4=FA=B1=ED Stephen Botzko =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C219=C8=D5 18:17 =CA=D5=BC=FE=C8=CB: Bert Greevenbosch =B3=AD=CB=CD: mmusic@ietf.org =D6=F7=CC=E2: Re: [MMUSIC] About measurement unit for ParallaxInfo =20 Thx for the formula / followup. The screen resolution is not known though. With H.264 all you know is = the profile/level. Regards, Stephen Botzko On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch wrote: Hi all, During the Prague meeting, there was a question about the measurement = unit of the "ParallaxInfo" attribute. Currently, this unit is pixels, but I = was asked if it would make sense to use another unit, for example cm, to = cater for different screen sizes and resolutions. As many before me, I did some calculations. The results match similar calculations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the parallax P is a hyperbolic function of the depth Z (where Z=3D0 = corresponds to the position of the screen itself). The function P(Z) has a zero at = screen depth, a vertical asymptote at the viewing distance and a horizontal asymptote of the distance between the eyes. Near to the screen, P(Z) can be approximated by a line, that goes trough (Z=3D0,P=3D0). It has the form (1) P(Z) ~=3D A*Z, where A depends on the x- and z-positions of the left and right eyes. = (In the calculations, I have neglected y, leading to a small bias.) Since formula (1) is linear, near to the screen, multiplying the = parallax by a certain factor results in increasing the depth by approximately the = same factor. This is desirable, since if in one representation the horizontal = and vertical distances are twice as big as in another, it is natural that = the depth is twice as big as well. If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, = then the parallax in pixels will be smaller on a small screen than on a big screen. But since the rest of the video is equally smaller, through (1) = the complete picture remains in sync (assuming the depth range is not too large). So I think the unit "pixels" is appropriate for the ParallaxInfo = attribute. We might want to add some text clarifying that the parallax suits the = pixel width and height of the video. Any opinions on this? Best regards, Bert _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 --Boundary_(ID_HGybl5JerisJUzxDDamdOw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi,all

 

The SDP  "ParallaxInfo" attribute  is  = actually computed relative to  a reference screen, which has = a  fixed screen resolution .

The  reference screen  has  a   screen = resolution of 11520 horizontal pixels .

The number has been standardized by the SMPTE = .

 

The SDP  "ParallaxInfo" attribute indicates the = parallax in units of pixels related to  reference screen with = 11,520 horizontal pixels.

 

The transformation from the reference parallax in pixels to the = actual parallax in pixels for different display sizes shall be as = follows:

PARALLAX=3D parallax/[11520/ W_pix]

 

PARALLAX  means the parallax in the actual screen in units of = pixels.

W_pix means  the horizontal pixels  of the actual screen = solution.

parallax is  the 'parallax' value in the SDP  = "ParallaxInfo" attribute line  in units of = pixels.

 

Because there may be master spatial resolutions for which [PARALLAX ] = cannot be readily derived by dividing by an integer. so the resulting = [PARALLAX ] value shall be appropriately rounded to the nearest integer = value."  Here  =A1=AE[11520/ W_pix]=A1=AF means  the = resulting value  shall  be rounded to the nearest = integer.

 

 

As for 11520, SMPTE  provide the following = reasoning:

The reason for this particular reference display value is that the = native parallax Value of the three most popular standards for horizontal = resolution can be readily derived from the display value by dividing by = an integer, as follows:

o       1920 horizontal pixels =3D = 11,520 / 6

o       1440 horizontal pixels =3D = 11,520 / 8

o       1280 horizontal pixels =3D = 11,520 / 9

 

 

 

The following illustrates the processing of  deducing the = transformation.

 

In MPEG-C part 3, ISO/IEC 23002-3=A3=AC<= /span>the formula P/P_ref=3DW/W_ref demonstrates the transformation of = parallax from  a reference screen to a actual = screen,

although it is just approximate.

 

 The unit of all parameters can be 'cm'. =

  'W_ref' means the horizontal screen size of the reference = screen.

  'w' means the horizontal screen size of the actual = screen.

  'P_ref'  means the parallax  in the reference = screen.

  'P'  means the parallax  in the actual = screen.

 

According to the physical size of each pixel  in screen, we can = change the unit of 'cm' to the unit of 'pixel' .

  the parallax of the reference screen in units of pixels can be = expressed as P_refpix,

  the horizontal screen size  of the reference screen in = units of pixels can be expressed as W_refpix,  =

  the parallax in the actual screen in units of pixels can = be expressed as P_pix,

  the horizontal screen size  of the actual screen in units = of pixels can be expressed as W_pix,

 

  so it has :

   W_refpix/P_refpix=3DW_ref/P_ref;

   W_pix/P_pix=3DW/P;

 

   According to  the above formulas,  it = has:   P_pix=3D P_refpix/( W_refpix / W_pix) = .

 

   Correspondingly,

   the value of W_refpix is 11520, =

   P_refpix is  the 'parallax' value in the = SDP  "ParallaxInfo" attribute line  . =

   the value of W_pix is the horizontal  pixels = of actual screen  solution.

   then  P_pix  is the actual parallax in actual = screen, it can also be transformed to cm  according to the physical = size of each pixel.

 

So this formula P_pix=3D P_refpix/( W_refpix / W_pix)  = corresponds to the previous transformation = formula.

   In summary, we reference the  SMPTE = standard , and choose 11520  as the horizontal pixels  of the = reference screen solution ,

and define  the transformation.    we will add = some text clarifying the transformation of = parallax.

 

 

Best regards,

HuiYu

 

 

 

=B7=A2=BC=FE=C8=CB: = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] =B4=FA=B1=ED = Stephen = Botzko
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA4=D4=C219=C8=D5 18:17
=CA=D5=BC=FE=C8=CB: Bert = Greevenbosch
=B3=AD=CB=CD: = mmusic@ietf.org
=D6=F7=CC=E2: Re: [MMUSIC] About = measurement unit for ParallaxInfo

 

Thx = for the formula / followup.

The screen resolution is not known = though.  With H.264 all you know is the = profile/level.

Regards,
Stephen = Botzko

On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com= > wrote:

Hi all,

During the Prague meeting, there was a = question about the measurement unit of the "ParallaxInfo" = attribute. Currently, this unit is pixels, but I was asked if it would = make sense to use another unit, for example cm, to cater for different = screen sizes and resolutions.

As many before me, I did some = calculations. The results match similar calculations in MPEG-C part 3, = ISO/IEC 23002-3. It turns out that the parallax P is a hyperbolic = function of the depth Z (where Z=3D0 corresponds to the position of the = screen itself). The function P(Z) has a zero at screen depth, a vertical = asymptote at the viewing distance and a horizontal asymptote of the = distance between the eyes.

Near to the screen, P(Z) can be = approximated by a line, that goes trough (Z=3D0,P=3D0). It has the = form

(1)     P(Z) ~=3D A*Z,

where A depends on = the x- and z-positions of the left and right eyes. (In the calculations, = I have neglected y, leading to a small bias.)

Since formula (1) = is linear, near to the screen, multiplying the parallax by a certain = factor results in increasing the depth by approximately the same factor. = This is desirable, since if in one representation the horizontal and = vertical distances are twice as big as in another, it is natural that = the depth is twice as big as well.

If we have a fixed screen = resolution in pixels, e.g. 1280x720 pixels, then the parallax in pixels = will be smaller on a small screen than on a big screen. But since the = rest of the video is equally smaller, through (1) the complete picture = remains in sync (assuming the depth range is not too large).

So I = think the unit "pixels" is appropriate for the ParallaxInfo = attribute. We might want to add some text clarifying that the parallax = suits the pixel width and height of the video.

Any opinions on = this?

Best = regards,
Bert
_______________________________________________
mm= usic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 

= --Boundary_(ID_HGybl5JerisJUzxDDamdOw)-- From stephen.botzko@gmail.com Wed Apr 20 03:29:33 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2834FE06B1 for ; Wed, 20 Apr 2011 03:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-1.725, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-CxRD+OiEBF for ; Wed, 20 Apr 2011 03:29:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7C863E06A3 for ; Wed, 20 Apr 2011 03:29:27 -0700 (PDT) Received: by vxg33 with SMTP id 33so490797vxg.31 for ; Wed, 20 Apr 2011 03:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e9nxqoRssEhJopDf3APveFUDilu3wmbmsVB7L7ezYPw=; b=mkj6GEX3qBT6lJPKnoH2nkavU/IUks1elG4wI1qdBp3od62iC2nOkU1Sc5FkOK8wmk /236Q8Wacn9q+FpGqwK8A7pl7kD3ueoldSh35u+rU6nav3qO65DmBPzTx7cc+zms/SnH rslQ1sP37uMUnf9YrMwbnnsKgRYWbIBRYY7TU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x1oOEF1I5BMo+irzslm4XquQVHWYsQaE0i/2VJqRkdZ4cQDl8mP2uBy1OoPR3wrWsH aPUoLJg5XXFt3w5QZm6NBHtNKeghWlYIJWTasZ7Ufz1Qxu/+x7bVWDYAk6tpzTy44HzO 9irDSk2TCwGf15y3annrPmA81BzcjqtODFBH0= MIME-Version: 1.0 Received: by 10.52.173.240 with SMTP id bn16mr5359161vdc.245.1303295366972; Wed, 20 Apr 2011 03:29:26 -0700 (PDT) Received: by 10.52.168.6 with HTTP; Wed, 20 Apr 2011 03:29:26 -0700 (PDT) In-Reply-To: <001101cbff1e$2914ec90$7b3ec5b0$@com> References: <46A1DF3F04371240B504290A071B4DB6012C561F@SZXEML501-MBS.china.huawei.com> <001101cbff1e$2914ec90$7b3ec5b0$@com> Date: Wed, 20 Apr 2011 06:29:26 -0400 Message-ID: From: Stephen Botzko To: huiyu Content-Type: multipart/alternative; boundary=bcaec51b199d62c5e504a1571988 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] About measurement unit for ParallaxInfo 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, 20 Apr 2011 10:29:33 -0000 --bcaec51b199d62c5e504a1571988 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I agree that having an implicit reference screen width of 11,520 pixels resolves the problem. This essentially defines the signaled value as a fraction of the screen size (using somewhat unusual but carefully chosen units). An alternative would be to explicitly signal the reference screen width. The only advantage I see to the alternative approach is that it allows an exact representation for other screen widths (such as 1024 for computer screens or 800 for mobile devices). Though this advantage is limited to cases there the text is intended for a narrow range of devices. Regards, Stephen Botzko 2011/4/20 huiyu > Hi,all > > > > *The SDP "ParallaxInfo" attribute is actually computed relative to a > reference screen, which has a fixed screen resolution .* > > *The reference screen has a screen resolution of 11520 horizontal > pixels .* > > *The number has been standardized by the SMPTE .* > > > > The SDP "ParallaxInfo" attribute indicates the parallax in units of pixe= ls > related to reference screen with 11,520 horizontal pixels. > > > > *The transformation from the reference parallax in pixels to the actual > parallax in pixels for different display sizes shall be as follows:* > > *PARALLAX=3D parallax/[11520/ W_pix]* > > > > PARALLAX means the parallax in the actual screen in units of pixels. > > W_pix means the horizontal pixels of the actual screen solution. > > parallax is the 'parallax' value in the SDP "ParallaxInfo" attribute > line in units of pixels. > > > > Because there may be master spatial resolutions for which [PARALLAX ] > cannot be readily derived by dividing by an integer. so the resulting > [PARALLAX ] value shall be appropriately rounded to the nearest integer > value." Here =A1=AE[11520/ W_pix]=A1=AF means the resulting value sha= ll be > rounded to the nearest integer. > > > > > > As for 11520, SMPTE provide the following reasoning: > > The reason for this particular reference display value is that the native > parallax Value of the three most popular standards for horizontal resolut= ion > can be readily derived from the display value by dividing by an integer, = as > follows: > > o 1920 horizontal pixels =3D 11,520 / 6 > > o 1440 horizontal pixels =3D 11,520 / 8 > > o 1280 horizontal pixels =3D 11,520 / 9 > > > > * * > > > > The following illustrates the processing of deducing the transformation. > > > > In MPEG-C part 3, ISO/IEC 23002-3=A3=ACthe formula P/P_ref=3DW/W_ref demo= nstrates > the transformation of parallax from a reference screen to a actual scree= n, > > although it is just approximate. > > > > The unit of all parameters can be 'cm'. > > 'W_ref' means the horizontal screen size of the reference screen. > > 'w' means the horizontal screen size of the actual screen. > > 'P_ref' means the parallax in the reference screen. > > 'P' means the parallax in the actual screen. > > > > According to the physical size of each pixel in screen, we can change th= e > unit of 'cm' to the unit of 'pixel' . > > the parallax of the reference screen in units of pixels can be expresse= d > as P_refpix, > > the horizontal screen size of the reference screen in units of pixels > can be expressed as W_refpix, > > the parallax in the actual screen in units of pixels can be expressed a= s > P_pix, > > the horizontal screen size of the actual screen in units of pixels can > be expressed as W_pix, > > > > so it has : > > W_refpix/P_refpix=3DW_ref/P_ref; > > W_pix/P_pix=3DW/P; > > > > According to the above formulas, it has: P_pix=3D P_refpix/( W_ref= pix > / W_pix) . > > > > Correspondingly, > > the value of W_refpix is 11520, > > P_refpix is the 'parallax' value in the SDP "ParallaxInfo" attribute > line . > > the value of W_pix is the horizontal pixels of actual screen solutio= n. > > then P_pix is the actual parallax in actual screen, it can also be > transformed to cm according to the physical size of each pixel. > > > > So this formula P_pix=3D P_refpix/( W_refpix / W_pix) corresponds to the > previous transformation formula. > > * In summary, we reference the SMPTE standard , and choose 11520 as > the horizontal pixels of the reference screen solution ,* > > *and define the transformation. we will add some text clarifying the > transformation of parallax.* > > > > > > Best regards, > > HuiYu > > > > > > > > *=B7=A2=BC=FE=C8=CB:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf= .org] *=B4=FA=B1=ED *Stephen > Botzko > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA4=D4=C219=C8=D5 18:17 > *=CA=D5=BC=FE=C8=CB:* Bert Greevenbosch > *=B3=AD=CB=CD:* mmusic@ietf.org > *=D6=F7=CC=E2:* Re: [MMUSIC] About measurement unit for ParallaxInfo > > > > Thx for the formula / followup. > > The screen resolution is not known though. With H.264 all you know is th= e > profile/level. > > Regards, > Stephen Botzko > > On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > > Hi all, > > During the Prague meeting, there was a question about the measurement uni= t > of the "ParallaxInfo" attribute. Currently, this unit is pixels, but I wa= s > asked if it would make sense to use another unit, for example cm, to cate= r > for different screen sizes and resolutions. > > As many before me, I did some calculations. The results match similar > calculations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the > parallax P is a hyperbolic function of the depth Z (where Z=3D0 correspon= ds to > the position of the screen itself). The function P(Z) has a zero at scree= n > depth, a vertical asymptote at the viewing distance and a horizontal > asymptote of the distance between the eyes. > > Near to the screen, P(Z) can be approximated by a line, that goes trough > (Z=3D0,P=3D0). It has the form > > (1) P(Z) ~=3D A*Z, > > where A depends on the x- and z-positions of the left and right eyes. (In > the calculations, I have neglected y, leading to a small bias.) > > Since formula (1) is linear, near to the screen, multiplying the parallax > by a certain factor results in increasing the depth by approximately the > same factor. This is desirable, since if in one representation the > horizontal and vertical distances are twice as big as in another, it is > natural that the depth is twice as big as well. > > If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, the= n > the parallax in pixels will be smaller on a small screen than on a big > screen. But since the rest of the video is equally smaller, through (1) t= he > complete picture remains in sync (assuming the depth range is not too > large). > > So I think the unit "pixels" is appropriate for the ParallaxInfo attribut= e. > We might want to add some text clarifying that the parallax suits the pix= el > width and height of the video. > > Any opinions on this? > > Best regards, > Bert > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --bcaec51b199d62c5e504a1571988 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable I agree that having an implicit reference screen width of 11,520 pixels res= olves the problem.  This essentially defines the signaled value as a f= raction of the screen size (using somewhat unusual but carefully chosen uni= ts).

An alternative would be to explicitly signal the reference screen width= .  The only advantage I see to the alternative approach is that it all= ows an exact representation for other screen widths (such as 1024 for compu= ter screens or 800 for mobile devices).  Though this advantage is limi= ted to cases there the text is intended for a narrow range of devices.

Regards,
Stephen Botzko

2011/4/20 = huiyu <huiyu@huawe= i.com>

Hi,all

 

The SDP  "ParallaxInfo" attribute  is = ; actually computed relative to  a reference screen, which has a = fixed screen resolution .

The  reference screen  has  a   scree= n resolution of 11520 horizontal pixels .

The nu= mber has been standardized by the SMPTE .

 

The SDP  "ParallaxInfo"= ; attribute indicates the parallax in units of pixels related to  refe= rence screen with 11,520 horizontal pixels.

 

The transformation from the refere= nce parallax in pixels to the actual parallax in pixels for different displ= ay sizes shall be as follows:

PARALLAX=3D parallax/[11520/ W_pix]

&n= bsp;

PARALLAX  means the parallax in the actual screen in units= of pixels.

W_pix means  the horizontal pixels&nb= sp; of the actual screen solution.

parallax is  the 'parallax' value in the SDP  = "ParallaxInfo" attribute line  in units of pixels.

 =

Because there may be master spatial resolutions for which [PA= RALLAX ] cannot be readily derived by dividing by an integer. so the result= ing [PARALLAX ] value shall be appropriately rounded to the nearest integer= value."  Here  ‘[11520/ W_pix]’ means  the= resulting value  shall  be rounded to the nearest integer.

 

 

As for 115= 20, SMPTE  provide the following reasoning:

The reason for this particular reference display value is that t= he native parallax Value of the three most popular standards for horizontal= resolution can be readily derived from the display value by dividing by an= integer, as follows:

o       1920 horizontal pixels =3D= 11,520 / 6

o       1440 = horizontal pixels =3D 11,520 / 8

o       1280 horizontal pixels =3D= 11,520 / 9

 

 

 

The = following illustrates the processing of  deducing the transformation.<= /span>

 

In MPEG-C part 3, ISO/IEC 23002-3=A3=ACthe formula P/P_ref=3DW/= W_ref demonstrates the transformation of parallax from  a reference sc= reen to a actual screen,

although it is just approximate.

 

 The uni= t of all parameters can be 'cm'.

=   &= #39;W_ref' means the horizontal screen size of the reference screen.

  'w' means the horizontal screen size of the actua= l screen.

  'P_ref'  means the parall= ax  in the reference screen.

  'P'  means the parallax  in the actual = screen.

 

According to the physical size of each pixel  in screen, w= e can change the unit of 'cm' to the unit of 'pixel' .

  the pa= rallax of the reference screen in units of pixels can be expressed as P_ref= pix,

  the horizontal screen size  of the ref= erence screen in units of pixels can be expressed as W_refpix, 

  the parallax in the actual screen in units of pixels= can be expressed as P_pix,

  the horizontal scree= n size  of the actual screen in units of pixels can be expressed as W_= pix,

 

  so it has :

   W_refpix/P_refpix=3DW_ref/P_ref;

   W_pix/P_pix=3DW/P;

 

   = According to  the above formulas,  it has:   P_pix=3D P= _refpix/( W_refpix / W_pix) .

 

   Correspondingly,

=   &= nbsp;the value of W_refpix is 11520,

   P_refpix is  the 'parallax' value= in the SDP  "ParallaxInfo" attribute line  .

   the value of W_pix is the horizontal  pi= xels of actual screen  solution.

   then  P_pix  is the actual parallax in ac= tual screen, it can also be transformed to cm  according to the physic= al size of each pixel.

 

So this = formula P_pix=3D P_refpix/( W_refpix / W_pix)  corresponds to the prev= ious transformation formula.

   In summary, we refere= nce the  SMPTE standard , and choose 11520  as the horizontal pix= els  of the reference screen solution ,

and define  the transformatio= n.    we will add some text clarifying the transformation of= parallax.

 

 

Best regar= ds,

HuiYu

 

 

 

=B7=A2=BC=FE=C8=CB: mmusic-bounces@ietf.org [mailto= :mmusic-bounce= s@ietf.org] =B4=FA=B1=ED Stephen Botzko
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C219=C8=D5 1= 8:17
=CA=D5=BC=FE=C8=CB: Bert Greevenbosch
=B3=AD=CB=CD: mmusic@ietf.org
=D6=F7=CC=E2= : Re: [MMUSIC] About measurement unit for P= arallaxInfo

 

Thx for the formula / followup.

The scre= en resolution is not known though.  With H.264 all you know is the pro= file/level.

Regards,
Stephen Botzko

On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch <Bert.Greevenbo= sch@huawei.com> wrote:

Hi all,

During the Pragu= e meeting, there was a question about the measurement unit of the "Par= allaxInfo" attribute. Currently, this unit is pixels, but I was asked = if it would make sense to use another unit, for example cm, to cater for di= fferent screen sizes and resolutions.

As many before me, I did some calculations. The results match similar c= alculations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the parall= ax P is a hyperbolic function of the depth Z (where Z=3D0 corresponds to th= e position of the screen itself). The function P(Z) has a zero at screen de= pth, a vertical asymptote at the viewing distance and a horizontal asymptot= e of the distance between the eyes.

Near to the screen, P(Z) can be approximated by a line, that goes troug= h (Z=3D0,P=3D0). It has the form

(1)     P(Z) ~=3D A*Z,
where A depends on the x- and z-positions of the left and right eyes. = (In the calculations, I have neglected y, leading to a small bias.)

Since formula (1) is linear, near to the screen, multiplying the parall= ax by a certain factor results in increasing the depth by approximately the= same factor. This is desirable, since if in one representation the horizon= tal and vertical distances are twice as big as in another, it is natural th= at the depth is twice as big as well.

If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, t= hen the parallax in pixels will be smaller on a small screen than on a big = screen. But since the rest of the video is equally smaller, through (1) the= complete picture remains in sync (assuming the depth range is not too larg= e).

So I think the unit "pixels" is appropriate for the ParallaxI= nfo attribute. We might want to add some text clarifying that the parallax = suits the pixel width and height of the video.

Any opinions on this?=

Best regards,
Bert
______________________________________________= _
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 


--bcaec51b199d62c5e504a1571988-- From huiyu@huawei.com Wed Apr 20 19:34:08 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36C08E07EF for ; Wed, 20 Apr 2011 19:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYlrAYKw1E7U for ; Wed, 20 Apr 2011 19:34:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id D8318E06DB for ; Wed, 20 Apr 2011 19:34:04 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ00897DORCO@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 21 Apr 2011 10:31:40 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ008EFDORX1@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 21 Apr 2011 10:31:39 +0800 (CST) Received: from h45037b ([10.138.73.44]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJZ002MSDOQBW@szxml06-in.huawei.com> for mmusic@ietf.org; Thu, 21 Apr 2011 10:31:39 +0800 (CST) Date: Thu, 21 Apr 2011 10:31:30 +0800 From: huiyu In-reply-to: To: 'Stephen Botzko' Message-id: <000301cbffcc$390f8200$ab2e8600$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NWINz4tJ0Vp+aM7VfPhv3w)" Content-language: zh-cn Thread-index: Acv/RxbFlRsN55rwQ0iyLhAiAnSWZwAffDDg References: <46A1DF3F04371240B504290A071B4DB6012C561F@SZXEML501-MBS.china.huawei.com> <001101cbff1e$2914ec90$7b3ec5b0$@com> Cc: mmusic@ietf.org Subject: [MMUSIC] =?gb2312?b?tPC4tDogIEFib3V0IG1lYXN1cmVtZW50IHVuaXQgZm9y?= =?gb2312?b?IFBhcmFsbGF4SW5mbw==?= 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, 21 Apr 2011 02:34:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NWINz4tJ0Vp+aM7VfPhv3w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Stephen=A3=AC =20 Thanks for your advice. =20 I think the two methods are all reasonable. But in fact whether selecting 11520 pixels as the reference screen width = or signalling the reference screen width in SDP "ParallaxInfo" attribute line,=20 the resulting [PARALLAX ] value may be a fraction and need to be appropriately rounded to the nearest integer value in some cases. =20 we select 11520 pixels as the reference screen width. Mainly Concerning that the standardized number is adopted by some = standard such as DVB ,SMPTE. so we think it should be consistent with these standard ,though it = leads to a fraction of in some cases. =20 Best regards=A3=AC Huiyu =20 =B7=A2=BC=FE=C8=CB: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C220=C8=D5 18:29 =CA=D5=BC=FE=C8=CB: huiyu =B3=AD=CB=CD: mmusic@ietf.org; Bert Greevenbosch =D6=F7=CC=E2: Re: [MMUSIC] About measurement unit for ParallaxInfo =20 I agree that having an implicit reference screen width of 11,520 pixels resolves the problem. This essentially defines the signaled value as a fraction of the screen size (using somewhat unusual but carefully chosen units).=20 An alternative would be to explicitly signal the reference screen width. The only advantage I see to the alternative approach is that it allows = an exact representation for other screen widths (such as 1024 for computer screens or 800 for mobile devices). Though this advantage is limited to cases there the text is intended for a narrow range of devices. Regards, Stephen Botzko 2011/4/20 huiyu Hi,all =20 The SDP "ParallaxInfo" attribute is actually computed relative to a reference screen, which has a fixed screen resolution . The reference screen has a screen resolution of 11520 horizontal = pixels . The number has been standardized by the SMPTE . =20 The SDP "ParallaxInfo" attribute indicates the parallax in units of = pixels related to reference screen with 11,520 horizontal pixels. =20 The transformation from the reference parallax in pixels to the actual parallax in pixels for different display sizes shall be as follows: PARALLAX=3D parallax/[11520/ W_pix] =20 PARALLAX means the parallax in the actual screen in units of pixels. W_pix means the horizontal pixels of the actual screen solution. parallax is the 'parallax' value in the SDP "ParallaxInfo" attribute = line in units of pixels. =20 Because there may be master spatial resolutions for which [PARALLAX ] = cannot be readily derived by dividing by an integer. so the resulting [PARALLAX = ] value shall be appropriately rounded to the nearest integer value." = Here =A1=AE[11520/ W_pix]=A1=AF means the resulting value shall be rounded = to the nearest integer. =20 =20 As for 11520, SMPTE provide the following reasoning: The reason for this particular reference display value is that the = native parallax Value of the three most popular standards for horizontal = resolution can be readily derived from the display value by dividing by an integer, = as follows: o 1920 horizontal pixels =3D 11,520 / 6 o 1440 horizontal pixels =3D 11,520 / 8 o 1280 horizontal pixels =3D 11,520 / 9 =20 =20 =20 The following illustrates the processing of deducing the = transformation. =20 In MPEG-C part 3, ISO/IEC 23002-3=A3=ACthe formula P/P_ref=3DW/W_ref = demonstrates the transformation of parallax from a reference screen to a actual = screen, although it is just approximate.=20 =20 The unit of all parameters can be 'cm'.=20 'W_ref' means the horizontal screen size of the reference screen. 'w' means the horizontal screen size of the actual screen. 'P_ref' means the parallax in the reference screen. 'P' means the parallax in the actual screen. =20 According to the physical size of each pixel in screen, we can change = the unit of 'cm' to the unit of 'pixel' . the parallax of the reference screen in units of pixels can be = expressed as P_refpix, the horizontal screen size of the reference screen in units of pixels = can be expressed as W_refpix, =20 the parallax in the actual screen in units of pixels can be expressed = as P_pix, the horizontal screen size of the actual screen in units of pixels = can be expressed as W_pix, =20 so it has : W_refpix/P_refpix=3DW_ref/P_ref; W_pix/P_pix=3DW/P; =20 According to the above formulas, it has: P_pix=3D P_refpix/( = W_refpix / W_pix) . =20 Correspondingly,=20 the value of W_refpix is 11520,=20 P_refpix is the 'parallax' value in the SDP "ParallaxInfo" = attribute line .=20 the value of W_pix is the horizontal pixels of actual screen = solution. then P_pix is the actual parallax in actual screen, it can also be transformed to cm according to the physical size of each pixel. =20 So this formula P_pix=3D P_refpix/( W_refpix / W_pix) corresponds to = the previous transformation formula. In summary, we reference the SMPTE standard , and choose 11520 as = the horizontal pixels of the reference screen solution , and define the transformation. we will add some text clarifying the transformation of parallax. =20 =20 Best regards, HuiYu =20 =20 =20 =B7=A2=BC=FE=C8=CB: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] =B4=FA=B1=ED Stephen Botzko =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C219=C8=D5 18:17 =CA=D5=BC=FE=C8=CB: Bert Greevenbosch =B3=AD=CB=CD: mmusic@ietf.org =D6=F7=CC=E2: Re: [MMUSIC] About measurement unit for ParallaxInfo =20 Thx for the formula / followup. The screen resolution is not known though. With H.264 all you know is = the profile/level. Regards, Stephen Botzko On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch wrote: Hi all, During the Prague meeting, there was a question about the measurement = unit of the "ParallaxInfo" attribute. Currently, this unit is pixels, but I = was asked if it would make sense to use another unit, for example cm, to = cater for different screen sizes and resolutions. As many before me, I did some calculations. The results match similar calculations in MPEG-C part 3, ISO/IEC 23002-3. It turns out that the parallax P is a hyperbolic function of the depth Z (where Z=3D0 = corresponds to the position of the screen itself). The function P(Z) has a zero at = screen depth, a vertical asymptote at the viewing distance and a horizontal asymptote of the distance between the eyes. Near to the screen, P(Z) can be approximated by a line, that goes trough (Z=3D0,P=3D0). It has the form (1) P(Z) ~=3D A*Z, where A depends on the x- and z-positions of the left and right eyes. = (In the calculations, I have neglected y, leading to a small bias.) Since formula (1) is linear, near to the screen, multiplying the = parallax by a certain factor results in increasing the depth by approximately the = same factor. This is desirable, since if in one representation the horizontal = and vertical distances are twice as big as in another, it is natural that = the depth is twice as big as well. If we have a fixed screen resolution in pixels, e.g. 1280x720 pixels, = then the parallax in pixels will be smaller on a small screen than on a big screen. But since the rest of the video is equally smaller, through (1) = the complete picture remains in sync (assuming the depth range is not too large). So I think the unit "pixels" is appropriate for the ParallaxInfo = attribute. We might want to add some text clarifying that the parallax suits the = pixel width and height of the video. Any opinions on this? Best regards, Bert _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 =20 --Boundary_(ID_NWINz4tJ0Vp+aM7VfPhv3w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Stephen=A3=AC

 

Thanks for your advice.

 

I think the two methods are all reasonable.

But in fact whether selecting 11520 pixels as the reference screen = width or  signalling  the reference screen width  in = SDP  "ParallaxInfo" attribute line, =

the resulting [PARALLAX ] value  may be a fraction and need = to  be appropriately rounded to the nearest integer value in some = cases.

 

we select  11520  pixels as the reference screen = width.

Mainly Concerning that the standardized number is adopted by some =  standard such as DVB ,SMPTE.

so we think it should be consistent with  these standard ,though = it leads to a fraction of  in some cases.

 

Best regards=A3=AC

Huiyu

 

=B7=A2=BC=FE=C8=CB: Stephen Botzko = [mailto:stephen.botzko@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C220=C8=D5 = 18:29
=CA=D5=BC=FE=C8=CB: = huiyu
=B3=AD=CB=CD: mmusic@ietf.org; Bert = Greevenbosch
=D6=F7=CC=E2: Re: [MMUSIC] About = measurement unit for ParallaxInfo

 

I = agree that having an implicit reference screen width of 11,520 pixels = resolves the problem.  This essentially defines the signaled value = as a fraction of the screen size (using somewhat unusual but carefully = chosen units).

An alternative would be to explicitly signal the = reference screen width.  The only advantage I see to the = alternative approach is that it allows an exact representation for other = screen widths (such as 1024 for computer screens or 800 for mobile = devices).  Though this advantage is limited to cases there the text = is intended for a narrow range of devices.

Regards,
Stephen = Botzko

2011/4/20 huiyu <huiyu@huawei.com>

Hi,all

 

The SDP  = "ParallaxInfo" attribute  is  actually computed = relative to  a reference screen, which has a  fixed screen = resolution .

The =  reference screen  has  a   screen resolution = of 11520 horizontal pixels .

The number has = been standardized by the SMPTE .

 

The SDP  = "ParallaxInfo" attribute indicates the parallax in units of = pixels related to  reference screen with 11,520 horizontal = pixels.

 

The transformation = from the reference parallax in pixels to the actual parallax in pixels = for different display sizes shall be as follows:

PARALLAX=3D = parallax/[11520/ W_pix]

 

PARALLAX =  means the parallax in the actual screen in units of = pixels.

W_pix means =  the horizontal pixels  of the actual screen = solution.

parallax is  = the 'parallax' value in the SDP  "ParallaxInfo" attribute = line  in units of pixels.

 

Because there may = be master spatial resolutions for which [PARALLAX ] cannot be readily = derived by dividing by an integer. so the resulting [PARALLAX ] value = shall be appropriately rounded to the nearest integer value." =  Here  =A1=AE[11520/ W_pix]=A1=AF means =  the resulting value  shall  be rounded to the nearest = integer.

 

 

As for 11520, = SMPTE  provide the following reasoning:

The reason for = this particular reference display value is that the native parallax = Value of the three most popular standards for horizontal resolution can = be readily derived from the display value by dividing by an integer, as = follows:

o     &= nbsp; 1920 horizontal pixels =3D 11,520 / 6

o     &= nbsp; 1440 horizontal pixels =3D 11,520 / 8

o     &= nbsp; 1280 horizontal pixels =3D 11,520 / 9

 

 

 

The following = illustrates the processing of  deducing the = transformation.

 

In MPEG-C part 3, = ISO/IEC 23002-3=A3=ACthe = formula P/P_ref=3DW/W_ref demonstrates the transformation of parallax = from  a reference screen to a actual screen,

although it is = just approximate.

 

 The unit of = all parameters can be 'cm'.

  'W_ref' means the = horizontal screen size of the reference screen.

  'w' means = the horizontal screen size of the actual screen.

  = 'P_ref'  means the parallax  in the reference = screen.

  'P'  = means the parallax  in the actual screen.

 

According to the = physical size of each pixel  in screen, we can change the unit of = 'cm' to the unit of 'pixel' .

  the = parallax of the reference screen in units of pixels can be expressed as = P_refpix,

  the = horizontal screen size  of the reference screen in units of pixels = can be expressed as W_refpix, 

  the = parallax in the actual screen in units of pixels can be expressed as = P_pix,

  the = horizontal screen size  of the actual screen in units of pixels can = be expressed as W_pix,

  =

  so it = has :

   = W_refpix/P_refpix=3DW_ref/P_ref;

   = W_pix/P_pix=3DW/P;

 

   = According to  the above formulas,  it has:   = P_pix=3D P_refpix/( W_refpix / W_pix) .

 

   = Correspondingly,

   the value of = W_refpix is 11520,

   P_refpix = is  the 'parallax' value in the SDP  "ParallaxInfo" = attribute line  .

   the value of = W_pix is the horizontal  pixels of actual screen =  solution.

   = then  P_pix  is the actual parallax in actual screen, it can = also be transformed to cm  according to the physical size of each = pixel.

 

So = this formula P_pix=3D P_refpix/( W_refpix / W_pix)  corresponds to = the previous transformation formula.

   In = summary, we reference the  SMPTE standard , and choose 11520 =  as the horizontal pixels  of the reference screen solution = ,

and = define  the transformation.    we will add some text = clarifying the transformation of parallax.

 

 

Best = regards,

HuiYu

 

 

 

=B7=A2=BC=FE=C8=CB: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] =B4=FA=B1=ED Stephen Botzko
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C219=C8=D5 = 18:17
=CA=D5=BC=FE=C8=CB: Bert = Greevenbosch
=B3=AD=CB=CD: mmusic@ietf.org
=D6=F7=CC=E2: Re: [MMUSIC] About = measurement unit for ParallaxInfo

 

Thx for the formula / followup.

The screen = resolution is not known though.  With H.264 all you know is the = profile/level.

Regards,
Stephen = Botzko

On Tue, Apr 19, 2011 at 3:29 AM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> = wrote:

Hi all,

During the Prague meeting, there was a = question about the measurement unit of the "ParallaxInfo" = attribute. Currently, this unit is pixels, but I was asked if it would = make sense to use another unit, for example cm, to cater for different = screen sizes and resolutions.

As many before me, I did some = calculations. The results match similar calculations in MPEG-C part 3, = ISO/IEC 23002-3. It turns out that the parallax P is a hyperbolic = function of the depth Z (where Z=3D0 corresponds to the position of the = screen itself). The function P(Z) has a zero at screen depth, a vertical = asymptote at the viewing distance and a horizontal asymptote of the = distance between the eyes.

Near to the screen, P(Z) can be = approximated by a line, that goes trough (Z=3D0,P=3D0). It has the = form

(1)     P(Z) ~=3D A*Z,

where A depends on = the x- and z-positions of the left and right eyes. (In the calculations, = I have neglected y, leading to a small bias.)

Since formula (1) = is linear, near to the screen, multiplying the parallax by a certain = factor results in increasing the depth by approximately the same factor. = This is desirable, since if in one representation the horizontal and = vertical distances are twice as big as in another, it is natural that = the depth is twice as big as well.

If we have a fixed screen = resolution in pixels, e.g. 1280x720 pixels, then the parallax in pixels = will be smaller on a small screen than on a big screen. But since the = rest of the video is equally smaller, through (1) the complete picture = remains in sync (assuming the depth range is not too large).

So I = think the unit "pixels" is appropriate for the ParallaxInfo = attribute. We might want to add some text clarifying that the parallax = suits the pixel width and height of the video.

Any opinions on = this?

Best = regards,
Bert
_______________________________________________
mm= usic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 

 

= --Boundary_(ID_NWINz4tJ0Vp+aM7VfPhv3w)-- From ted.ietf@gmail.com Thu Apr 21 09:35:46 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E7C9E0663 for ; Thu, 21 Apr 2011 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RSUhHaGz51r for ; Thu, 21 Apr 2011 09:35:44 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 81FE1E0780 for ; Thu, 21 Apr 2011 09:35:44 -0700 (PDT) Received: by pxi20 with SMTP id 20so1375984pxi.27 for ; Thu, 21 Apr 2011 09:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A/9D68CFQMIXo3mKq2E4vMhsHbdwqlH+LwIM0plJGxo=; b=eaPoeTn6b4hhevs9E1MMdCvAS5lzS9ZFnyj3WeDLtzEmSWJ8Lj22mnAxvAWnHUXRkn KcneqKWe56259NFLM0kEYET4JFpSHZj/iK23RBfDks5zF2JcRJ65Fc4JqPJm2iy7fqY4 esF0I1VuJ+XvcEyKJZ60VLta3vFrwd73nxaug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ya63qUqAVPZ5Qtyonr52/FgyrsTyEX2CxhsqZBIHJxGIkQBKD8r3clXNlhEqg/BYzn xZRqbm5oFhTtHsGXDa7QGJbSIXGTRwFYqTLkcQvQRLASeFsUD8HR5W4g1ncni6/gxxx7 YOhiUtM2WnB2p2RG1QwIiH63VeGQ4/Tc/Qlls= MIME-Version: 1.0 Received: by 10.68.50.198 with SMTP id e6mr175314pbo.438.1303403743742; Thu, 21 Apr 2011 09:35:43 -0700 (PDT) Received: by 10.68.48.33 with HTTP; Thu, 21 Apr 2011 09:35:43 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C55AA@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C55AA@SZXEML501-MBS.china.huawei.com> Date: Thu, 21 Apr 2011 09:35:43 -0700 Message-ID: From: Ted Hardie To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=bcaec544eb76250b3a04a170559d Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 21 Apr 2011 16:35:46 -0000 --bcaec544eb76250b3a04a170559d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi Ted, > > > > If I understand you well, you would like to be able to negotiate the video > frequency, such that it can easily be converted to the shutter glass > frequency. > > > > So for example, if the shutter glass frequency is 120Hz (60Hz/view), then > reasonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of > 60Hz (or in the Frame Sequential case, 120Hz). In this case it is easy to > upsample the signal by repeating each frame sequence {Lk Rk} an integer > number of times. > > > > I have a preference to use the "framerate" attribute for this, as adding > another rather similar parameter to the "3dFormat" attribute seems somehow > double. However, I also see your point in that the "framerate" attribute > only indicates a maximum frequency, not a guaranteed frequency. We could > solve this in the draft by mandating that in case of 3D streaming, the > frequency the video MUST equal the value of the "framerate" attribute, in > case the "framerate" attribute is included. > > Well, I agree that this solves the problem. I'm a little leary of having the same parameter have two related but distinct meanings, depending on the context. But if no one else objects to this, I'm certainly willing to go along. I think you are correct that the context is easy enough to determine. regards, Ted Hardie > > > What do you think? > > > > Best regards, > > Bert > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* 16 April 2011 08:36 > > *To:* Bert Greevenbosch > *Cc:* lennox@cs.columbia.edu; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Remarks from today > > > > Hi, > > Some further comments in-line. > > On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > > Hi Ted, > > > > My suspicion is that there are probably practical limits to some system's > ability to either upsample or interpolate. Would it make sense to add > something to the 3dFormat line to indicate what the resulting per-view rate > will be? So that > > a=3dFormat:FP SbS > > had an additional parameter: > > a=3dFormat:FP SbS 30Hz > > We could also consider using the SDP attribute "framerate" (RFC 4566). This > attribute would give the frame rate of the 2D channel stream, but we can > write in the draft that in the frame sequential case the frame rate per view > is half of it. > > > The relevant text from RFC 4566 is: > > a=framerate: > > > This gives the maximum video frame rate in frames/sec. It is > > intended as a recommendation for the encoding of video data. > > Decimal representations of fractional values using the notation > > "." are allowed. It is a media-level > > attribute, defined only for video media, and it is not > > dependent on charset. > > While I think it could be re-used here, it seems to me to make more sense > to use a separate indicator. This is partly because it is more for the > decoder/upsampler/interpolation check (Can I upsample this to something > reasonable? If not, don't select this choice). And it's partly because I > worry a bit about the interaction with existing code. > > > > Or do you want to indicate the target shutter glass frequency? > > > > > No, I think you're right that it's more likely that things will get > adjusted to a standard shutter speed by upsampling than they will change the > shutter speed. > > regards, > > Ted Hardie > > > Best regards, > > Bert > > > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* 15 April 2011 02:49 > > > *To:* Bert Greevenbosch > *Cc:* lennox@cs.columbia.edu; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Remarks from today > > > > On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > > I agree, the 30Hz (per view) case would give a flickering effect. Since > normal TVs have a frequency of 60Hz or more, for a similar quality with > shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. > > > > But the receiver can also upsample the received signal to a higher display > rate. For example, if it receives the following frame sequence at 30Hz/view: > > > > L1,R1,L2,R2,L3,R3,..., > > > > then it could display at 60Hz/view: > > > > L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... > > > > The receiver can also use some interpolation technique to generate the > frames between L*k* and L(*k*+1). > > > > I think that in praxis the receiving device will process the received > stream to make it fit the display system. This allows different > types/standards of shutter glasses to be used, independent on the format in > which the 3D stream was received. It also allows other display types such as > polarisation or autostereoscopic displays. > > > > > My suspicion is that there are probably practical limits to some system's > ability to either upsample or interpolate. Would it make sense to add > something to the 3dFormat line to indicate what the resulting per-view rate > will be? So that > > a=3dFormat:FP SbS > > had an additional parameter: > > a=3dFormat:FP SbS 30Hz > > *>I know only know one manufacturer's system at all well, and my > understanding is that the timing signals which synchronize them are really > matching the frame start times to the shuttering, but don't adjust the frame > rates. Are there glasses which can modify the rate substantially as well? > * > > > > Can you please explain a bit more about the system you are referring too, > especially about not modifying the frame rate? Do you mean the frame rate > between the TV screen and the signalling device (that transmits the signal > to the shutter glasses) or the frame rate of the video stream as it is > received before it is decoded (by the codec)? > > > > > I probably should have said "shuttering rate", sorry. I mean that it > matches the shutters to the alternating left and right view, but that the > shuttering rate is consistent (resulting in 60Hz per view, in this case). > > regards, > > Ted Hardie > > > --bcaec544eb76250b3a04a170559d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com<= /a>> wrote:

Hi Ted,

=A0

If I understand you well, you would like to be able to negotiate the = video frequency, such that it can easily be converted to the shutter glass = frequency.

=A0

So for example, if the shutter glass frequency is 120Hz (60Hz/view), = then reasonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors = of 60Hz (or in the Frame Sequential case, 120Hz). In this case it is easy to upsample = the signal by repeating each frame sequence {Lk Rk} an integer number of ti= mes.

=A0

I have a preference to use the "framerate" attribute for th= is, as adding another rather similar parameter to the "3dFormat" = attribute seems somehow double. However, I also see your point in that the "framerate" attribute= only indicates a maximum frequency, not a guaranteed frequency. We could s= olve this in the draft by mandating that in case of 3D streaming, the frequ= ency the video MUST equal the value of the "framerate" attribute, in case the "framerate" attribu= te is included.


Well, I agree that this = solves the problem.=A0 I'm a little leary of having the same parameter = have two related but distinct meanings, depending on the context.=A0 But if= no one else objects to this, I'm certainly willing to go along.=A0 I t= hink you are correct that the context is easy enough to determine.

regards,

Ted Hardie

=A0

=A0

What do you think?

=A0

Best regards,

Bert

=A0

F= rom: Ted Hardie = [mailto:ted.ietf@gm= ail.com]
Sent: 16 April 2011 08:36


To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

=A0

Hi,

Some further comments in-line.

On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch = <Bert.= Greevenbosch@huawei.com> wrote:

Hi Ted,

=A0

My suspicion is that there are probabl= y practical limits to some system's ability to either upsample or inter= polate.=A0 Would it make sense to add something to the 3dFormat line to indicate what the resulting per-v= iew rate will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz

We could also consi= der using the SDP attribute "framerate" (RFC 4566). This attribut= e would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per vi= ew is half of it.


The relevant text from RFC 4566 is:

a=3Dframerate:<frame rate>



=A0=A0=A0=A0=A0=A0=A0=A0 This gives the maximum video frame rate in frames/=
sec.=A0 It is




=A0=A0=A0=A0=A0=A0=A0=A0 intended as a recommendation for the encoding=
 of video data.

=A0=A0=A0=A0=A0=A0=A0=A0 Decimal representations of fractional values using=
 the notation

=A0=A0=A0=A0=A0=A0=A0=A0 "<integer>.<fraction>" are a=
llowed.=A0 It is a media-level




=A0=A0=A0=A0=A0=A0=A0=A0 attribute, defined only for video media, and =
it is not

=A0=A0=A0=A0=A0=A0=A0=A0 dependent on charset.

While I think it could be re-used here, it seems to = me to make more sense to use a separate indicator.=A0 This is partly becaus= e it is more for the decoder/upsampler/interpolation check (Can I upsample = this to something reasonable?=A0 If not, don't select this choice).=A0 And it's partly because I worry a bi= t about the interaction with existing code.

=A0

=A0Or do you want t= o indicate the target shutter glass frequency?

=A0


No, I think you're right that it's more likely that things will get= adjusted to a standard shutter speed by upsampling than they will change t= he shutter speed.

regards,

Ted Hardie
=A0

Best regards,

Bert

=A0

=A0

F= rom: Ted Hardie = [mailto:ted.ietf@gm= ail.com]
Sent: 15 April 2011 02:49


To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today

=A0

On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch = <Bert.= Greevenbosch@huawei.com> wrote:

I agree, the 30Hz (= per view) case would give a flickering effect. Since normal TVs have a freq= uency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=3D60 Hz/view) or more.

=A0

But the receiver ca= n also upsample the received signal to a higher display rate. For example, = if it receives the following frame sequence at 30Hz/view:

=A0

L1,R1,L2,R2,L3,R3,...,

=A0

then it could displ= ay at 60Hz/view:

=A0

L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....

=A0

The receiver can al= so use some interpolation technique to generate the frames between Lk and L(k+1).

=A0

I think that in pra= xis the receiving device will process the received stream to make it fit th= e display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D s= tream was received. It also allows other display types such as polarisation= or autostereoscopic displays.

=A0


My suspicion is that there are probably practical limits to some system'= ;s ability to either upsample or interpolate.=A0 Would it make sense to add= something to the 3dFormat line to indicate what the resulting per-view rat= e will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz

>I know only know one manufacturer's system at all well, an= d my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adj= ust the frame rates.=A0 Are there glasses which can modify the rate substan= tially as well?

=A0

Can you please expl= ain a bit more about the system you are referring too, especially about not= modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal= to the shutter glasses) or the frame rate of the video stream as it is rec= eived before it is decoded (by the codec)?

=A0


I probably should have said "shuttering rate", sorry.=A0 I mean t= hat it matches the shutters to the alternating left and right view, but tha= t the shuttering rate is consistent (resulting in 60Hz per view, in this ca= se).

regards,

Ted Hardie

=A0


--bcaec544eb76250b3a04a170559d-- From stephen.botzko@gmail.com Thu Apr 21 10:30:09 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1F74E0663 for ; Thu, 21 Apr 2011 10:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC1uzy57GZ0D for ; Thu, 21 Apr 2011 10:30:08 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id A9B20E065F for ; Thu, 21 Apr 2011 10:30:07 -0700 (PDT) Received: by pwi5 with SMTP id 5so1261121pwi.31 for ; Thu, 21 Apr 2011 10:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=teB4cQ/PRqhoHxCRgoyiPsszlzP4SjAMJ92ZCEoo92U=; b=D/1qL/HoIYyVBVfsEgvJfnwcN5TFjq7G1c1wCwZelIgbFi6ZaKqCzP3zeD9zW1X4LR R+tlWtBPsr0f2nEKsO24QnIfQUjXjo+sTIRLxLhL5I5bnHXaM9WTNfFeO2vr9j9E5x/p 2rd5wzxykEJTJj12J1n04HxmSgPg3p+J4b3/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XlSpBTqxW6IYnJRVGkGOmKbxA6GrAJKQ4NOSweckOCfBxDKhLzmROKjGw8/f0DUEKt EdfLlvyUWARlJOvUKDDFqP7eaVPdrpUBnByMB8pECFPCtsBVeYRaRlAY2GFibrhzKJPt lETsSsjvSo0EDDuzKQfP3UWO8EtJtFfE56ARU= MIME-Version: 1.0 Received: by 10.68.10.100 with SMTP id h4mr308191pbb.19.1303407006939; Thu, 21 Apr 2011 10:30:06 -0700 (PDT) Received: by 10.68.42.101 with HTTP; Thu, 21 Apr 2011 10:30:06 -0700 (PDT) In-Reply-To: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C55AA@SZXEML501-MBS.china.huawei.com> Date: Thu, 21 Apr 2011 13:30:06 -0400 Message-ID: From: Stephen Botzko To: Ted Hardie Content-Type: multipart/alternative; boundary=bcaec53042ffa57ab804a1711786 Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 21 Apr 2011 17:30:09 -0000 --bcaec53042ffa57ab804a1711786 Content-Type: text/plain; charset=ISO-8859-1 in-line Stephen Botzko On Thu, Apr 21, 2011 at 12:35 PM, Ted Hardie wrote: > On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > >> Hi Ted, >> >> >> >> If I understand you well, you would like to be able to negotiate the video >> frequency, such that it can easily be converted to the shutter glass >> frequency. >> >> >> >> So for example, if the shutter glass frequency is 120Hz (60Hz/view), then >> reasonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of >> 60Hz (or in the Frame Sequential case, 120Hz). In this case it is easy to >> upsample the signal by repeating each frame sequence {Lk Rk} an integer >> number of times. >> >> >> >> I have a preference to use the "framerate" attribute for this, as adding >> another rather similar parameter to the "3dFormat" attribute seems somehow >> double. However, I also see your point in that the "framerate" attribute >> only indicates a maximum frequency, not a guaranteed frequency. We could >> solve this in the draft by mandating that in case of 3D streaming, the >> frequency the video MUST equal the value of the "framerate" attribute, in >> case the "framerate" attribute is included. >> >> > Well, I agree that this solves the problem. I'm a little leary of having > the same parameter have two related but distinct meanings, depending on the > context. But if no one else objects to this, I'm certainly willing to go > along. I think you are correct that the context is easy enough to > determine. > > regards, > So this means that this video frequency negotiation can't be done for 3D video conferencing? Providing application-specific definitions for a parameter seems like a problem to me, as many stacks / systems support multiple applications, and good definitions of the application might be hard to craft. Are we sure we really need this negotiation to achieve interoperability? I'm not convinced myself. If we do, I think a new parameter is a better approach. > > Ted Hardie > > > >> >> >> What do you think? >> >> >> >> Best regards, >> >> Bert >> >> >> >> *From:* Ted Hardie [mailto:ted.ietf@gmail.com] >> *Sent:* 16 April 2011 08:36 >> >> *To:* Bert Greevenbosch >> *Cc:* lennox@cs.columbia.edu; mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Remarks from today >> >> >> >> Hi, >> >> Some further comments in-line. >> >> On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch < >> Bert.Greevenbosch@huawei.com> wrote: >> >> Hi Ted, >> >> >> >> My suspicion is that there are probably practical limits to some system's >> ability to either upsample or interpolate. Would it make sense to add >> something to the 3dFormat line to indicate what the resulting per-view rate >> will be? So that >> >> a=3dFormat:FP SbS >> >> had an additional parameter: >> >> a=3dFormat:FP SbS 30Hz >> >> We could also consider using the SDP attribute "framerate" (RFC 4566). >> This attribute would give the frame rate of the 2D channel stream, but we >> can write in the draft that in the frame sequential case the frame rate per >> view is half of it. >> >> >> The relevant text from RFC 4566 is: >> >> a=framerate: >> >> >> This gives the maximum video frame rate in frames/sec. It is >> >> intended as a recommendation for the encoding of video data. >> >> Decimal representations of fractional values using the notation >> >> "." are allowed. It is a media-level >> >> attribute, defined only for video media, and it is not >> >> dependent on charset. >> >> While I think it could be re-used here, it seems to me to make more sense >> to use a separate indicator. This is partly because it is more for the >> decoder/upsampler/interpolation check (Can I upsample this to something >> reasonable? If not, don't select this choice). And it's partly because I >> worry a bit about the interaction with existing code. >> >> >> >> Or do you want to indicate the target shutter glass frequency? >> >> >> >> >> No, I think you're right that it's more likely that things will get >> adjusted to a standard shutter speed by upsampling than they will change the >> shutter speed. >> >> regards, >> >> Ted Hardie >> >> >> Best regards, >> >> Bert >> >> >> >> >> >> *From:* Ted Hardie [mailto:ted.ietf@gmail.com] >> *Sent:* 15 April 2011 02:49 >> >> >> *To:* Bert Greevenbosch >> *Cc:* lennox@cs.columbia.edu; mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Remarks from today >> >> >> >> On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch < >> Bert.Greevenbosch@huawei.com> wrote: >> >> I agree, the 30Hz (per view) case would give a flickering effect. Since >> normal TVs have a frequency of 60Hz or more, for a similar quality with >> shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. >> >> >> >> But the receiver can also upsample the received signal to a higher display >> rate. For example, if it receives the following frame sequence at 30Hz/view: >> >> >> >> L1,R1,L2,R2,L3,R3,..., >> >> >> >> then it could display at 60Hz/view: >> >> >> >> L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... >> >> >> >> The receiver can also use some interpolation technique to generate the >> frames between L*k* and L(*k*+1). >> >> >> >> I think that in praxis the receiving device will process the received >> stream to make it fit the display system. This allows different >> types/standards of shutter glasses to be used, independent on the format in >> which the 3D stream was received. It also allows other display types such as >> polarisation or autostereoscopic displays. >> >> >> >> >> My suspicion is that there are probably practical limits to some system's >> ability to either upsample or interpolate. Would it make sense to add >> something to the 3dFormat line to indicate what the resulting per-view rate >> will be? So that >> >> a=3dFormat:FP SbS >> >> had an additional parameter: >> >> a=3dFormat:FP SbS 30Hz >> >> *>I know only know one manufacturer's system at all well, and my >> understanding is that the timing signals which synchronize them are really >> matching the frame start times to the shuttering, but don't adjust the frame >> rates. Are there glasses which can modify the rate substantially as well? >> * >> >> >> >> Can you please explain a bit more about the system you are referring too, >> especially about not modifying the frame rate? Do you mean the frame rate >> between the TV screen and the signalling device (that transmits the signal >> to the shutter glasses) or the frame rate of the video stream as it is >> received before it is decoded (by the codec)? >> >> >> >> >> I probably should have said "shuttering rate", sorry. I mean that it >> matches the shutters to the alternating left and right view, but that the >> shuttering rate is consistent (resulting in 60Hz per view, in this case). >> >> regards, >> >> Ted Hardie >> >> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --bcaec53042ffa57ab804a1711786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line
Stephen Botzko

On Thu, Apr 21,= 2011 at 12:35 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:


Ted Hardie
<= br>=A0

Fro= m: Ted Hardie [mai= lto:ted.ietf@gmail.= com]
Sent: 16 April 2011 08:36


To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today

=A0

Hi,

Some further comments in-line.

On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch = <Bert.= Greevenbosch@huawei.com> wrote:

Hi Ted,

My suspicion is that there are probably prac= tical limits to some system's ability to either upsample or interpolate= .=A0 Would it make sense to add something to the 3dFormat line to indicate what the resulting per-v= iew rate will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz

We could also conside= r using the SDP attribute "framerate" (RFC 4566). This attribute = would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per vi= ew is half of it.


The relevant text from RFC 4566 is:

a=3Dframerate:<frame rate>



=A0=A0=A0=A0=A0=A0=A0=A0 This gives the maximum video frame rate in frames/=
sec.=A0 It is




=A0=A0=A0=A0=A0=A0=A0=A0 intended as a recommendation for the encoding=
 of video data.

=A0=A0=A0=A0=A0=A0=A0=A0 Decimal representations of fractional values using=
 the notation

=A0=A0=A0=A0=A0=A0=A0=A0 "<integer>.<fraction>" are a=
llowed.=A0 It is a media-level




=A0=A0=A0=A0=A0=A0=A0=A0 attribute, defined only for video media, and =
it is not

=A0=A0=A0=A0=A0=A0=A0=A0 dependent on charset.

While I think it could be re-used here, it seems to = me to make more sense to use a separate indicator.=A0 This is partly becaus= e it is more for the decoder/upsampler/interpolation check (Can I upsample = this to something reasonable?=A0 If not, don't select this choice).=A0 And it's partly because I worry a bi= t about the interaction with existing code.

=A0

=A0Or do you want to = indicate the target shutter glass frequency?

=A0


No, I think you're right that it's more likely that things will get= adjusted to a standard shutter speed by upsampling than they will change t= he shutter speed.

regards,

Ted Hardie
=A0

Best regards,<= /p>

Bert

=A0

=A0

Fro= m: Ted Hardie [mai= lto:ted.ietf@gmail.= com]
Sent: 15 April 2011 02:49


To: Bert Greevenbosch
Cc: lenn= ox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today

=A0

On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch = <Bert.= Greevenbosch@huawei.com> wrote:

I agree, the 30Hz (pe= r view) case would give a flickering effect. Since normal TVs have a freque= ncy of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=3D60 Hz/view) or more.

=A0

But the receiver can = also upsample the received signal to a higher display rate. For example, if= it receives the following frame sequence at 30Hz/view:

=A0

L1,R1,L2,R2,L3,R3,...,

=A0

then it could display= at 60Hz/view:

=A0

L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....

=A0

The receiver can also= use some interpolation technique to generate the frames between Lk = and L(k+1).

=A0

I think that in praxi= s the receiving device will process the received stream to make it fit the = display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D s= tream was received. It also allows other display types such as polarisation= or autostereoscopic displays.

=A0


My suspicion is that there are probably practical limits to some system'= ;s ability to either upsample or interpolate.=A0 Would it make sense to add= something to the 3dFormat line to indicate what the resulting per-view rat= e will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz

>I know only know one manufacturer's system at all well, and my= understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adj= ust the frame rates.=A0 Are there glasses which can modify the rate substan= tially as well?

=A0

Can you please explai= n a bit more about the system you are referring too, especially about not m= odifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal= to the shutter glasses) or the frame rate of the video stream as it is rec= eived before it is decoded (by the codec)?

=A0


I probably should have said "shuttering rate", sorry.=A0 I mean t= hat it matches the shutters to the alternating left and right view, but tha= t the shuttering rate is consistent (resulting in 60Hz per view, in this ca= se).

regards,

Ted Hardie

=A0



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


--bcaec53042ffa57ab804a1711786-- From Bert.Greevenbosch@huawei.com Fri Apr 22 19:56:06 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0B4C1E06D6 for ; Fri, 22 Apr 2011 19:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2ryc7FmXeU3 for ; Fri, 22 Apr 2011 19:56:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 3008BE065C for ; Fri, 22 Apr 2011 19:56:04 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK3009Q945CTV@szxga03-in.huawei.com> for mmusic@ietf.org; Sat, 23 Apr 2011 10:56:00 +0800 (CST) Received: from szxeml204-edg.china.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 <0LK300A9145CFH@szxga03-in.huawei.com> for mmusic@ietf.org; Sat, 23 Apr 2011 10:56:00 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 23 Apr 2011 10:55:46 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Sat, 23 Apr 2011 10:55:57 +0800 Date: Sat, 23 Apr 2011 02:55:56 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.52] To: Stephen Botzko , Ted Hardie Message-id: <46A1DF3F04371240B504290A071B4DB6012C7155@SZXEML501-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] Remarks from today Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUCAFPgEAP/7eJRwgAqv/YD//mkrcACdjgWA//69IJD//MnmgP/0M8AA/+TfsID/ybAuAP+SVX2g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C55AA@SZXEML501-MBS.china.huawei.com> Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 23 Apr 2011 02:56:06 -0000 Hi Ted, Stephen, all, I have thought a bit more about the frame rate issue, especially why it is = originally defined as a maximum frame rate rather than an exact frame rate. The main problem with the negotiation of the frame rate is, that it is like= ly that the server can only provide a limited number of fixed frame rates. = It could have the coded video ready for these frame rates, but it would be = hard to provide any other frame rate. With the negotiation of a max frame r= ate, the source can choose a lower frame rate, as it already has the video = stream with that frame rate available. So a fixed frame rate negotiation would only work if there is only a limite= d number of common shutter glass frequencies and associated video frame rat= es. In that case the server can have video representations with matching fr= ame rates available. I think a common shutter glass frequency is 120 Hz (60 Hz/view). Common fra= me rates are 24 fps, 30 fps, 50 fps, 60 fps. If this is the case in general= , negotiation with an exact frame rate can work. Notice that the 24 fps and= 50 fps are not divisors of 60 Hz, but by displaying some of the frames one= time more than the other frames, it is still relatively easy to convert th= e frame rates to shutter glass frequencies. @Stephen: do you want to keep the meaning of the maximum frame rate because= you want to be able to choose a lower frame rate, for example because the = video is to be multiplexed with other video in the same RTP stream? @Ted: given the common frame rates in practise, do you think they still nee= d to be negotiated or will the shutter glasses be able to accept all of the= se? Then we could also add some informative text about this in the draft. Best regards, Bert From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 22 April 2011 01:30 To: Ted Hardie Cc: Bert Greevenbosch; lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today in-line Stephen Botzko On Thu, Apr 21, 2011 at 12:35 PM, Ted Hardie wrote: On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch wrote: Hi Ted, =A0 If I understand you well, you would like to be able to negotiate the video = frequency, such that it can easily be converted to the shutter glass freque= ncy. =A0 So for example, if the shutter glass frequency is 120Hz (60Hz/view), then r= easonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of 60H= z (or in the Frame Sequential case, 120Hz). In this case it is easy to upsa= mple the signal by repeating each frame sequence {Lk Rk} an integer number = of times. =A0 I have a preference to use the "framerate" attribute for this, as adding an= other rather similar parameter to the "3dFormat" attribute seems somehow do= uble. However, I also see your point in that the "framerate" attribute only= indicates a maximum frequency, not a guaranteed frequency. We could solve = this in the draft by mandating that in case of 3D streaming, the frequency = the video MUST equal the value of the "framerate" attribute, in case the "f= ramerate" attribute is included. Well, I agree that this solves the problem.=A0 I'm a little leary of having= the same parameter have two related but distinct meanings, depending on th= e context.=A0 But if no one else objects to this, I'm certainly willing to = go along.=A0 I think you are correct that the context is easy enough to det= ermine. regards, =A0 So this means that this video frequency negotiation can't be done for 3D vi= deo conferencing?=A0 Providing application-specific definitions for a param= eter seems like a problem to me, as many stacks / systems support multiple = applications, and good definitions of the application might be hard to craf= t.=A0=20 Are we sure we really need this negotiation to achieve interoperability?=A0= I'm not convinced myself.=A0 If we do, I think a new parameter is a better= approach. =A0 Ted Hardie =A0 =A0 What do you think? =A0 Best regards, Bert =A0 From: Ted Hardie [mailto:ted.ietf@gmail.com]=20 Sent: 16 April 2011 08:36 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today =A0 Hi, Some further comments in-line. On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch wrote: Hi Ted, =A0 My suspicion is that there are probably practical limits to some system's a= bility to either upsample or interpolate.=A0 Would it make sense to add som= ething to the 3dFormat line to indicate what the resulting per-view rate wi= ll be?=A0 So that a=3D3dFormat:FP SbS had an additional parameter: a=3D3dFormat:FP SbS 30Hz We could also consider using the SDP attribute "framerate" (RFC 4566). This= attribute would give the frame rate of the 2D channel stream, but we can w= rite in the draft that in the frame sequential case the frame rate per view= is half of it. The relevant text from RFC 4566 is: a=3Dframerate: =A0=A0=A0=A0=A0=A0=A0=A0 This gives the maximum video frame rate in frames/= sec.=A0 It is =A0=A0=A0=A0=A0=A0=A0=A0 intended as a recommendation for the encoding of v= ideo data. =A0=A0=A0=A0=A0=A0=A0=A0 Decimal representations of fractional values using= the notation =A0=A0=A0=A0=A0=A0=A0=A0 "." are allowed.=A0 It is a med= ia-level =A0=A0=A0=A0=A0=A0=A0=A0 attribute, defined only for video media, and it is= not =A0=A0=A0=A0=A0=A0=A0=A0 dependent on charset. While I think it could be re-used here, it seems to me to make more sense t= o use a separate indicator.=A0 This is partly because it is more for the de= coder/upsampler/interpolation check (Can I upsample this to something reaso= nable?=A0 If not, don't select this choice).=A0 And it's partly because I w= orry a bit about the interaction with existing code. =A0 =A0Or do you want to indicate the target shutter glass frequency? =A0 No, I think you're right that it's more likely that things will get adjuste= d to a standard shutter speed by upsampling than they will change the shutt= er speed. regards, Ted Hardie =A0 Best regards, Bert =A0 =A0 From: Ted Hardie [mailto:ted.ietf@gmail.com]=20 Sent: 15 April 2011 02:49 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today =A0 On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch wrote: I agree, the 30Hz (per view) case would give a flickering effect. Since nor= mal TVs have a frequency of 60Hz or more, for a similar quality with shutte= r glasses the frame rate should be 120Hz (=3D60 Hz/view) or more. =A0 But the receiver can also upsample the received signal to a higher display = rate. For example, if it receives the following frame sequence at 30Hz/view= : =A0 L1,R1,L2,R2,L3,R3,..., =A0 then it could display at 60Hz/view: =A0 L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... =A0 The receiver can also use some interpolation technique to generate the fram= es between Lk and L(k+1). =A0 I think that in praxis the receiving device will process the received strea= m to make it fit the display system. This allows different types/standards = of shutter glasses to be used, independent on the format in which the 3D st= ream was received. It also allows other display types such as polarisation = or autostereoscopic displays. =A0 My suspicion is that there are probably practical limits to some system's a= bility to either upsample or interpolate.=A0 Would it make sense to add som= ething to the 3dFormat line to indicate what the resulting per-view rate wi= ll be?=A0 So that a=3D3dFormat:FP SbS had an additional parameter: a=3D3dFormat:FP SbS 30Hz >I know only know one manufacturer's system at all well, and my understandi= ng is that the timing signals which synchronize them are really matching th= e frame start times to the shuttering, but don't adjust the frame rates.=A0= Are there glasses which can modify the rate substantially as well? =A0 Can you please explain a bit more about the system you are referring too, e= specially about not modifying the frame rate? Do you mean the frame rate be= tween the TV screen and the signalling device (that transmits the signal to= the shutter glasses) or the frame rate of the video stream as it is receiv= ed before it is decoded (by the codec)? =A0 I probably should have said "shuttering rate", sorry.=A0 I mean that it mat= ches the shutters to the alternating left and right view, but that the shut= tering rate is consistent (resulting in 60Hz per view, in this case).=20 regards, Ted Hardie =A0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From stephen.botzko@gmail.com Sat Apr 23 04:34:49 2011 Return-Path: X-Original-To: mmusic@ietfc.amsl.com Delivered-To: mmusic@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59A94E0681 for ; Sat, 23 Apr 2011 04:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP1ZTURVjWTV for ; Sat, 23 Apr 2011 04:34:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id A5FEBE0661 for ; Sat, 23 Apr 2011 04:34:46 -0700 (PDT) Received: by vws12 with SMTP id 12so1117564vws.31 for ; Sat, 23 Apr 2011 04:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ult1yNFFtsUZvoObhz6HCNFiTrLsCZCwE+6hrUjvtvM=; b=wZGQ7TG6NfAxICYpALOUIcZ7MqfJ/2qZ/L4aquhfR+Mq8UnwyMOsyGlk85bbA1icAJ mOd+IIDRY/yIzR09J5/I7gEoQojiqykzurOH3MBdO0Spfe61kUzoTXwERsqD/l1S78cH jEXS9Kv8YxtweuGye5TCamwPsVEjfWe8oRTmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F5YxjJB2XeJ7QZiigOf/7tL3uvqhq1Ih9NDpv8306AHgC7BIMOXHoF4sUmHlYHXWYr UfUmRVbkBDTtpWtBwhnWhHaQPdosIJlwx9MfmToCgGjFdV1raRpmaB145/ZEAMEhNlPS /vszAVSg0WMxKZrym+9Dd3Qvoi3Jyrmm+DdPM= MIME-Version: 1.0 Received: by 10.52.0.67 with SMTP id 3mr3212232vdc.261.1303558486329; Sat, 23 Apr 2011 04:34:46 -0700 (PDT) Received: by 10.52.161.226 with HTTP; Sat, 23 Apr 2011 04:34:46 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C7155@SZXEML501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C55AA@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB6012C7155@SZXEML501-MBS.china.huawei.com> Date: Sat, 23 Apr 2011 07:34:46 -0400 Message-ID: From: Stephen Botzko To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=20cf3054a11f85891f04a1945c0d Cc: "lennox@cs.columbia.edu" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remarks from today 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, 23 Apr 2011 11:34:49 -0000 --20cf3054a11f85891f04a1945c0d Content-Type: text/plain; charset=ISO-8859-1 in-line On Fri, Apr 22, 2011 at 10:55 PM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi Ted, Stephen, all, > > I have thought a bit more about the frame rate issue, especially why it is > originally defined as a maximum frame rate rather than an exact frame rate. > > The main problem with the negotiation of the frame rate is, that it is > likely that the server can only provide a limited number of fixed frame > rates. It could have the coded video ready for these frame rates, but it > would be hard to provide any other frame rate. With the negotiation of a max > frame rate, the source can choose a lower frame rate, as it already has the > video stream with that frame rate available. > I suspect you are thinking mostly about video streaming of stored media. There are video sources where you get substantially lower bit rates if you use a dynamic frame rate when encoding - particularly PC screens which often are relatively unchanging. Digital signage might have similar characteristics. In video conferencing (or other real-time encoding applications) it is common for encoders to drop frames during heavy motion or scene changes in order to maintain a bit rate constraint (trading off image sharpness for motion handling). If the video encoding is layered (for instance H.264 Annex G), it can be routed through a MANE. In this case, the frame rate (and the spatial resolution) are dynamically adjusted by the MANE in response to network conditions, with different receivers getting different resolutions and frame rates. > > So a fixed frame rate negotiation would only work if there is only a > limited number of common shutter glass frequencies and associated video > frame rates. In that case the server can have video representations with > matching frame rates available. > > I think a common shutter glass frequency is 120 Hz (60 Hz/view). Common > frame rates are 24 fps, 30 fps, 50 fps, 60 fps. If this is the case in > general, negotiation with an exact frame rate can work. Notice that the 24 > fps and 50 fps are not divisors of 60 Hz, but by displaying some of the > frames one time more than the other frames, it is still relatively easy to > convert the frame rates to shutter glass frequencies. > @Stephen: do you want to keep the meaning of the maximum frame rate because > you want to be able to choose a lower frame rate, for example because the > video is to be multiplexed with other video in the same RTP stream? > Part of my thinking is simply that it is a bad design practice to overload a parameter by giving it different meanings (even if the differences appear slight). Design principles aside, I believe that real-time applications (particularly video conferencing) will need variable frame rate for 3D (as they already do for 2D), for the reasons I pointed out above. As you point out, there is one easy (though sub-optimal) way to upsample / downsample frame rate to match the needed refresh rate - simple duplicating / dropping of frames. Since frames can be lost in transmission (and because sender and receiver clocks are not precisely matched), receivers will need to employ such techniques anyway. And shuttered glasses are only one way of rendering 3D; it is clear that shuttering, polarization and lenticular techniques will all co-exist. For many receivers, shutter rate doesn't apply at all. So I am still thinking that negotiation of shuttering rate (or fixed frame rate) is not required for 3D interoperability. An encoder is already free to send fixed frame rate video if it wishes; I think that is enough. Best Regards, Stephen > > @Ted: given the common frame rates in practise, do you think they still > need to be negotiated or will the shutter glasses be able to accept all of > these? Then we could also add some informative text about this in the draft. > > Best regards, > Bert > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: 22 April 2011 01:30 > To: Ted Hardie > Cc: Bert Greevenbosch; lennox@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] Remarks from today > > in-line > Stephen Botzko > On Thu, Apr 21, 2011 at 12:35 PM, Ted Hardie wrote: > On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > Hi Ted, > > If I understand you well, you would like to be able to negotiate the video > frequency, such that it can easily be converted to the shutter glass > frequency. > > So for example, if the shutter glass frequency is 120Hz (60Hz/view), then > reasonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of > 60Hz (or in the Frame Sequential case, 120Hz). In this case it is easy to > upsample the signal by repeating each frame sequence {Lk Rk} an integer > number of times. > > I have a preference to use the "framerate" attribute for this, as adding > another rather similar parameter to the "3dFormat" attribute seems somehow > double. However, I also see your point in that the "framerate" attribute > only indicates a maximum frequency, not a guaranteed frequency. We could > solve this in the draft by mandating that in case of 3D streaming, the > frequency the video MUST equal the value of the "framerate" attribute, in > case the "framerate" attribute is included. > > Well, I agree that this solves the problem. I'm a little leary of having > the same parameter have two related but distinct meanings, depending on the > context. But if no one else objects to this, I'm certainly willing to go > along. I think you are correct that the context is easy enough to > determine. > > regards, > > So this means that this video frequency negotiation can't be done for 3D > video conferencing? Providing application-specific definitions for a > parameter seems like a problem to me, as many stacks / systems support > multiple applications, and good definitions of the application might be hard > to craft. > > Are we sure we really need this negotiation to achieve interoperability? > I'm not convinced myself. If we do, I think a new parameter is a better > approach. > > > Ted Hardie > > > > What do you think? > > Best regards, > Bert > > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: 16 April 2011 08:36 > > To: Bert Greevenbosch > Cc: lennox@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] Remarks from today > > Hi, > > Some further comments in-line. > On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > Hi Ted, > > My suspicion is that there are probably practical limits to some system's > ability to either upsample or interpolate. Would it make sense to add > something to the 3dFormat line to indicate what the resulting per-view rate > will be? So that > > a=3dFormat:FP SbS > > had an additional parameter: > > a=3dFormat:FP SbS 30Hz > We could also consider using the SDP attribute "framerate" (RFC 4566). This > attribute would give the frame rate of the 2D channel stream, but we can > write in the draft that in the frame sequential case the frame rate per view > is half of it. > > The relevant text from RFC 4566 is: > a=framerate: > > > > > > > > This gives the maximum video frame rate in frames/sec. It is > > > > > > > > intended as a recommendation for the encoding of video data. > > > > Decimal representations of fractional values using the notation > > > > "." are allowed. It is a media-level > > > > > > > > attribute, defined only for video media, and it is not > > > > dependent on charset. > While I think it could be re-used here, it seems to me to make more sense > to use a separate indicator. This is partly because it is more for the > decoder/upsampler/interpolation check (Can I upsample this to something > reasonable? If not, don't select this choice). And it's partly because I > worry a bit about the interaction with existing code. > > > Or do you want to indicate the target shutter glass frequency? > > > No, I think you're right that it's more likely that things will get > adjusted to a standard shutter speed by upsampling than they will change the > shutter speed. > > regards, > > Ted Hardie > > Best regards, > Bert > > > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: 15 April 2011 02:49 > > To: Bert Greevenbosch > Cc: lennox@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] Remarks from today > > On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch < > Bert.Greevenbosch@huawei.com> wrote: > I agree, the 30Hz (per view) case would give a flickering effect. Since > normal TVs have a frequency of 60Hz or more, for a similar quality with > shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. > > But the receiver can also upsample the received signal to a higher display > rate. For example, if it receives the following frame sequence at 30Hz/view: > > L1,R1,L2,R2,L3,R3,..., > > then it could display at 60Hz/view: > > L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... > > The receiver can also use some interpolation technique to generate the > frames between Lk and L(k+1). > > I think that in praxis the receiving device will process the received > stream to make it fit the display system. This allows different > types/standards of shutter glasses to be used, independent on the format in > which the 3D stream was received. It also allows other display types such as > polarisation or autostereoscopic displays. > > > My suspicion is that there are probably practical limits to some system's > ability to either upsample or interpolate. Would it make sense to add > something to the 3dFormat line to indicate what the resulting per-view rate > will be? So that > > a=3dFormat:FP SbS > > had an additional parameter: > > a=3dFormat:FP SbS 30Hz > >I know only know one manufacturer's system at all well, and my > understanding is that the timing signals which synchronize them are really > matching the frame start times to the shuttering, but don't adjust the frame > rates. Are there glasses which can modify the rate substantially as well? > > Can you please explain a bit more about the system you are referring too, > especially about not modifying the frame rate? Do you mean the frame rate > between the TV screen and the signalling device (that transmits the signal > to the shutter glasses) or the frame rate of the video stream as it is > received before it is decoded (by the codec)? > > > I probably should have said "shuttering rate", sorry. I mean that it > matches the shutters to the alternating left and right view, but that the > shuttering rate is consistent (resulting in 60Hz per view, in this case). > > regards, > > Ted Hardie > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --20cf3054a11f85891f04a1945c0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line

On Fri, Apr 22, 2011 at 10:55 PM,= Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:
Hi Ted, Stephen, all,

I have thought a bit more about the frame rate issue, especially why it is = originally defined as a maximum frame rate rather than an exact frame rate.=

The main problem with the negotiation of the frame rate is, that it is like= ly that the server can only provide a limited number of fixed frame rates. = It could have the coded video ready for these frame rates, but it would be = hard to provide any other frame rate. With the negotiation of a max frame r= ate, the source can choose a lower frame rate, as it already has the video = stream with that frame rate available.
I suspect you are thinking mostly about video streaming o= f stored media.=A0

There are video sources where you get substantia= lly lower bit rates if=20 you use a dynamic frame rate when encoding - particularly PC screens=20 which often are relatively unchanging.=A0 Digital signage might have=20 similar characteristics.

In video conferencing (or other real-time e= ncoding applications) it is common for encoders to drop frames during heavy= motion or scene changes in order to maintain a bit rate constraint (tradin= g off image sharpness for motion handling).

If the video encoding is layered (for instance H.264 Annex G), it can b= e routed through a MANE.=A0 In this case, the frame rate (and the spatial r= esolution) are dynamically adjusted by the MANE in response to network cond= itions, with different receivers getting different resolutions and frame ra= tes.
=A0

So a fixed frame rate negotiation would only work if there is only a limite= d number of common shutter glass frequencies and associated video frame rat= es. In that case the server can have video representations with matching fr= ame rates available.

I think a common shutter glass frequency is 120 Hz (60 Hz/view). Common fra= me rates are 24 fps, 30 fps, 50 fps, 60 fps. If this is the case in general= , negotiation with an exact frame rate can work. Notice that the 24 fps and= 50 fps are not divisors of 60 Hz, but by displaying some of the frames one= time more than the other frames, it is still relatively easy to convert th= e frame rates to shutter glass frequencies.
=A0
@Stephen: do you want to keep the meaning of the maximum frame rate because= you want to be able to choose a lower frame rate, for example because the = video is to be multiplexed with other video in the same RTP stream?

Part of my thinking is simply that it is a bad design= practice to=20 overload a parameter by giving it different meanings (even if the=20 differences appear slight).
=A0
Design principles aside, I= believe that real-time applications (particularly video conferencing) will= need variable frame rate for 3D (as they already do for 2D), for the reaso= ns I pointed out above.=A0 As you point out, there is one easy (though sub-= optimal) way to=20 upsample / downsample frame rate to match the needed refresh rate - simple duplicating / dropping of frames.=A0 Since frames can be lost in=20 transmission (and because sender and receiver clocks are not precisely matc= hed), receivers will need to employ such techniques anyway.

And shut= tered glasses are only one way of rendering 3D;=A0 it is clear that shutter= ing, polarization and lenticular techniques will all co-exist. For many rec= eivers, shutter rate doesn't apply at all.=A0

So I am still thinking that negotiation of shuttering rate (or fixed fr= ame rate) is not required for 3D interoperability.=A0 An encoder is already= free to send fixed frame rate video if it wishes; I think that is enough.<= br>
Best Regards,
Stephen
=A0

@Ted: given the common frame rates in practise, do you think they still nee= d to be negotiated or will the shutter glasses be able to accept all of the= se? Then we could also add some informative text about this in the draft.
Best regards,
Bert



From: Stephen Botzko [mailto:st= ephen.botzko@gmail.com]
Sent: 22 April 2011 01:30
To: Ted Hardie
Cc: Bert Greevenbosch; lennox@cs.= columbia.edu; mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today<= br>
in-line
Stephen Botzko
On Thu, Apr 21, 2011 at 12:35 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Apr 18, 2011 at 7:52 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:
Hi Ted,
=A0
If I understand you well, you would like to be able to negotiate the video = frequency, such that it can easily be converted to the shutter glass freque= ncy.
=A0
So for example, if the shutter glass frequency is 120Hz (60Hz/view), then r= easonable video frequencies would be 60Hz, 40Hz, 30Hz, i.e. divisors of 60H= z (or in the Frame Sequential case, 120Hz). In this case it is easy to upsa= mple the signal by repeating each frame sequence {Lk Rk} an integer number = of times.
=A0
I have a preference to use the "framerate" attribute for this, as= adding another rather similar parameter to the "3dFormat" attrib= ute seems somehow double. However, I also see your point in that the "= framerate" attribute only indicates a maximum frequency, not a guarant= eed frequency. We could solve this in the draft by mandating that in case o= f 3D streaming, the frequency the video MUST equal the value of the "f= ramerate" attribute, in case the "framerate" attribute is in= cluded.

Well, I agree that this solves the problem.=A0 I'm a little leary of ha= ving the same parameter have two related but distinct meanings, depending o= n the context.=A0 But if no one else objects to this, I'm certainly wil= ling to go along.=A0 I think you are correct that the context is easy enoug= h to determine.

regards,
=A0
So this means that this video frequency negotiation can't be done for 3= D video conferencing?=A0 Providing application-specific definitions for a p= arameter seems like a problem to me, as many stacks / systems support multi= ple applications, and good definitions of the application might be hard to = craft.=A0

Are we sure we really need this negotiation to achieve interoperability?=A0= I'm not convinced myself.=A0 If we do, I think a new parameter is a be= tter approach.
=A0

Ted Hardie

=A0
=A0
What do you think?
=A0
Best regards,
Bert
=A0
From: Ted Hardie [mailto:ted.ietf@gma= il.com]
Sent: 16 April 2011 08:36

To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; <= a href=3D"mailto:mmusic@ietf.org">mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today
=A0
Hi,

Some further comments in-line.
On Thu, Apr 14, 2011 at 11:21 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote: Hi Ted,
=A0
My suspicion is that there are probably practical limits to some system'= ;s ability to either upsample or interpolate.=A0 Would it make sense to add= something to the 3dFormat line to indicate what the resulting per-view rat= e will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz
We could also consider using the SDP attribute "framerate" (RFC 4= 566). This attribute would give the frame rate of the 2D channel stream, bu= t we can write in the draft that in the frame sequential case the frame rat= e per view is half of it.

The relevant text from RFC 4566 is:
a=3Dframerate:<frame rate>







=A0=A0=A0=A0=A0=A0=A0=A0 This gives the maximum video frame rate in frames/= sec.=A0 It is







=A0=A0=A0=A0=A0=A0=A0=A0 intended as a recommendation for the encoding of v= ideo data.



=A0=A0=A0=A0=A0=A0=A0=A0 Decimal representations of fractional values using= the notation



=A0=A0=A0=A0=A0=A0=A0=A0 "<integer>.<fraction>" are a= llowed.=A0 It is a media-level







=A0=A0=A0=A0=A0=A0=A0=A0 attribute, defined only for video media, and it is= not



=A0=A0=A0=A0=A0=A0=A0=A0 dependent on charset.
While I think it could be re-used here, it seems to me to make more sense t= o use a separate indicator.=A0 This is partly because it is more for the de= coder/upsampler/interpolation check (Can I upsample this to something reaso= nable?=A0 If not, don't select this choice).=A0 And it's partly bec= ause I worry a bit about the interaction with existing code.

=A0
=A0Or do you want to indicate the target shutter glass frequency?
=A0

No, I think you're right that it's more likely that things will get= adjusted to a standard shutter speed by upsampling than they will change t= he shutter speed.

regards,

Ted Hardie
=A0
Best regards,
Bert
=A0
=A0
From: Ted Hardie [mailto:ted.ietf@gma= il.com]
Sent: 15 April 2011 02:49

To: Bert Greevenbosch
Cc: lennox@cs.columbia.edu; <= a href=3D"mailto:mmusic@ietf.org">mmusic@ietf.org
Subject: Re: [MMUSIC] Remarks from today
=A0
On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote: I agree, the 30Hz (per view) case would give a flickering effect. Since nor= mal TVs have a frequency of 60Hz or more, for a similar quality with shutte= r glasses the frame rate should be 120Hz (=3D60 Hz/view) or more.
=A0
But the receiver can also upsample the received signal to a higher display = rate. For example, if it receives the following frame sequence at 30Hz/view= :
=A0
=A0 =A0 =A0 L1,R1,L2,R2,L3,R3,...,
=A0
then it could display at 60Hz/view:
=A0
=A0 =A0 =A0 L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,....
=A0
The receiver can also use some interpolation technique to generate the fram= es between Lk and L(k+1).
=A0
I think that in praxis the receiving device will process the received strea= m to make it fit the display system. This allows different types/standards = of shutter glasses to be used, independent on the format in which the 3D st= ream was received. It also allows other display types such as polarisation = or autostereoscopic displays.
=A0

My suspicion is that there are probably practical limits to some system'= ;s ability to either upsample or interpolate.=A0 Would it make sense to add= something to the 3dFormat line to indicate what the resulting per-view rat= e will be?=A0 So that

a=3D3dFormat:FP SbS

had an additional parameter:

a=3D3dFormat:FP SbS 30Hz
>I know only know one manufacturer's system at all well, and my unde= rstanding is that the timing signals which synchronize them are really matc= hing the frame start times to the shuttering, but don't adjust the fram= e rates.=A0 Are there glasses which can modify the rate substantially as we= ll?
=A0
Can you please explain a bit more about the system you are referring too, e= specially about not modifying the frame rate? Do you mean the frame rate be= tween the TV screen and the signalling device (that transmits the signal to= the shutter glasses) or the frame rate of the video stream as it is receiv= ed before it is decoded (by the codec)?
=A0

I probably should have said "shuttering rate", sorry.=A0 I mean t= hat it matches the shutters to the alternating left and right view, but tha= t the shuttering rate is consistent (resulting in 60Hz per view, in this ca= se).

regards,

Ted Hardie
=A0


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


--20cf3054a11f85891f04a1945c0d-- From gsalguei@cisco.com Tue Apr 26 11:28:33 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C85E064A for ; Tue, 26 Apr 2011 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egE-AmAxvaKe for ; Tue, 26 Apr 2011 11:28:32 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE41E062B for ; Tue, 26 Apr 2011 11:28:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3QISToF023808; Tue, 26 Apr 2011 14:28:29 -0400 (EDT) Received: from dhcp-64-102-155-110.cisco.com (dhcp-64-102-155-110.cisco.com [64.102.155.110]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3QISTGJ016502; Tue, 26 Apr 2011 14:28:29 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=Apple-Mail-45--882204979 Date: Tue, 26 Apr 2011 14:28:29 -0400 Message-Id: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> To: mmusic Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Flemming Andreasen Subject: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Tue, 26 Apr 2011 18:28:33 -0000 --Apple-Mail-45--882204979 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, In reference to some discussion we had on the list recently, I wanted to = bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that oversight.=20 The draft can be found at: = http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-= 00 I would welcome any comments on the draft. Warm Regards, Gonzalo --Apple-Mail-45--882204979 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Folks,

In reference to some discussion we had on the list recently, I wanted to bring your attention to an Internet Draft I submitted that registers 'image' in the newly created SDP media type registry. For some reason (unbeknownst to me) this was omitted in RFC 4566 when the other media types were registered. This draft aims to rectify that oversight. 

The draft can be found at:

http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-00

I would welcome any comments on the draft.

Warm Regards,

Gonzalo


--Apple-Mail-45--882204979-- From kpfleming@digium.com Tue Apr 26 12:33:54 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E63E07FE for ; Tue, 26 Apr 2011 12:33:54 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YUW7X-IRioI for ; Tue, 26 Apr 2011 12:33:53 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4286EE07A8 for ; Tue, 26 Apr 2011 12:33:53 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QEnK6-0004Db-Fn for mmusic@ietf.org; Tue, 26 Apr 2011 13:49:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 80205D82AE for ; Tue, 26 Apr 2011 13:49:22 -0500 (CDT) 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 wwxQEMGXCTC7 for ; Tue, 26 Apr 2011 13:49:22 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 09F49D82AF for ; Tue, 26 Apr 2011 13:49:22 -0500 (CDT) Message-ID: <4DB713B1.9000604@digium.com> Date: Tue, 26 Apr 2011 13:49:21 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> In-Reply-To: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Tue, 26 Apr 2011 19:33:54 -0000 On 04/26/2011 01:28 PM, Gonzalo Salgueiro wrote: > Folks, > > In reference to some discussion we had on the list recently, I wanted to > bring your attention to an Internet Draft I submitted that registers > 'image' in the newly created SDP media type registry. For some reason > (unbeknownst to me) this was omitted in RFC 4566 when the other media > types were registered. This draft aims to rectify that oversight. > > The draft can be found at: > > http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-00 > > I would welcome any comments on the draft. My only comments is 'nice work' :-) -- 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 Wed Apr 27 05:32:15 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D611DE0739 for ; Wed, 27 Apr 2011 05:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2365QWqTbHu for ; Wed, 27 Apr 2011 05:32:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AE241E073D for ; Wed, 27 Apr 2011 05:32:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-6e-4db80cca54f4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C1.3C.11171.ACC08BD4; Wed, 27 Apr 2011 14:32:10 +0200 (CEST) Received: from [159.107.24.249] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 27 Apr 2011 14:32:09 +0200 Message-ID: <4DB80CC9.9080605@ericsson.com> Date: Wed, 27 Apr 2011 14:32:09 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] IETF 80 minutes posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:32:15 -0000 The IETF 80 MMUSIC minutes of the meeting are now available at: http://www.ietf.org/proceedings/80/minutes/mmusic.txt /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From keith.drage@alcatel-lucent.com Wed Apr 27 06:58:03 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D1DE079D for ; Wed, 27 Apr 2011 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.941 X-Spam-Level: X-Spam-Status: No, score=-105.941 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIUgojSuevRQ for ; Wed, 27 Apr 2011 06:57:59 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4BAE0704 for ; Wed, 27 Apr 2011 06:57:59 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3RDqbe4011943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Apr 2011 15:57:53 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 27 Apr 2011 15:57:12 +0200 From: "DRAGE, Keith (Keith)" To: Gonzalo Salgueiro , mmusic Date: Wed, 27 Apr 2011 15:57:11 +0200 Thread-Topic: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-00 Thread-Index: AcwEP8lOy98/KaxHR6q1m1q3+opFnAAod/fA Message-ID: References: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> In-Reply-To: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Flemming Andreasen Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Wed, 27 Apr 2011 13:58:03 -0000 Section 3 This document registers with IANA the 'image' media type in the Session Description Protocol (SDP) Parameters registry [SDP-IANA] in accordance with the "Standards Action" policy defined in Section 4.1 of [RFC5226]. >From the perspective of brevity, I do not believe the reference to RFC 5226= is necessary. IANA will apply the policy stated in the table, which now ex= ists, rather than anything that is said in this RFC. I also do not believe = you need the [SDP-IANA] reference. If you put the full stop after "registry= " you have clearly identified the table to IANA. This document registers with IANA the 'image' media type in the Session Description Protocol (SDP) Parameters registry. References RFC 2119 is never used as a reference. Delete. Otherwise the document looks good to me. Regards Keith ________________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Gonzalo Salgueiro Sent: 26 April 2011 19:28 To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-regist= ration-00 Folks, In reference to some discussion we had on the list recently, I wanted to br= ing your attention to an Internet Draft I submitted that registers 'image' = in the newly created SDP media type registry. For some reason (unbeknownst = to me) this was omitted in RFC 4566 when the other media types were registe= red. This draft aims to rectify that oversight.=A0 The draft can be found at: http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-0= 0 I would welcome any comments on the draft. Warm Regards, Gonzalo From gsalguei@cisco.com Wed Apr 27 09:50:41 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46236E084A for ; Wed, 27 Apr 2011 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmRhS6Exavt0 for ; Wed, 27 Apr 2011 09:50:40 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7913EE06F7 for ; Wed, 27 Apr 2011 09:50:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3RGob6w021295; Wed, 27 Apr 2011 12:50:37 -0400 (EDT) Received: from dhcp-64-102-155-110.cisco.com (dhcp-64-102-155-110.cisco.com [64.102.155.110]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3RGobbu009179; Wed, 27 Apr 2011 12:50:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--801677742 From: Gonzalo Salgueiro In-Reply-To: Date: Wed, 27 Apr 2011 12:50:36 -0400 Message-Id: <1A1E3EC8-7BBA-4A6F-A1E2-E90399D5012C@cisco.com> References: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Wed, 27 Apr 2011 16:50:41 -0000 --Apple-Mail-2--801677742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Many thanks for the feedback Keith. If we think there is value in making things a bit more brief by removing = the references to RFC 5226 and the SDP media type registry, then I can = certainly accommodate that. FYI - The reference to RFC 2119 is in Section 1. Warm Regards, Gonzalo On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote: > Section 3 >=20 > This document registers with IANA the 'image' media type in the > Session Description Protocol (SDP) Parameters registry [SDP-IANA] in > accordance with the "Standards Action" policy defined in Section 4.1 > of [RFC5226]. >=20 >> =46rom the perspective of brevity, I do not believe the reference to = RFC 5226 is necessary. IANA will apply the policy stated in the table, = which now exists, rather than anything that is said in this RFC. I also = do not believe you need the [SDP-IANA] reference. If you put the full = stop after "registry" you have clearly identified the table to IANA. >=20 > This document registers with IANA the 'image' media type in the > Session Description Protocol (SDP) Parameters registry. >=20 > References >=20 > RFC 2119 is never used as a reference. Delete. >=20 > Otherwise the document looks good to me. >=20 > Regards >=20 > Keith >=20 > ________________________________________ > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Gonzalo Salgueiro > Sent: 26 April 2011 19:28 > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00 >=20 > Folks, >=20 > In reference to some discussion we had on the list recently, I wanted = to bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that oversight.=20 >=20 > The draft can be found at: >=20 > = http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-= 00 >=20 > I would welcome any comments on the draft. >=20 > Warm Regards, >=20 > Gonzalo >=20 >=20 --Apple-Mail-2--801677742 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Many = thanks for the feedback Keith.

If we think there is = value in making things a bit more brief by removing the references to = RFC 5226 and the SDP media type registry, then I can certainly = accommodate that.

FYI - The reference to = RFC 2119 is in Section 1.

Warm = Regards,

Gonzalo

On Apr = 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote:

Section= 3

  This document registers with IANA the 'image' = media type in the
  Session Description Protocol (SDP) = Parameters registry [SDP-IANA] in
  accordance with the = "Standards Action" policy defined in Section 4.1
  of = [RFC5226].

=46rom the perspective of = brevity, I do not believe the reference to RFC 5226 is necessary. IANA = will apply the policy stated in the table, which now exists, rather than = anything that is said in this RFC. I also do not believe you need the = [SDP-IANA] reference. If you put the full stop after "registry" you have = clearly identified the table to IANA.

=   This document registers with IANA the 'image' media type in = the
  Session Description Protocol (SDP) Parameters = registry.

References

RFC 2119 is never used as a = reference. Delete.

Otherwise the document looks good to = me.

Regards

Keith

___________________________________= _____
From: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro
Sent: = 26 April 2011 19:28
To: mmusic
Cc: Flemming Andreasen
Subject: = [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00

Folks,

In = reference to some discussion we had on the list recently, I wanted to = bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that = oversight. 

The draft can be found at:

http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-r= egistration-00

I would welcome any comments on the = draft.

Warm = Regards,

Gonzalo



= --Apple-Mail-2--801677742-- From keith.drage@alcatel-lucent.com Thu Apr 28 03:06:26 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9A2E06D7 for ; Thu, 28 Apr 2011 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.952 X-Spam-Level: X-Spam-Status: No, score=-105.952 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXZTfjOEfBmS for ; Thu, 28 Apr 2011 03:06:25 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 71531E0676 for ; Thu, 28 Apr 2011 03:06:25 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3SA4qhQ029586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Apr 2011 12:06:21 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 28 Apr 2011 12:06:06 +0200 From: "DRAGE, Keith (Keith)" To: Gonzalo Salgueiro Date: Thu, 28 Apr 2011 12:06:05 +0200 Thread-Topic: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-00 Thread-Index: AcwE+0dXxg38DYbbTsyDnpxTxKYftQAkFxZA Message-ID: References: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> <1A1E3EC8-7BBA-4A6F-A1E2-E90399D5012C@cisco.com> In-Reply-To: <1A1E3EC8-7BBA-4A6F-A1E2-E90399D5012C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21F5DBC87FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Thu, 28 Apr 2011 10:06:26 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21F5DBC87FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But then there is no RFC 2119 language used in the document, except for ext= racted text (with associated references) from other documents, where the co= nventions in those other documents have to apply, rather than the ones in t= his document. Check with the RFC editor on the need for the 2119 boilerplate when no such= usage is made. Regards Keith ________________________________ From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com] Sent: 27 April 2011 17:51 To: DRAGE, Keith (Keith) Cc: mmusic; Flemming Andreasen Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-re= gistration-00 Many thanks for the feedback Keith. If we think there is value in making things a bit more brief by removing th= e references to RFC 5226 and the SDP media type registry, then I can certai= nly accommodate that. FYI - The reference to RFC 2119 is in Section 1. Warm Regards, Gonzalo On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote: Section 3 This document registers with IANA the 'image' media type in the Session Description Protocol (SDP) Parameters registry [SDP-IANA] in accordance with the "Standards Action" policy defined in Section 4.1 of [RFC5226]. >From the perspective of brevity, I do not believe the reference to RFC 5226= is necessary. IANA will apply the policy stated in the table, which now ex= ists, rather than anything that is said in this RFC. I also do not believe = you need the [SDP-IANA] reference. If you put the full stop after "registry= " you have clearly identified the table to IANA. This document registers with IANA the 'image' media type in the Session Description Protocol (SDP) Parameters registry. References RFC 2119 is never used as a reference. Delete. Otherwise the document looks good to me. Regards Keith ________________________________________ From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro Sent: 26 April 2011 19:28 To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-regist= ration-00 Folks, In reference to some discussion we had on the list recently, I wanted to br= ing your attention to an Internet Draft I submitted that registers 'image' = in the newly created SDP media type registry. For some reason (unbeknownst = to me) this was omitted in RFC 4566 when the other media types were registe= red. This draft aims to rectify that oversight. The draft can be found at: http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-0= 0 I would welcome any comments on the draft. Warm Regards, Gonzalo --_000_EDC0A1AE77C57744B664A310A0B23AE21F5DBC87FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But then there is no RFC 2119 language used in the document, except for extracted text (with associated references= ) from other documents, where the conventions in those other documents have to app= ly, rather than the ones in this document.

 

Check with the RFC editor on the need = for the 2119 boilerplate when no such usage is made.

 

Regards

 

Keith

 

From:= Gonzalo Salgueiro [mailto:gsalguei@cisco.com]
Sent: 27 April 2011 17:51 To: DRAGE, Keith (Keith)
Cc: mmusic; Flemming Andreas= en
Subject: Re: [MMUSIC] Notifi= cation for draft-salgueiro-mmusic-image-iana-registration-00

 

Many thanks for the feedback Keith.

 

If we think there is value in making things a bit more brief by removing the references to RFC 5226 and the SDP media type registry, then I= can certainly accommodate that.

 

FYI - The reference to RFC 2119 is in Section 1.

 

Warm Regards,

 

Gonzalo

 

On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote:=



Section 3

  This document registers with IANA the 'image' media type in the=
  Session Description Protocol (SDP) Parameters registry [SDP-IAN= A] in
  accordance with the "Standards Action" policy defined= in Section 4.1
  of [RFC5226].


From the perspective of brevity, I do not believe the reference to = RFC 5226 is necessary. IANA will apply the policy stated in the table, which no= w exists, rather than anything that is said in this RFC. I also do not believ= e you need the [SDP-IANA] reference. If you put the full stop after "registry" you have clearly identified the table to IANA.


  This document registers with IANA the 'image' media type in the=
  Session Description Protocol (SDP) Parameters registry.

References

RFC 2119 is never used as a reference. Delete.

Otherwise the document looks good to me.

Regards

Keith

________________________________________
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro
Sent: 26 April 2011 19:28
To: mmusic
Cc: Flemming Andreasen
Subject: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-00

Folks,

In reference to some discussion we had on the list recently, I wanted to br= ing your attention to an Internet Draft I submitted that registers 'image' in t= he newly created SDP media type registry. For some reason (unbeknownst to me) = this was omitted in RFC 4566 when the other media types were registered. This dr= aft aims to rectify that oversight. 

The draft can be found at:

http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-reg= istration-00

I would welcome any comments on the draft.

Warm Regards,

Gonzalo

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21F5DBC87FRMRSSXCHMBSC3d_-- From iesg-secretary@ietf.org Thu Apr 28 09:01:39 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8E6E0721; Thu, 28 Apr 2011 09:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMwH4TIvI3GD; Thu, 28 Apr 2011 09:01:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97764E0669; Thu, 28 Apr 2011 09:01:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110428160138.13587.58242.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2011 09:01:38 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:01:39 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'IANA Registry for Interactive Connectivity Establishment (ICE) Options' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/ No IPR declarations have been submitted directly on this I-D. From gsalguei@cisco.com Thu Apr 28 10:34:24 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CBBE0689 for ; Thu, 28 Apr 2011 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jat-TK3xARvj for ; Thu, 28 Apr 2011 10:34:23 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 198ADE0670 for ; Thu, 28 Apr 2011 10:34:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3SHYJ4O001406; Thu, 28 Apr 2011 13:34:19 -0400 (EDT) Received: from dhcp-64-102-155-110.cisco.com (dhcp-64-102-155-110.cisco.com [64.102.155.110]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3SHYIHZ028530; Thu, 28 Apr 2011 13:34:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--712655826 From: Gonzalo Salgueiro In-Reply-To: Date: Thu, 28 Apr 2011 13:34:18 -0400 Message-Id: References: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> <1A1E3EC8-7BBA-4A6F-A1E2-E90399D5012C@cisco.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Thu, 28 Apr 2011 17:34:24 -0000 --Apple-Mail-8--712655826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Good point Keith. I prematurely figured that if 2119 language appeared = ANYWHERE in the text, then the reference to it should be there. As you = rightly point out, if it is in quoted text, there is likely no need for = it. I'll verify and address this as appropriate. Warm regards, Gonzalo On Apr 28, 2011, at 6:06 AM, DRAGE, Keith (Keith) wrote: > But then there is no RFC 2119 language used in the document, except = for extracted text (with associated references) from other documents, = where the conventions in those other documents have to apply, rather = than the ones in this document. > =20 > Check with the RFC editor on the need for the 2119 boilerplate when no = such usage is made. > =20 > Regards > =20 > Keith > =20 > From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com]=20 > Sent: 27 April 2011 17:51 > To: DRAGE, Keith (Keith) > Cc: mmusic; Flemming Andreasen > Subject: Re: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00 > =20 > Many thanks for the feedback Keith. > =20 > If we think there is value in making things a bit more brief by = removing the references to RFC 5226 and the SDP media type registry, = then I can certainly accommodate that. > =20 > FYI - The reference to RFC 2119 is in Section 1. > =20 > Warm Regards, > =20 > Gonzalo > =20 > On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote: >=20 >=20 > Section 3 >=20 > This document registers with IANA the 'image' media type in the > Session Description Protocol (SDP) Parameters registry [SDP-IANA] in > accordance with the "Standards Action" policy defined in Section 4.1 > of [RFC5226]. >=20 >=20 > =46rom the perspective of brevity, I do not believe the reference to = RFC 5226 is necessary. IANA will apply the policy stated in the table, = which now exists, rather than anything that is said in this RFC. I also = do not believe you need the [SDP-IANA] reference. If you put the full = stop after "registry" you have clearly identified the table to IANA. >=20 > This document registers with IANA the 'image' media type in the > Session Description Protocol (SDP) Parameters registry. >=20 > References >=20 > RFC 2119 is never used as a reference. Delete. >=20 > Otherwise the document looks good to me. >=20 > Regards >=20 > Keith >=20 > ________________________________________ > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Gonzalo Salgueiro > Sent: 26 April 2011 19:28 > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00 >=20 > Folks, >=20 > In reference to some discussion we had on the list recently, I wanted = to bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that oversight.=20 >=20 > The draft can be found at: >=20 > = http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-= 00 >=20 > I would welcome any comments on the draft. >=20 > Warm Regards, >=20 > Gonzalo >=20 >=20 > =20 --Apple-Mail-8--712655826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Good point Keith. I prematurely figured that if = 2119 language appeared ANYWHERE in the text, then the reference to it = should be there. As you rightly point out, if it is in quoted text, = there is likely no need for it. I'll verify and address this as = appropriate.

Warm = regards,

Gonzalo

On Apr = 28, 2011, at 6:06 AM, DRAGE, Keith (Keith) wrote:

But then = there is no RFC 2119 language used in the document, except for extracted = text (with associated references) from other documents, where the = conventions in those other documents have to apply, rather than the ones = in this document.
Check with the RFC editor on the need for the 2119 = boilerplate when no such usage is = made.
 
 
 
 Gonzalo Salgueiro = [mailto:gsalguei@cisco.com] 
Sent: 27 April 2011 = 17:51
To: DRAGE, Keith = (Keith)
Cc: mmusic; Flemming = Andreasen
 Re: [MMUSIC] Notification = for draft-salgueiro-mmusic-image-iana-registration-00
Many thanks for the = feedback Keith.
 
If we think there is value in making things a bit more brief by = removing the references to RFC 5226 and the SDP media type registry, = then I can certainly accommodate = that.
FYI - The reference to RFC 2119 is in Section = 1.
Warm Regards,
 
Gonzalo
 
On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) = wrote:
Section = 3

  This document registers with IANA the 'image' media = type in the
  Session Description Protocol (SDP) Parameters = registry [SDP-IANA] in
  accordance with the "Standards = Action" policy defined in Section 4.1
  of = [RFC5226].


=46rom the perspective of brevity, I do not believe the = reference to RFC 5226 is necessary. IANA will apply the policy stated in = the table, which now exists, rather than anything that is said in this = RFC. I also do not believe you need the [SDP-IANA] reference. If you put = the full stop after "registry" you have clearly identified the table to = IANA.


  This document registers with IANA the 'image' = media type in the
  Session Description Protocol (SDP) = Parameters registry.

References

RFC 2119 is never used as = a reference. Delete.

Otherwise the document looks good to = me.

Regards

Keith

___________________________________= _____
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg] On Behalf Of Gonzalo Salgueiro
Sent: 26 April 2011 19:28
To: = mmusic
Cc: Flemming Andreasen
Subject: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00

Folks,

In = reference to some discussion we had on the list recently, I wanted to = bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that = oversight. 

The draft can be found at:

(IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard 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, 28 Apr 2011 17:22:13 -0000 This is a multi-part message in MIME format. --------------060409000201000508080501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, Some comments on this document, currently in Last Call. > Network Working Group M. Westerlund > Internet-Draft Ericsson > Updates:5245 (if approved) C. Perkins > Intended status: Standards Track University of Glasgow > Expires: September 29, 2011 March 28, 2011 I don't see why the intended status for this document is Standards Track. Wouldn't Informational be enough? Could you please justify why have you chosen it? Your registry description does not mention what is the precise name of the registry. While everybody understands that is sands for ICE options, it would be useful to give IANA distinctive guidelines on its name (this is also required in RFC5226, Section 4.2, 1) in the list; http://tools.ietf.org/html/rfc5226#section-4.2). From RFC 5226, also Section 4.2: > 5) Initial assignments and reservations. Clear instructions > should be provided to identify any initial assignments or > registrations. In addition, any ranges that are to be reserved > for "Private Use", "Reserved", "Unassigned", etc. should be > clearly indicated. Are there any initial assignments? Your document mentions one option; shouldn't it be registered? > A registration request MUST include the following information: > > [ . . . ] Shall this be mentioned as a registration template? > o Email and Address of the Contact person I think you should add the name of the contact person to the name of this field as well. I see, except some aforementioned issues, this document conforms to RFC 5226, particularly Section 4.2. Thanks in advance for considering my comments. Mykyta Yevstifeyev 28.04.2011 19:01, The IESG wrote: > The IESG has received a request from the Multiparty Multimedia Session > Control WG (mmusic) to consider the following document: > - 'IANA Registry for Interactive Connectivity Establishment (ICE) > Options' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-05-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/ > > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --------------060409000201000508080501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

Some comments on this document, currently in Last Call.

Network Working Group                                      M. Westerlund
Internet-Draft                                                  Ericsson
Updates: 5245 (if approved)                                   C. Perkins
Intended status: Standards Track                   University of Glasgow
Expires: September 29, 2011                               March 28, 2011
I don't see why the intended status for this document is Standards Track.  Wouldn't Informational be enough?  Could you please justify why have you chosen it?

Your registry description does not mention what is the precise name of the registry.  While everybody understands that is sands for ICE options, it would be useful to give IANA distinctive guidelines on its name (this is also required in RFC5226, Section 4.2, 1) in the list; http://tools.ietf.org/html/rfc5226#section-4.2).

From RFC 5226, also Section 4.2:

 5) Initial assignments and reservations.  Clear instructions
         should be provided to identify any initial assignments or
         registrations.  In addition, any ranges that are to be reserved
 for "Private Use", "Reserved", "Unassigned", etc. should be
         clearly indicated.

Are there any initial assignments?  Your document mentions one option; shouldn't it be registered?

 A registration request MUST include the following information:

   [ . . . ]
Shall this be mentioned as a registration template?

o  Email and Address of the Contact person
I think you should add the name of the contact person to the name of this field as well.

I see, except some aforementioned issues, this document conforms to RFC 5226, particularly Section 4.2.

Thanks in advance for considering my comments.

Mykyta Yevstifeyev

28.04.2011 19:01, The IESG wrote: 
The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'IANA Registry for Interactive Connectivity Establishment (ICE)
Options'
  <draft-ietf-mmusic-ice-options-registry-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/



No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------060409000201000508080501-- From magnus.westerlund@ericsson.com Fri Apr 29 01:47:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18718E06B2; Fri, 29 Apr 2011 01:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlTg6m6byUWk; Fri, 29 Apr 2011 01:47:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AEDD5E0678; Fri, 29 Apr 2011 01:47:14 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-17-4dba7b11695b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D5.4A.28525.11B7ABD4; Fri, 29 Apr 2011 10:47:13 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 29 Apr 2011 10:47:13 +0200 Message-ID: <4DBA7B11.8080708@ericsson.com> Date: Fri, 29 Apr 2011 10:47:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <20110428160138.13587.58242.idtracker@ietfa.amsl.com> <4DB9A26C.9010303@gmail.com> In-Reply-To: <4DB9A26C.9010303@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-ice-options-registry@tools.ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard 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, 29 Apr 2011 08:47:19 -0000 Hi Mykyta, Thanks for the review. See inline for response. Mykyta Yevstifeyev skrev 2011-04-28 19:22: > Hello, > > Some comments on this document, currently in Last Call. > >> Network Working Group M. Westerlund >> Internet-Draft Ericsson >> Updates: 5245 (if approved) C. Perkins >> Intended status: Standards Track University of Glasgow >> Expires: September 29, 2011 March 28, 2011 > I don't see why the intended status for this document is Standards > Track. Wouldn't Informational be enough? Could you please justify why > have you chosen it? I don't think we have put much thought into it. But one reason I can think of is to have it on the same maturity level as the ICE specification itself. Thus enabling a merge of this registry into an update of RFC 5245 without forcing it to be recycled as proposed. > > Your registry description does not mention what is the precise name of > the registry. While everybody understands that is sands for ICE > options, it would be useful to give IANA distinctive guidelines on its > name (this is also required in RFC5226, Section 4.2, 1) in the list; > http://tools.ietf.org/html/rfc5226#section-4.2). Yes, I agree that it should be included in Section 3.1 of our document rather than only in the title which says "Interactive Connectivity Establishment (ICE) Options" > > From RFC 5226, also Section 4.2: > >> 5) Initial assignments and reservations. Clear instructions >> should be provided to identify any initial assignments or >> registrations. In addition, any ranges that are to be reserved >> for "Private Use", "Reserved", "Unassigned", etc. should be >> clearly indicated. > > Are there any initial assignments? Your document mentions one option; > shouldn't it be registered? No, because when draft-ietf-avtcore-rtp-ecn gets published that will actually do the registration. As that document isn't approved yet and in fact still not WG last called this registry will first be created empty and then populated. > >> A registration request MUST include the following information: >> >> [ . . . ] > Shall this be mentioned as a registration template? It isn't written as one. It is a list of what needs to be present in the registration. And I think a template would be more focused on what needs to the general categories rather than the information. Thus I don't want this as registration template. > >> o Email and Address of the Contact person > I think you should add the name of the contact person to the name of > this field as well. As the two first bullets are: o Name of contact person for the registration o Email and Address of the Contact person I don't quite understand your comment. Do you want us to merge the two entries? This as the contact persons will need to provide name, email and address. I am fine with merging them and this is likely a slight improvement. Cheers 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 evnikita2@gmail.com Fri Apr 29 09:03:47 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4F5E06A7; Fri, 29 Apr 2011 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.577 X-Spam-Level: X-Spam-Status: No, score=-4.577 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4QpyDj7ip-B; Fri, 29 Apr 2011 09:03:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7FBE06A2; Fri, 29 Apr 2011 09:03:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so3009380fxm.31 for ; Fri, 29 Apr 2011 09:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+AKobDRo/SnBE04OibQ/c3A8r/dOvOkK7HDXldEmZ7E=; b=ToIdKbyVRMiDRPfkdWlVWM4y/KyZKuIbFRHzZBhPbPa/ocUhWTzZ831qdCDmEBKXT1 pYKMn9I/GsPemgga3LgSG+yDrPiYr/SaTBzDFWp/3a2lrbYh+V+4Jv6oTgnEMVOxVD49 BHqghoOBI0xJ6ppSB3SYFKEIRWMXX0QAqawuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=V/K+HUsHsUEIXc0WDZZfoSfEbXX9jKsy3iW9WMSVk7knO+qwMrClp5Qsmww8759sZ8 omF1FQgLR2r2tmDtc/0nOEklPC8NgTKfBbYexL6ZMDDgxgFTGucdSmhzgsQcctP6KSa6 4Pg+bHzSVr9jdo1I2eTAQvUuUrQFR6VWqTm2k= Received: by 10.223.100.15 with SMTP id w15mr296252fan.11.1304093011583; Fri, 29 Apr 2011 09:03:31 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id j12sm940093fax.9.2011.04.29.09.03.29 (version=SSLv3 cipher=OTHER); Fri, 29 Apr 2011 09:03:30 -0700 (PDT) Message-ID: <4DBAE17E.6050807@gmail.com> Date: Fri, 29 Apr 2011 19:04:14 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Magnus Westerlund References: <20110428160138.13587.58242.idtracker@ietfa.amsl.com> <4DB9A26C.9010303@gmail.com> <4DBA7B11.8080708@ericsson.com> In-Reply-To: <4DBA7B11.8080708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 29 Apr 2011 10:09:26 -0700 Cc: "draft-ietf-mmusic-ice-options-registry@tools.ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard 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, 29 Apr 2011 16:03:47 -0000 Magnus, 29.04.2011 11:47, Magnus Westerlund wrote: > Hi Mykyta, > > Thanks for the review. > > See inline for response. > > Mykyta Yevstifeyev skrev 2011-04-28 19:22: >> Hello, >> >> Some comments on this document, currently in Last Call. >> >>> Network Working Group M. Westerlund >>> Internet-Draft Ericsson >>> Updates: 5245 (if approved) C. Perkins >>> Intended status: Standards Track University of Glasgow >>> Expires: September 29, 2011 March 28, 2011 >> I don't see why the intended status for this document is Standards >> Track. Wouldn't Informational be enough? Could you please justify why >> have you chosen it? > I don't think we have put much thought into it. But one reason I can > think of is to have it on the same maturity level as the ICE > specification itself. Thus enabling a merge of this registry into an > update of RFC 5245 without forcing it to be recycled as proposed. This is a good reason, so I'll agree with it. >> Your registry description does not mention what is the precise name of >> the registry. While everybody understands that is sands for ICE >> options, it would be useful to give IANA distinctive guidelines on its >> name (this is also required in RFC5226, Section 4.2, 1) in the list; >> http://tools.ietf.org/html/rfc5226#section-4.2). > > Yes, I agree that it should be included in Section 3.1 of our document > rather than only in the title which says "Interactive Connectivity > Establishment (ICE) Options" Agreed on this. Such name is fine, IMO. >> From RFC 5226, also Section 4.2: >> >>> 5) Initial assignments and reservations. Clear instructions >>> should be provided to identify any initial assignments or >>> registrations. In addition, any ranges that are to be reserved >>> for "Private Use", "Reserved", "Unassigned", etc. should be >>> clearly indicated. >> Are there any initial assignments? Your document mentions one option; >> shouldn't it be registered? > No, because when draft-ietf-avtcore-rtp-ecn gets published that will > actually do the registration. As that document isn't approved yet and in > fact still not WG last called this registry will first be created empty > and then populated. So you should have mentioned this in the draft as well. >>> A registration request MUST include the following information: >>> >>> [ . . . ] >> Shall this be mentioned as a registration template? > It isn't written as one. It is a list of what needs to be present in the > registration. And I think a template would be more focused on what needs > to the general categories rather than the information. Thus I don't want > this as registration template. OK, this matter is not very important. >>> o Email and Address of the Contact person >> I think you should add the name of the contact person to the name of >> this field as well. > As the two first bullets are: > > o Name of contact person for the registration > > o Email and Address of the Contact person > > I don't quite understand your comment. Do you want us to merge the two > entries? This as the contact persons will need to provide name, email > and address. I am fine with merging them and this is likely a slight > improvement. No, I didn't propose to merge it. I just proposed to rename this field as "Name, Email and Addresses of the Contact Person". Thanks for taking time to response to my comments. Mykyta Yevstifeyev > Cheers > > 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 gsalguei@cisco.com Sat Apr 30 11:08:04 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BEAE06C2 for ; Sat, 30 Apr 2011 11:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfyR8FoC225p for ; Sat, 30 Apr 2011 11:08:03 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 50983E06B9 for ; Sat, 30 Apr 2011 11:08:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3UI7xT7012770; Sat, 30 Apr 2011 14:07:59 -0400 (EDT) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3UI7rfm024457; Sat, 30 Apr 2011 14:07:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28--537840726 From: Gonzalo Salgueiro In-Reply-To: Date: Sat, 30 Apr 2011 14:07:53 -0400 Message-Id: <99AD85AE-F2BE-4713-A196-6B1B97994F84@cisco.com> References: <27FDAD4D-2EC4-48D1-A357-622BE582BDCA@cisco.com> <1A1E3EC8-7BBA-4A6F-A1E2-E90399D5012C@cisco.com> To: mmusic X-Mailer: Apple Mail (2.1084) Cc: "DRAGE, Keith \(Keith\)" Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-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: Sat, 30 Apr 2011 18:08:04 -0000 --Apple-Mail-28--537840726 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've submitted an -01 version that addresses all the comments raised = thus far as well as a few additional nits. Feedback welcome. Warm Regards, Gonzalo On Apr 28, 2011, at 1:34 PM, Gonzalo Salgueiro wrote: > Good point Keith. I prematurely figured that if 2119 language appeared = ANYWHERE in the text, then the reference to it should be there. As you = rightly point out, if it is in quoted text, there is likely no need for = it. I'll verify and address this as appropriate. >=20 > Warm regards, >=20 > Gonzalo >=20 > On Apr 28, 2011, at 6:06 AM, DRAGE, Keith (Keith) wrote: >=20 >> But then there is no RFC 2119 language used in the document, except = for extracted text (with associated references) from other documents, = where the conventions in those other documents have to apply, rather = than the ones in this document. >> =20 >> Check with the RFC editor on the need for the 2119 boilerplate when = no such usage is made. >> =20 >> Regards >> =20 >> Keith >> =20 >> From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com]=20 >> Sent: 27 April 2011 17:51 >> To: DRAGE, Keith (Keith) >> Cc: mmusic; Flemming Andreasen >> Subject: Re: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00 >> =20 >> Many thanks for the feedback Keith. >> =20 >> If we think there is value in making things a bit more brief by = removing the references to RFC 5226 and the SDP media type registry, = then I can certainly accommodate that. >> =20 >> FYI - The reference to RFC 2119 is in Section 1. >> =20 >> Warm Regards, >> =20 >> Gonzalo >> =20 >> On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote: >>=20 >>=20 >> Section 3 >>=20 >> This document registers with IANA the 'image' media type in the >> Session Description Protocol (SDP) Parameters registry [SDP-IANA] = in >> accordance with the "Standards Action" policy defined in Section = 4.1 >> of [RFC5226]. >>=20 >>=20 >> =46rom the perspective of brevity, I do not believe the reference to = RFC 5226 is necessary. IANA will apply the policy stated in the table, = which now exists, rather than anything that is said in this RFC. I also = do not believe you need the [SDP-IANA] reference. If you put the full = stop after "registry" you have clearly identified the table to IANA. >>=20 >> This document registers with IANA the 'image' media type in the >> Session Description Protocol (SDP) Parameters registry. >>=20 >> References >>=20 >> RFC 2119 is never used as a reference. Delete. >>=20 >> Otherwise the document looks good to me. >>=20 >> Regards >>=20 >> Keith >>=20 >> ________________________________________ >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Gonzalo Salgueiro >> Sent: 26 April 2011 19:28 >> To: mmusic >> Cc: Flemming Andreasen >> Subject: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00 >>=20 >> Folks, >>=20 >> In reference to some discussion we had on the list recently, I wanted = to bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that oversight.=20 >>=20 >> The draft can be found at: >>=20 >> = http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-= 00 >>=20 >> I would welcome any comments on the draft. >>=20 >> Warm Regards, >>=20 >> Gonzalo >>=20 >>=20 >> =20 >=20 --Apple-Mail-28--537840726 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I've = submitted an -01 version that addresses all the comments raised thus far = as well as  a few additional nits.

Feedback = welcome.

Warm = Regards,

Gonzalo

On Apr = 28, 2011, at 1:34 PM, Gonzalo Salgueiro wrote:

Good point Keith. I prematurely = figured that if 2119 language appeared ANYWHERE in the text, then the = reference to it should be there. As you rightly point out, if it is in = quoted text, there is likely no need for it. I'll verify and address = this as appropriate.

Warm = regards,

Gonzalo

On Apr = 28, 2011, at 6:06 AM, DRAGE, Keith (Keith) wrote:

But then = there is no RFC 2119 language used in the document, except for extracted = text (with associated references) from other documents, where the = conventions in those other documents have to apply, rather than the ones = in this document.
Check with the RFC editor on the need for the 2119 = boilerplate when no such usage is = made.
 
 
 
 Gonzalo Salgueiro = [mailto:gsalguei@cisco.com] 
Sent: 27 April 2011 = 17:51
To: DRAGE, Keith = (Keith)
Cc: mmusic; Flemming = Andreasen
 Re: [MMUSIC] Notification = for draft-salgueiro-mmusic-image-iana-registration-00
Many thanks for the = feedback Keith.
 
If we think there is value in making things a bit more brief by = removing the references to RFC 5226 and the SDP media type registry, = then I can certainly accommodate = that.
FYI - The reference to RFC 2119 is in Section = 1.
Warm Regards,
 
Gonzalo
 
On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) = wrote:
Section = 3

  This document registers with IANA the 'image' media = type in the
  Session Description Protocol (SDP) Parameters = registry [SDP-IANA] in
  accordance with the "Standards = Action" policy defined in Section 4.1
  of = [RFC5226].


=46rom the perspective of brevity, I do not believe the = reference to RFC 5226 is necessary. IANA will apply the policy stated in = the table, which now exists, rather than anything that is said in this = RFC. I also do not believe you need the [SDP-IANA] reference. If you put = the full stop after "registry" you have clearly identified the table to = IANA.


  This document registers with IANA the 'image' = media type in the
  Session Description Protocol (SDP) = Parameters registry.

References

RFC 2119 is never used as = a reference. Delete.

Otherwise the document looks good to = me.

Regards

Keith

___________________________________= _____
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg] On Behalf Of Gonzalo Salgueiro
Sent: 26 April 2011 19:28
To: = mmusic
Cc: Flemming Andreasen
Subject: [MMUSIC] Notification for = draft-salgueiro-mmusic-image-iana-registration-00

Folks,

In = reference to some discussion we had on the list recently, I wanted to = bring your attention to an Internet Draft I submitted that registers = 'image' in the newly created SDP media type registry. For some reason = (unbeknownst to me) this was omitted in RFC 4566 when the other media = types were registered. This draft aims to rectify that = oversight. 

The draft can be found at: