From mmusic-bounces@ietf.org Mon Feb 2 02:41:16 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6563A69BF; Mon, 2 Feb 2009 02:41:16 -0800 (PST) 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 7E21A3A69BF for ; Mon, 2 Feb 2009 02:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 XGyQWTL-0i6d for ; Mon, 2 Feb 2009 02:41:14 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 7CB413A68A6 for ; Mon, 2 Feb 2009 02:41:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4AA8F2C01898A; Mon, 2 Feb 2009 11:40:55 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+oWoM+jimkI; Mon, 2 Feb 2009 11:40:55 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 26CC92C0008DF; Mon, 2 Feb 2009 11:40:40 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 Feb 2009 11:40:38 +0100 Message-ID: <547F018265F92642B577B986577D671C63C8BB@VENUS.office> In-Reply-To: <200901081037.40509.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP From header issue thread-index: AclxbH5NBbOiRWBsSWWKFRixmvOVEwTtbp9g References: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> <200901081037.40509.remi.denis-courmont@nokia.com> From: "Martin Stiemerling" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , Cc: ext Ingemar Johansson S Subject: Re: [MMUSIC] RTSP From header issue 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hi, A good question anyhow. I also did wonder about the from header while editi= ng the HTTP parts of the draft. = I wouldn't removing it, as it does look a bit as legacy which isn't used. Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 = > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of R=E9mi Denis-Courmont > Sent: Thursday, January 08, 2009 9:38 AM > To: mmusic@ietf.org > Cc: ext Ingemar Johansson S > Subject: Re: [MMUSIC] RTSP From header issue > = > On Thursday 08 January 2009 10:33:25 ext Ingemar Johansson S, you > wrote: > > Hi > > > > Going through the syntax of the parts that handles URI's I found a > possible > > issue with the syntax of the From header. 1) In section 16.23 in RTSP > 2.0 > > there is only a reference section 14.22 in RFC2616 which contains a > rather > > simple definition. From =3D "From" ":" mailbox > > Section 20.2.3 in RTSP 2.0 however contains a much more elaborate > > definition with extensions (from-param). Isn't it better to specify > > something in section 16.23 like "The From header is defined in in > [H14.22] > > but is extended in this specification" ? > = > Is anyone using the From: in HTTP or RTSP anyhow? I guess not. > = > -- > R=E9mi Denis-Courmont > Maemo Software, Nokia Devices R&D > _______________________________________________ > 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 mmusic-bounces@ietf.org Mon Feb 2 02:46:40 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573A63A6A0C; Mon, 2 Feb 2009 02:46:40 -0800 (PST) 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 136433A6A0C for ; Mon, 2 Feb 2009 02:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 etGAcUjdBrdu for ; Mon, 2 Feb 2009 02:46:38 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D2B803A68A6 for ; Mon, 2 Feb 2009 02:46:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4EFDC2C01898A; Mon, 2 Feb 2009 11:46:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtzPX6BM24Lm; Mon, 2 Feb 2009 11:46:18 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 2E4022C0008DF; Mon, 2 Feb 2009 11:46:03 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 Feb 2009 11:46:02 +0100 Message-ID: <547F018265F92642B577B986577D671C63C8C2@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP From header issue thread-index: AclxbH5NBbOiRWBsSWWKFRixmvOVEwTtbp9gAABLakA= References: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> <200901081037.40509.remi.denis-courmont@nokia.com> From: "Martin Stiemerling" To: "Martin Stiemerling" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , Cc: ext Ingemar Johansson S Subject: Re: [MMUSIC] RTSP From header issue 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org well, it should read I wouldn't mind removing... Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 = > -----Original Message----- > From: Martin Stiemerling > Sent: Monday, February 02, 2009 11:41 AM > To: 'R=E9mi Denis-Courmont'; mmusic@ietf.org > Cc: ext Ingemar Johansson S > Subject: RE: [MMUSIC] RTSP From header issue > = > Hi, > = > A good question anyhow. I also did wonder about the from header while > editing the HTTP parts of the draft. > = > I wouldn't removing it, as it does look a bit as legacy which isn't > used. > = > Martin > = > stiemerling@nw.neclab.eu > = > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of R=E9mi Denis-Courmont > > Sent: Thursday, January 08, 2009 9:38 AM > > To: mmusic@ietf.org > > Cc: ext Ingemar Johansson S > > Subject: Re: [MMUSIC] RTSP From header issue > > > > On Thursday 08 January 2009 10:33:25 ext Ingemar Johansson S, you > > wrote: > > > Hi > > > > > > Going through the syntax of the parts that handles URI's I found a > > possible > > > issue with the syntax of the From header. 1) In section 16.23 in > RTSP > > 2.0 > > > there is only a reference section 14.22 in RFC2616 which contains a > > rather > > > simple definition. From =3D "From" ":" mailbox > > > Section 20.2.3 in RTSP 2.0 however contains a much more elaborate > > > definition with extensions (from-param). Isn't it better to specify > > > something in section 16.23 like "The From header is defined in in > > [H14.22] > > > but is extended in this specification" ? > > > > Is anyone using the From: in HTTP or RTSP anyhow? I guess not. > > > > -- > > R=E9mi Denis-Courmont > > Maemo Software, Nokia Devices R&D > > _______________________________________________ > > 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 mmusic-bounces@ietf.org Mon Feb 2 02:52:09 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7532D3A69E0; Mon, 2 Feb 2009 02:52:09 -0800 (PST) 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 6F5E63A69E0 for ; Mon, 2 Feb 2009 02:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 HHgproBGLcY7 for ; Mon, 2 Feb 2009 02:52:06 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D407E3A68A6 for ; Mon, 2 Feb 2009 02:52:04 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n12ApcNN029684; Mon, 2 Feb 2009 12:51:40 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 12:51:38 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 12:51:37 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n12Apaac002821; Mon, 2 Feb 2009 12:51:36 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: ext Martin Stiemerling Date: Mon, 2 Feb 2009 12:52:01 +0200 User-Agent: KMail/1.10.3 (Linux/2.6.27.13; KDE/4.1.3; i686; ; ) References: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> <200901081037.40509.remi.denis-courmont@nokia.com> <547F018265F92642B577B986577D671C63C8BB@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C63C8BB@VENUS.office> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200902021252.02398.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Feb 2009 10:51:38.0008 (UTC) FILETIME=[3919D180:01C98524] X-Nokia-AV: Clean Cc: ext Ingemar Johansson S , "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP From header issue 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org On Monday 02 February 2009 12:40:38 ext Martin Stiemerling, you wrote: > A good question anyhow. I also did wonder about the from header while > editing the HTTP parts of the draft. > > I wouldn't removing it, as it does look a bit as legacy which isn't used. ^ mind? I definitely would remove it. It is not used. There are high-level reasons = not = to use it: privacy/spam. There is a low-level reasons not to use it: media = player is typically not provisioned with email address. I would even advocate removing it from httpbis, if I were asked... -- = R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From ingemar.s.johansson@ericsson.com Wed Feb 4 00:48:34 2009 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 CED0928C164 for ; Wed, 4 Feb 2009 00:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 JX4mB4FaIyiR for ; Wed, 4 Feb 2009 00:48:34 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CC8BC28C0F0 for ; Wed, 4 Feb 2009 00:48:33 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C175228C6; Wed, 4 Feb 2009 09:41:59 +0100 (CET) X-AuditID: c1b4fb3e-ad06cbb00000429e-ff-498954d64848 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC9A7228C8; Wed, 4 Feb 2009 09:41:58 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 09:41:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2009 09:41:03 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C480FCE@esealmw109.eemea.ericsson.se> In-Reply-To: <200902021252.02398.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP From header issue Thread-Index: AcmFJDvcDXo57+lbQQ6K/dxvq/4apABfzrgQ References: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> <200901081037.40509.remi.denis-courmont@nokia.com> <547F018265F92642B577B986577D671C63C8BB@VENUS.office> <200902021252.02398.remi.denis-courmont@nokia.com> From: "Ingemar Johansson S" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "ext Martin Stiemerling" X-OriginalArrivalTime: 04 Feb 2009 08:41:58.0199 (UTC) FILETIME=[70CCAC70:01C986A4] X-Brightmail-Tracker: AAAAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP From header issue 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, 04 Feb 2009 08:48:34 -0000 Hi I have no specific opinon about the existence of the From header. I would however like bring up my second question about the use of DQ = around URI's.=20 >3) In general. The idea to use DQ around URI's in some cases and in = some cases=20 > not may cause some headache for the implementor.=20 > Sure, one should read the ABNF but I would say that it would be more=20 > consistent to always use DQ around URI's in headers regardless if they = are needed or not. Any comments ? Regards /Ingemar > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 > Sent: den 2 februari 2009 11:52 > To: ext Martin Stiemerling > Cc: mmusic@ietf.org; Ingemar Johansson S > Subject: Re: [MMUSIC] RTSP From header issue >=20 > On Monday 02 February 2009 12:40:38 ext Martin Stiemerling, you wrote: > > A good question anyhow. I also did wonder about the from=20 > header while=20 > > editing the HTTP parts of the draft. > > > > I wouldn't removing it, as it does look a bit as legacy=20 > which isn't used. > ^ > mind? >=20 > I definitely would remove it. It is not used. There are=20 > high-level reasons not to use it: privacy/spam. There is a=20 > low-level reasons not to use it: media player is typically=20 > not provisioned with email address. >=20 > I would even advocate removing it from httpbis, if I were asked... >=20 > -- > R=E9mi Denis-Courmont > Maemo Software, Nokia Devices R&D >=20 From Stiemerling@nw.neclab.eu Wed Feb 4 01:07:54 2009 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 EC5C93A6C5F for ; Wed, 4 Feb 2009 01:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 XEQd6byvMzBs for ; Wed, 4 Feb 2009 01:07:54 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C9ED13A6C5E for ; Wed, 4 Feb 2009 01:06:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 314132C017B31; Wed, 4 Feb 2009 10:06:31 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBmfC5zxWaFC; Wed, 4 Feb 2009 10:06:31 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 0D45F2C00030D; Wed, 4 Feb 2009 10:06:16 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Feb 2009 10:06:15 +0100 Message-ID: <547F018265F92642B577B986577D671C63CB6B@VENUS.office> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C480FCE@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP From header issue thread-index: AcmFJDvcDXo57+lbQQ6K/dxvq/4apABfzrgQAAD2oTA= References: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se><200901081037.40509.remi.denis-courmont@nokia.com><547F018265F92642B577B986577D671C63C8BB@VENUS.office><200902021252.02398.remi.denis-courmont@nokia.com> <130EBB38279E9847BAAAE0B8F9905F8C480FCE@esealmw109.eemea.ericsson.se> From: "Martin Stiemerling" To: "Ingemar Johansson S" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP From header issue 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, 04 Feb 2009 09:07:55 -0000 Hi Ingemar, > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ingemar Johansson S > Sent: Wednesday, February 04, 2009 9:41 AM > To: R=E9mi Denis-Courmont; Martin Stiemerling > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP From header issue >=20 > Hi >=20 > I have no specific opinon about the existence of the From header. > I would however like bring up my second question about the use of DQ > around URI's. >=20 > >3) In general. The idea to use DQ around URI's in some cases and in > some cases > > not may cause some headache for the implementor. > > Sure, one should read the ABNF but I would say that it would be more > > consistent to always use DQ around URI's in headers regardless if > they are needed or not. >=20 > Any comments ? I'm not an implementer (not in general but in the case of RTSP I'm not = ;), anyhow: checking the ABNF, it seems to be not straight forward when the RTSP-URI = is set in DQ and when not. I.e., it would be good to get this = streamlined.=20 However, let the implementers speak up. Martin >=20 > Regards > /Ingemar >=20 > > -----Original Message----- > > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > > Sent: den 2 februari 2009 11:52 > > To: ext Martin Stiemerling > > Cc: mmusic@ietf.org; Ingemar Johansson S > > Subject: Re: [MMUSIC] RTSP From header issue > > > > On Monday 02 February 2009 12:40:38 ext Martin Stiemerling, you > wrote: > > > A good question anyhow. I also did wonder about the from > > header while > > > editing the HTTP parts of the draft. > > > > > > I wouldn't removing it, as it does look a bit as legacy > > which isn't used. > > ^ > > mind? > > > > I definitely would remove it. It is not used. There are > > high-level reasons not to use it: privacy/spam. There is a > > low-level reasons not to use it: media player is typically > > not provisioned with email address. > > > > I would even advocate removing it from httpbis, if I were asked... > > > > -- > > R=E9mi Denis-Courmont > > Maemo Software, Nokia Devices R&D > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 From root@core3.amsl.com Mon Feb 9 05:30:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7C5C93A6A90; Mon, 9 Feb 2009 05:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090209133001.7C5C93A6A90@core3.amsl.com> Date: Mon, 9 Feb 2009 05:30:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-image-attributes-00.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, 09 Feb 2009 13:30:01 -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 : Negotiation of Generic Image Attributes in SDP Author(s) : I. Johansson, K. Jung Filename : draft-ietf-mmusic-image-attributes-00.txt Pages : 18 Date : 2009-02-06 This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a e.g a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-image-attributes-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-image-attributes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-09051840.I-D@ietf.org> --NextPart-- From ingemar.s.johansson@ericsson.com Mon Feb 9 09:08:29 2009 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 8D7303A6AB4 for ; Mon, 9 Feb 2009 09:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiZu2ebxQtsC for ; Mon, 9 Feb 2009 09:08:28 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A937C3A69B1 for ; Mon, 9 Feb 2009 09:08:28 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6FE1F20647; Mon, 9 Feb 2009 16:59:31 +0100 (CET) X-AuditID: c1b4fb3c-a827fbb00000127c-21-499052e3ca35 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 57553204C7; Mon, 9 Feb 2009 16:59:31 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 16:59:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2009 16:59:26 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C55E489@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mmusic-image-attributes-00 Thread-Index: AcmKz2IqA8N54BDhTcC0g/fTEbFTeQ== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 09 Feb 2009 15:59:31.0383 (UTC) FILETIME=[64FB6470:01C98ACF] X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] draft-ietf-mmusic-image-attributes-00 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, 09 Feb 2009 17:08:29 -0000 Hi A new version of the image attribute draft has been submitted (now a WG = draft) http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-image-attributes/ The main change is that the syntax has been changed to ABNF, moreover = most of the open issues from the individual -02 version has been sorted = out.=20 Abstract This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a e.g a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. Comments are welcome Regards Ingemar *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVP - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From ingemar.s.johansson@ericsson.com Tue Feb 10 23:17:43 2009 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 B53363A6934 for ; Tue, 10 Feb 2009 23:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s9DneuMWqX4 for ; Tue, 10 Feb 2009 23:17:42 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5139C3A68AD for ; Tue, 10 Feb 2009 23:17:42 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E418020EF8 for ; Wed, 11 Feb 2009 08:17:44 +0100 (CET) X-AuditID: c1b4fb3c-ada8abb00000127c-57-49927b9835a5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C9BC5207B5 for ; Wed, 11 Feb 2009 08:17:44 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 08:17:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2009 08:17:44 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C58CC50@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Setup of Asymmetric Media with SDP Thread-Index: AcmMGNUv5XhfD6rKRVmrn5lw5wNqaQ== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 11 Feb 2009 07:17:44.0729 (UTC) FILETIME=[D5969890:01C98C18] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S Subject: [MMUSIC] Setup of Asymmetric Media with 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, 11 Feb 2009 07:17:43 -0000 Hi A new draft that proposes an extension to the SDP Capability Negotiation = framework (SDPCapNeg) for the setup of asymmetric sessions has been = submitted http://tools.ietf.org/id/draft-johansson-mmusic-asymmetric-media-00.txt Abstract This draft proposes an extension to the SDP Capability Negotiation framework for the setup of asymmetric sessions. One example of an asymmetric session is a conversational video session between a handset with a small screen (high-resolution camera) and a home- entertainment set-top box connected to a wide-screen TV. Another example is tightly coupled conferences with different number of in and outgoing streams for each client. Comments are welcome Regards Ingemar *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVP - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From alex.giladi@gmail.com Wed Feb 11 10:52:15 2009 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 388E43A6D6B for ; Wed, 11 Feb 2009 10:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 msisM+qJUEOp for ; Wed, 11 Feb 2009 10:52:14 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 4EBB23A6D6A for ; Wed, 11 Feb 2009 10:52:14 -0800 (PST) Received: by ewy14 with SMTP id 14so286530ewy.13 for ; Wed, 11 Feb 2009 10:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ZCEwb5hftaQz1wWoqowbeit5gJVAqYEzSG60VCwpMkA=; b=ABb9k2paNrLr1yI3/v8GaPBUUUgVFbRPUlsQBMpwLxkWL1YGxM6B1RyRa5kEft9Abp TyDU36Sap5HG3L1Wo7J7aiKD9ShaqKV2zH356fu2ufLBkmpHv8KH53cszAQqN9+Kjut2 R1AZ9V6i7RNrQpAe2YtKojUvdo+1SzNr6ulL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=CR/S6lrOtNXmLu7JG9yTCmr/pLjw8GH05LbffTWB7Uw7Tq6WRwUdxav42/422OaF2w MsFkxP5GaF3jsEiQF3Xlh/QU5B2YHuiej5FdCe0cCTg5ZcD1IB4vPsyWZZYYPlN+o3z5 u2he6iNgu8rSe8ioWWWaKrmQjWkTpTXEfz8gU= MIME-Version: 1.0 Received: by 10.210.131.6 with SMTP id e6mr3725494ebd.77.1234378337108; Wed, 11 Feb 2009 10:52:17 -0800 (PST) Date: Wed, 11 Feb 2009 11:52:17 -0700 Message-ID: <57a9e15d0902111052j5afdc5b3xd1f359df0738ad12@mail.gmail.com> From: Alex Giladi To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Non-standard RTSP extensions 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, 11 Feb 2009 18:52:15 -0000 Hi As far as I know, there are several non-normative extensions to RTSP 1.0, used by some VOD vendors. Are there any specs on these? Thanks! Alex. From rem@videolan.org Wed Feb 11 11:00:14 2009 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 D23BB3A6D6A for ; Wed, 11 Feb 2009 11:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] 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 kbYSn6WaDjKc for ; Wed, 11 Feb 2009 11:00:13 -0800 (PST) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id A9A303A6A19 for ; Wed, 11 Feb 2009 11:00:13 -0800 (PST) Received: from basile.remlab.net (unknown [IPv6:2002:591b:3e27:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 81FCF394; Wed, 11 Feb 2009 20:00:15 +0100 (CET) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: VideoLAN project - www.videolan.org To: mmusic@ietf.org Date: Wed, 11 Feb 2009 21:00:12 +0200 User-Agent: KMail/1.9.9 References: <57a9e15d0902111052j5afdc5b3xd1f359df0738ad12@mail.gmail.com> In-Reply-To: <57a9e15d0902111052j5afdc5b3xd1f359df0738ad12@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902112100.12739.rem@videolan.org> Subject: Re: [MMUSIC] Non-standard RTSP extensions 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, 11 Feb 2009 19:00:14 -0000 Le mercredi 11 f=E9vrier 2009 20:52:17 Alex Giladi, vous avez =E9crit=A0: > As far as I know, there are several non-normative extensions to RTSP > 1.0, used by some VOD vendors. > Are there any specs on these? Not at IETF. IIRC, Microsoft has published "their" RTSP with the rest of th= eir=20 network protocol interoperability specifications. I don't know if 3GPP has= =20 defined any extensions but you should be able to check easily from their=20 website, but it is not a "vendor" anyway. I am not aware of any specs from Apple, Real and Amino. Other vendors that = I=20 know follow RFC2326 proper. =2D-=20 R=E9mi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummary From alex.giladi@gmail.com Wed Feb 11 11:03:27 2009 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 51F5E3A6D70 for ; Wed, 11 Feb 2009 11:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Ui607Df9Y1MB for ; Wed, 11 Feb 2009 11:03:26 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 626083A6A33 for ; Wed, 11 Feb 2009 11:03:26 -0800 (PST) Received: by ewy14 with SMTP id 14so290595ewy.13 for ; Wed, 11 Feb 2009 11:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hDcsJqxIrATjdu11PD0sgPjKnHRd7iv6uR30dRHx9NQ=; b=O1Dtu2gzlF3dmn2/Ok8jpEte1hMie7a6iNHOAdnBbqWJKzI5Gbks1QeZ9t7XJNknnJ 1ngfw8VkrjlVSVerWeXLJM7QO9K2MuqNWPR5kc0jzHMl1ohLMa214/O3JI+FE4vpPC2h az7iKPskqQ07xMCn8nYZZwPKeULsiEfdIqgnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bz6WpG7VcaVHqBmz15sEWN91QfdMEf82OSbB7knOmxXYztz9LSwBd9pGW0LnG0WAuy yZZ1hmYFs8tMIzP60b0UvpPAvng7RugQ+yvvgUmwBndcJmVCxOfDQbgVZVXY3hkKhxet sgtOpirl9moz3yrZJeP+k87WNxwJ3ES1OHKkc= MIME-Version: 1.0 Received: by 10.210.61.11 with SMTP id j11mr814017eba.119.1234379010019; Wed, 11 Feb 2009 11:03:30 -0800 (PST) In-Reply-To: <200902112100.12739.rem@videolan.org> References: <57a9e15d0902111052j5afdc5b3xd1f359df0738ad12@mail.gmail.com> <200902112100.12739.rem@videolan.org> Date: Wed, 11 Feb 2009 12:03:29 -0700 Message-ID: <57a9e15d0902111103m573ca25di9b475fe653db5242@mail.gmail.com> From: Alex Giladi To: =?UTF-8?Q?R=C3=A9mi_Denis=2DCourmont?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Non-standard RTSP extensions 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, 11 Feb 2009 19:03:27 -0000 Remi, Thanks a lot! Do you know if there anything specific to Kasenna / Seachange / nCube? Alex. On Wed, Feb 11, 2009 at 12:00 PM, R=C3=A9mi Denis-Courmont wrote: > Le mercredi 11 f=C3=A9vrier 2009 20:52:17 Alex Giladi, vous avez =C3=A9cr= it : >> As far as I know, there are several non-normative extensions to RTSP >> 1.0, used by some VOD vendors. >> Are there any specs on these? > > Not at IETF. IIRC, Microsoft has published "their" RTSP with the rest of = their > network protocol interoperability specifications. I don't know if 3GPP ha= s > defined any extensions but you should be able to check easily from their > website, but it is not a "vendor" anyway. > > I am not aware of any specs from Apple, Real and Amino. Other vendors tha= t I > know follow RFC2326 proper. > > -- > R=C3=A9mi Denis-Courmont > http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummar= y > From rem@videolan.org Wed Feb 11 11:04:53 2009 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 4068B3A6A63 for ; Wed, 11 Feb 2009 11:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 PnIZ4K6QQPg4 for ; Wed, 11 Feb 2009 11:04:52 -0800 (PST) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 872963A6929 for ; Wed, 11 Feb 2009 11:04:52 -0800 (PST) Received: from basile.remlab.net (unknown [IPv6:2002:591b:3e27:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id BCE54394; Wed, 11 Feb 2009 20:04:55 +0100 (CET) From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: VideoLAN project - www.videolan.org To: Alex Giladi Date: Wed, 11 Feb 2009 21:04:53 +0200 User-Agent: KMail/1.9.9 References: <57a9e15d0902111052j5afdc5b3xd1f359df0738ad12@mail.gmail.com> <200902112100.12739.rem@videolan.org> <57a9e15d0902111103m573ca25di9b475fe653db5242@mail.gmail.com> In-Reply-To: <57a9e15d0902111103m573ca25di9b475fe653db5242@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902112104.53298.rem@videolan.org> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Non-standard RTSP extensions 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, 11 Feb 2009 19:04:53 -0000 Le mercredi 11 f=C3=A9vrier 2009 21:03:29 Alex Giladi, vous avez =C3=A9crit= =C2=A0: > Do you know if there anything specific to Kasenna / Seachange / nCube? The answer to that question was in the original mail. No. =2D-=20 R=C3=A9mi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummary From joe.pallas@gmail.com Wed Feb 11 11:37:54 2009 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 E38CE3A6948 for ; Wed, 11 Feb 2009 11:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuWFQzNNenQM for ; Wed, 11 Feb 2009 11:37:54 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 42C433A6931 for ; Wed, 11 Feb 2009 11:37:54 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so199825wag.5 for ; Wed, 11 Feb 2009 11:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=0oIQAJAS2U36gK5sHYUMIWzN8jg4bdd1S+lpIJfV+m8=; b=DMyvg+blpiMYokdK6zY77YbkGqZpad9HI6OurZ2p3Bl+cSSB7yUNGo5NJxW7eX9GuQ fBo9saNIoVx43IAtD4rzWFAgnKZY6VH8U7C4LhWXJEQVNx4rHJUAZ5DxuvahuqV9iYMN V2KU05platTx7gcNFWcf2Uf8IFendnCSZeu1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ogdl+4b4eRE/+LmOnnNzL0AmYaX4cp/YhKqmj/bHJjqbb4fU/sq9qaVECS/LB8AQWc xUcImhOypm3399BSF28OvW8NFwrZ3x/YG3UEfiQg4Tc4zlloo85iU2vl5eZhJ8Kq2BsD 6QGV6KTo2hPR9DzLeJoFjPjzcbOs7lkZUJkPU= Received: by 10.114.137.2 with SMTP id k2mr5708931wad.146.1234381078338; Wed, 11 Feb 2009 11:37:58 -0800 (PST) Received: from dhcp-umpk14-99-59.SFBay.Sun.COM (sca-ea-fw-1.Sun.COM [192.18.43.225]) by mx.google.com with ESMTPS id z15sm15390286pod.0.2009.02.11.11.37.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 11:37:57 -0800 (PST) Sender: Joe Pallas Message-Id: From: Joe Pallas To: Alex Giladi In-Reply-To: <57a9e15d0902111103m573ca25di9b475fe653db5242@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 11:37:56 -0800 References: <57a9e15d0902111052j5afdc5b3xd1f359df0738ad12@mail.gmail.com> <200902112100.12739.rem@videolan.org> <57a9e15d0902111103m573ca25di9b475fe653db5242@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Non-standard RTSP extensions 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, 11 Feb 2009 19:37:55 -0000 On Feb 11, 2009, at 11:03 AM, Alex Giladi wrote: > Remi, > > Thanks a lot! > > Do you know if there anything specific to Kasenna / Seachange / nCube? > > Alex. Several VOD vendors implement a non-standard ANNOUNCE behavior that was described in a now-expired internet draft named draft-sheedy- mmusic-rtsp-ext-01. joe From Stiemerling@nw.neclab.eu Thu Feb 12 05:44:28 2009 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 5DB6E3A6AD9 for ; Thu, 12 Feb 2009 05:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18yFOWWyDpd4 for ; Thu, 12 Feb 2009 05:44:27 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 801453A67A2 for ; Thu, 12 Feb 2009 05:44:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id AB22C2C00030D for ; Thu, 12 Feb 2009 14:44:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFKwongTSKx5 for ; Thu, 12 Feb 2009 14:44:32 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 8BDA92C0000EB for ; Thu, 12 Feb 2009 14:44:27 +0100 (CET) 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: Thu, 12 Feb 2009 14:43:05 +0100 Message-ID: <547F018265F92642B577B986577D671C698654@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTSP: Server behaviour for 413 Request Entity Too Large Thread-Index: AcmNF9VHD+6bZzv2QmGnVPhhCKYj8Q== From: "Martin Stiemerling" To: Subject: [MMUSIC] RTSP: Server behaviour for 413 Request Entity Too Large 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: Thu, 12 Feb 2009 13:44:28 -0000 Hi all, I'm changing parts of the RTSP spec from the old notation of referencing = HTTP (like see [H.x.Y]) to include the text. The text is taken from the = HTTP spec (RFC 2616) and adapted to fit RTSP. Adapted, as the original = HTTP often says, e.g., "The PUT method", which is not applicable to = RTSP.=20 In this process, I have added a section describing the 413 error code = ("Request Entity Too Large ") and taken the text from RFC 2616. This = section says: *** The server is refusing to process a request because the request message = body is larger than the server is willing or able to process. The server = MAY close the connection to prevent the client from continuing the = request. If the condition is temporary, the server SHOULD include a Retry- After = header field to indicate that it is temporary and after what time the = client MAY try again. *** Now my question: Do you see it also appropriate for the RTSP server to = close the connection in this case? My opinion is yes, as there is no = other way of keeping the server from being overloaded. Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From jaehwan@vidiator.com Fri Feb 13 00:53:29 2009 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 BECFE3A6C23 for ; Fri, 13 Feb 2009 00:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxdGi6pRJ-dX for ; Fri, 13 Feb 2009 00:53:27 -0800 (PST) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id E96063A684A for ; Fri, 13 Feb 2009 00:53:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Feb 2009 17:51:53 +0900 Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C698654@VENUS.office> References: <547F018265F92642B577B986577D671C698654@VENUS.office> From: "Jaehwan Kim" To: "Martin Stiemerling" , Subject: Re: [MMUSIC] RTSP: Server behaviour for 413 Request Entity Too Large 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, 13 Feb 2009 08:53:29 -0000 Hi, IMO, typical case is what Martin mentioned. Just I guess the proposed text allows using Retry-After header as well. And the session would sustain if the request method does not change session state. It looks true in both persistent and non-persistent connection. Therefore, connection close might not be expected at all cases. i.e. the given sentence using "MAY" is no problem. I guess main usecase would be GET_PARAMETER or SET_PARAMETER but famous methods might be also able to send message body in a RTSP extension. And, Table 11 for Retry-After should be updated... Regards, Jaehwan -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Thursday, February 12, 2009 10:43 PM To: mmusic@ietf.org Subject: [MMUSIC] RTSP: Server behaviour for 413 Request Entity Too Large Hi all, I'm changing parts of the RTSP spec from the old notation of referencing HTTP (like see [H.x.Y]) to include the text. The text is taken from the HTTP spec (RFC 2616) and adapted to fit RTSP. Adapted, as the original HTTP often says, e.g., "The PUT method", which is not applicable to RTSP.=20 In this process, I have added a section describing the 413 error code ("Request Entity Too Large ") and taken the text from RFC 2616. This section says: *** The server is refusing to process a request because the request message body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. *** Now my question: Do you see it also appropriate for the RTSP server to close the connection in this case? My opinion is yes, as there is no other way of keeping the server from being overloaded. Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From Stiemerling@nw.neclab.eu Mon Feb 16 08:01:17 2009 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 1F74F3A6B73 for ; Mon, 16 Feb 2009 08:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SGT6n5IgebW for ; Mon, 16 Feb 2009 08:01:16 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 53F583A6C03 for ; Mon, 16 Feb 2009 08:01:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 20B252C017B31 for ; Mon, 16 Feb 2009 17:01:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz5KT8v97QBU for ; Mon, 16 Feb 2009 17:01:26 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 03FEA2C0004DA for ; Mon, 16 Feb 2009 17:01:21 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Feb 2009 17:00:27 +0100 Message-ID: <547F018265F92642B577B986577D671C698967@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTSP 2.0 meeting during upcoming IETF#74? Thread-Index: AcmQFcs9Ep9PN48mTNG2V5z/J5uPpQ== From: "Martin Stiemerling" To: Subject: [MMUSIC] RTSP 2.0 meeting during upcoming IETF#74? 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, 16 Feb 2009 16:01:17 -0000 Hi all, Magnus and me are working on a new version the RTSP 2.0 draft. However, there will be still open issues left (for sure ;) and I propose to have a meeting about RTSP 2.0 sometimes during the IETF#74 week. This meeting is additionally to the MMUSIC session.=20 This meeting should give the chance to discuss the remaining open issues and to get solutions to them nailed down.=20 Any opinions on that? Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From root@core3.amsl.com Tue Feb 17 06:00:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DDA293A6A60; Tue, 17 Feb 2009 06:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090217140001.DDA293A6A60@core3.amsl.com> Date: Tue, 17 Feb 2009 06:00:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-file-transfer-mech-11.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: Tue, 17 Feb 2009 14:00:02 -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 : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Author(s) : M. Garcia, et al. Filename : draft-ietf-mmusic-file-transfer-mech-11.txt Pages : 49 Date : 2009-02-17 This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-11.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-file-transfer-mech-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-17054819.I-D@ietf.org> --NextPart-- From miguel.a.garcia@ericsson.com Tue Feb 17 06:41:32 2009 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 AB3DC3A6A01 for ; Tue, 17 Feb 2009 06:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPvAQWv2gsLF for ; Tue, 17 Feb 2009 06:41:31 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4840C3A67EA for ; Tue, 17 Feb 2009 06:41:31 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 483C6211A8 for ; Tue, 17 Feb 2009 15:41:41 +0100 (CET) X-AuditID: c1b4fb3e-ae8c0bb000001315-aa-499acca53eb4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1FB0B2052F for ; Tue, 17 Feb 2009 15:41:41 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 15:41:40 +0100 Received: from [159.107.25.97] ([159.107.25.97]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 15:41:40 +0100 Message-ID: <499ACCA4.4030409@ericsson.com> Date: Tue, 17 Feb 2009 15:41:40 +0100 From: "Miguel A. Garcia" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmusic Content-Type: multipart/mixed; boundary="------------010400070802090400090304" X-OriginalArrivalTime: 17 Feb 2009 14:41:40.0517 (UTC) FILETIME=[D83BCD50:01C9910D] X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] [Fwd: New Version Notification for draft-ietf-mmusic-file-transfer-mech-11] 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, 17 Feb 2009 14:41:32 -0000 This is a multi-part message in MIME format. --------------010400070802090400090304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit We have just submitted a new version of the file transfer draft. This is to address a comment we got during the IESG review, related to the ABNF of "parameter", which allows free insertion of linear-white-space (including comments and line folding). This has never been the intention of the draft. The solution was to disallow linear-white-space by comment: filetype-selector = "type:" type "/" subtype *(";" ft-parameter) ft-parameter = attribute "=" DQUOTE value-string DQUOTE ; attribute is defined in RFC 2045 ; free insertion of linear-white-space is not ; permitted in this context. ; note: value-string has to be re-encoded ; when translating between this and a ; Content-Type header. value-string = filename-string We expect that this version will solve the issue and clears the IESG. /Miguel Miguel A. Garcia +34-91-339-3608 Ericsson Spain --------------010400070802090400090304 Content-Type: message/rfc822; name="New Version Notification for draft-ietf-mmusic-file-transfer-mech-11.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-ietf-mmusic-file"; filename*1="-transfer-mech-11.eml" Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw121.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 14:48:32 +0100 Received: from mailgw7.ericsson.se ([193.180.251.48]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 14:48:32 +0100 Received: from mailgw7.ericsson.se (unknown [127.0.0.1]) by mailgw7.ericsson.se (Symantec Mail Security) with ESMTP id 4CAF258C002; Tue, 17 Feb 2009 14:48:32 +0100 (CET) X-AuditID: c1b4fb30-a80e4bb000001d50-7e-499ac02f164b Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mailgw7.ericsson.se (Symantec Mail Security) with ESMTP id F317050000B; Tue, 17 Feb 2009 14:48:31 +0100 (CET) Received: by core3.amsl.com (Postfix, from userid 30) id D9C873A68B5; Tue, 17 Feb 2009 05:48:19 -0800 (PST) From: IETF I-D Submission Tool To: miguel.a.garcia@ericsson.com Cc: markus.isomaki@nokia.com,Gonzalo.Camarillo@ericsson.com,Salvatore.Loreto@ericsson.com,pkyzivat@cisco.com Subject: New Version Notification for draft-ietf-mmusic-file-transfer-mech-11 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090217134819.D9C873A68B5@core3.amsl.com> Date: Tue, 17 Feb 2009 05:48:19 -0800 (PST) X-Brightmail-Tracker: AAAAAQ2TYs4= Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 17 Feb 2009 13:48:32.0132 (UTC) FILETIME=[6BCEDC40:01C99106] A new version of I-D, draft-ietf-mmusic-file-transfer-mech-11.txt has been successfuly submitted by Miguel Garcia and posted to the IETF repository. Filename: draft-ietf-mmusic-file-transfer-mech Revision: 11 Title: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Creation_date: 2009-02-17 WG ID: mmusic Number_of_pages: 49 Abstract: This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. The IETF Secretariat. --------------010400070802090400090304-- From Stiemerling@nw.neclab.eu Wed Feb 18 06:33:32 2009 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 4D9773A6A71 for ; Wed, 18 Feb 2009 06:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNuqeoXWIvCj for ; Wed, 18 Feb 2009 06:33:31 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0A9DF3A6C66 for ; Wed, 18 Feb 2009 06:33:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C28482C0004DA for ; Wed, 18 Feb 2009 15:33:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLULRnUMsN01 for ; Wed, 18 Feb 2009 15:33:42 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id A42D52C00030D for ; Wed, 18 Feb 2009 15:33:37 +0100 (CET) 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, 18 Feb 2009 15:33:29 +0100 Message-ID: <547F018265F92642B577B986577D671C698C14@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C698654@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP: Server behaviour for 413 Request Entity Too Large Thread-Index: AcmNF9VHD+6bZzv2QmGnVPhhCKYj8QEu+wJA References: <547F018265F92642B577B986577D671C698654@VENUS.office> From: "Martin Stiemerling" To: Subject: Re: [MMUSIC] RTSP: Server behaviour for 413 Request Entity Too Large 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, 18 Feb 2009 14:33:32 -0000 Ok, took out my editor's note on this and also added 413 to the tables = 10 & 12, where Retry-After is listed as extra row. Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Martin Stiemerling > Sent: Thursday, February 12, 2009 2:43 PM > To: mmusic@ietf.org > Subject: [MMUSIC] RTSP: Server behaviour for 413 Request Entity Too > Large >=20 > Hi all, >=20 > I'm changing parts of the RTSP spec from the old notation of > referencing HTTP (like see [H.x.Y]) to include the text. The text is > taken from the HTTP spec (RFC 2616) and adapted to fit RTSP. Adapted, > as the original HTTP often says, e.g., "The PUT method", which is not > applicable to RTSP. >=20 > In this process, I have added a section describing the 413 error code > ("Request Entity Too Large ") and taken the text from RFC 2616. This > section says: >=20 > *** > The server is refusing to process a request because the request = message > body is larger than the server is willing or able to process. The > server MAY close the connection to prevent the client from continuing > the request. >=20 > If the condition is temporary, the server SHOULD include a Retry- = After > header field to indicate that it is temporary and after what time the > client MAY try again. > *** >=20 >=20 > Now my question: Do you see it also appropriate for the RTSP server to > close the connection in this case? My opinion is yes, as there is no > other way of keeping the server from being overloaded. >=20 >=20 > Martin >=20 > stiemerling@nw.neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From olivier.crete@collabora.co.uk Thu Feb 19 12:09:49 2009 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 AC09D28C105 for ; Thu, 19 Feb 2009 12:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=1.854, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 CZ41fSNKz+J7 for ; Thu, 19 Feb 2009 12:09:48 -0800 (PST) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [195.10.223.82]) by core3.amsl.com (Postfix) with ESMTP id 6B33B28C11A for ; Thu, 19 Feb 2009 12:09:48 -0800 (PST) Received: from [192.168.1.105] (MTLXPQAK-1176055545.sdsl.bell.ca [70.25.46.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bhuna.collabora.co.uk (Postfix) with ESMTP id 6B41A1889 for ; Thu, 19 Feb 2009 20:10:00 +0000 (GMT) From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: nobody Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZuLV3GV0bwoCLCJqtkEz" Organization: Collabora Date: Thu, 19 Feb 2009 15:09:58 -0500 Message-Id: <1235074198.30960.5.camel@TesterTop3.tester.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [MMUSIC] How to produce the m= for the re-offer with ICE? 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: Thu, 19 Feb 2009 20:09:49 -0000 --=-ZuLV3GV0bwoCLCJqtkEz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, We're implementing ICE in libnice[1] and we have a problem finding what candidates are we receiving data on, so that we can put the right thing in the m=3D line in the offer that contains a=3Dremote-candidates. Since they're all sending to the same port, we have no way of knowing. Looking at other implementations, it seems that Microsoft added an extra attribute to their STUN packets with the foundation of the candidates it sent to, so they can find which one is the right one. [1] http://nice.freedesktop.org/ --=20 Olivier Cr=C3=AAte olivier.crete@collabora.co.uk Collabora Ltd --=-ZuLV3GV0bwoCLCJqtkEz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkmdvJYACgkQHTiOWk7Zorsy8gCfUKTAW/Rp6l0Q3wRTMniiPOOI 95AAnis29skwTTrLopvEIcuKHp25vsaI =qzwW -----END PGP SIGNATURE----- --=-ZuLV3GV0bwoCLCJqtkEz-- From olivier.crete@collabora.co.uk Thu Feb 19 12:16:06 2009 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 E10C028C127 for ; Thu, 19 Feb 2009 12:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 vDa4Ia+SGlAW for ; Thu, 19 Feb 2009 12:16:06 -0800 (PST) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [195.10.223.82]) by core3.amsl.com (Postfix) with ESMTP id 2E2EA28C10B for ; Thu, 19 Feb 2009 12:16:06 -0800 (PST) Received: from [192.168.1.105] (MTLXPQAK-1176055545.sdsl.bell.ca [70.25.46.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bhuna.collabora.co.uk (Postfix) with ESMTP id 8FD901889 for ; Thu, 19 Feb 2009 20:16:18 +0000 (GMT) From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: mmusic Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p7mQwF6T6ZTReV3rV909" Organization: Collabora Date: Thu, 19 Feb 2009 15:16:16 -0500 Message-Id: <1235074576.30960.12.camel@TesterTop3.tester.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [MMUSIC] Connectivity checks during call and re-connection 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: Thu, 19 Feb 2009 20:16:07 -0000 --=-p7mQwF6T6ZTReV3rV909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Google's libjingle ICE-like implementation does connectivity checks as keepalives. This allows it to find out if the other end is no longer "there" and try to reconnect, possibly through a different path. In draft 19, I see that we're supposed to answer any connectivity-check, so it should be possible to implement the same behavior. But I don't see any mecanism to re-start the negotiation. Should one do a complete ICE restart ? --=20 Olivier Cr=C3=AAte olivier.crete@collabora.co.uk Collabora Ltd --=-p7mQwF6T6ZTReV3rV909 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkmdvhAACgkQHTiOWk7ZoruTyACeMQ5dx1+PpWArn6A7vmc+0bNm suEAnA4Xh/+pHOiaAbDDJQtLx32rOMSZ =5jXT -----END PGP SIGNATURE----- --=-p7mQwF6T6ZTReV3rV909-- From gonzalo.camarillo@ericsson.com Thu Feb 19 12:57:12 2009 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 4510628C15E for ; Thu, 19 Feb 2009 12:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYZ3S0MI-eJM for ; Thu, 19 Feb 2009 12:57:11 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 24E0428C0FC for ; Thu, 19 Feb 2009 12:57:11 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2AE1D211A6; Thu, 19 Feb 2009 21:57:22 +0100 (CET) X-AuditID: c1b4fb3e-af8c2bb000001315-b4-499dc7b1d22e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EF85021184; Thu, 19 Feb 2009 21:57:21 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 21:57:22 +0100 Received: from [164.48.166.70] ([164.48.166.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 21:57:21 +0100 Message-ID: <499DC7B1.5030002@ericsson.com> Date: Thu, 19 Feb 2009 22:57:21 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jean-Francois Mule , Joerg Ott References: <9AAEDF491EF7CA48AB587781B8F5D7C60150BB53@srvxchg3.cablelabs.com> <49461C9D.6000508@ericsson.com> In-Reply-To: <49461C9D.6000508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2009 20:57:21.0879 (UTC) FILETIME=[A8C22E70:01C992D4] X-Brightmail-Tracker: AAAAAA== Cc: fandreas@cisco.com, oran@cisco.com, mmusic@ietf.org, dwing@cisco.com Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-connectivity-precon-05.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: Thu, 19 Feb 2009 20:57:12 -0000 Jean Francois, Joerg, when do you think you will get around to requesting the publication of the draft below? Thanks, Gonzalo -------- Original Message -------- Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-connectivity-precon-05.txt Date: Mon, 15 Dec 2008 11:00:13 +0200 From: Gonzalo Camarillo To: Jean-Francois Mule CC: fandreas@cisco.com, dwing@cisco.com, oran@cisco.com, mmusic@ietf.org, Joerg Ott Hi Jean Francois, we have not received any further comments on the draft. So, you can go ahead request its publication as soon as you get some time to the PROTO writeup. Thanks, Gonzalo -------- Original Message -------- Subject: WGLC: draft-ietf-mmusic-connectivity-precon-05.txt Date: Fri, 24 Oct 2008 05:49:37 -0600 From: Jean-Francois Mule To: CC: Joerg Ott , Gonzalo Camarillo , , , This is to announce the Working Group Last Call on draft-ietf-mmusic-connectivity-precon-05. The WGLC starts today and will end on November 7 2008. Please send your comments and any open issues to the MMUSIC list and the authors. Thank you in advance for taking the time to read this document and provide your review comments. Jean-Francois. jfm@cablelabs.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From Remi.Denis-Courmont@nokia.com Thu Feb 19 23:44:29 2009 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 0AA4B3A697B for ; Thu, 19 Feb 2009 23:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 6qI6VcU5K5qf for ; Thu, 19 Feb 2009 23:44:28 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 20BEA3A694F for ; Thu, 19 Feb 2009 23:44:28 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1K7icc9027330 for ; Fri, 20 Feb 2009 01:44:40 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 09:44:32 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 09:44:31 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n1K7iUbv022878 for ; Fri, 20 Feb 2009 09:44:30 +0200 From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: mmusic@ietf.org Date: Fri, 20 Feb 2009 09:44:40 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.27.15; KDE/4.1.4; i686; ; ) References: <1235074198.30960.5.camel@TesterTop3.tester.ca> In-Reply-To: <1235074198.30960.5.camel@TesterTop3.tester.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902200944.41208.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Feb 2009 07:44:31.0769 (UTC) FILETIME=[112D3090:01C9932F] X-Nokia-AV: Clean Subject: Re: [MMUSIC] How to produce the m= for the re-offer with ICE? 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, 20 Feb 2009 07:44:29 -0000 On Thursday 19 February 2009 22:09:58 ext Olivier Cr=EAte, you wrote: > We're implementing ICE in libnice[1] and we have a problem finding what > candidates are we receiving data on, so that we can put the right thing > in the m=3D line in the offer that contains a=3Dremote-candidates. Since > they're all sending to the same port, we have no way of knowing. The peer includes your address/port in the STUN Binding Response XOR-MAPPED- ADDRESS attribute. From that you can infer what your re-offer m=3D line sho= uld=20 be. =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From root@core3.amsl.com Fri Feb 20 16:15:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C864F28C18A; Fri, 20 Feb 2009 16:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090221001501.C864F28C18A@core3.amsl.com> Date: Fri, 20 Feb 2009 16:15:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-10.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: Sat, 21 Feb 2009 00:15:01 -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 : An Extension to the Session Description Protocol (SDP) for Media Loopback Author(s) : K. Hedayat Filename : draft-ietf-mmusic-media-loopback-10.txt Pages : 33 Date : 2009-2-18 The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-10.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-media-loopback-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-2-20160443.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Feb 23 03:30:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B87A53A681C; Mon, 23 Feb 2009 03:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090223113001.B87A53A681C@core3.amsl.com> Date: Mon, 23 Feb 2009 03:30:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-decoding-dependency-06.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, 23 Feb 2009 11:30:01 -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 : Signaling media decoding dependency in Session Description Protocol (SDP) Author(s) : T. Schierl, S. Wenger Filename : draft-ietf-mmusic-decoding-dependency-06.txt Pages : 17 Date : 2009-02-23 This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-decoding-dependency-06.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-decoding-dependency-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-23032053.I-D@ietf.org> --NextPart-- From gao.yang2@zte.com.cn Mon Feb 23 23:53:45 2009 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 67D3A3A6991; Mon, 23 Feb 2009 23:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.47 X-Spam-Level: X-Spam-Status: No, score=-94.47 tagged_above=-999 required=5 tests=[AWL=3.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_84=0.6, RCVD_DOUBLE_IP_SPAM=3.798, 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 thdkGKjf6fPk; Mon, 23 Feb 2009 23:53:44 -0800 (PST) Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id B0DFE3A688D; Mon, 23 Feb 2009 23:53:39 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 33096.1456474892; Tue, 24 Feb 2009 16:13:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n1O7rKQM000497; Tue, 24 Feb 2009 15:53:21 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) From: gao.yang2@zte.com.cn To: mmusic@ietf.org, SIPPING MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Tue, 24 Feb 2009 15:53:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-02-24 15:53:12, Serialize complete at 2009-02-24 15:53:12 Content-Type: multipart/alternative; boundary="=_alternative 002B51F648257567_=" X-MAIL: mse1.zte.com.cn n1O7rKQM000497 Subject: [MMUSIC] Discuss: Session continuity in RFC3264 need further definition 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, 24 Feb 2009 07:53:45 -0000 This is a multipart message in MIME format. --=_alternative 002B51F648257567_= Content-Type: text/plain; charset="US-ASCII" RFC3264 defined many for offerer's and answerer's behavior while during the modifcation of session parameters. The main aim is session continuity, or say that avoiding media clip during modificaion. But I find that it is not complete, and something is not precision enough. 1. When should offerer using new parameters? RFC3264 repeated many times of recv in two(the new and old one) parameters(address, port and so on). But when should the offerer using the new media type is beyond definition. In point of view, it should be until the offerer find the answer using the new type( in signal level by answer or in media level by media content). But it is not complete: o offer can be rejected. Using new parameters radically can bring about media clip. o modification can be emergent, such as domain handover. Delay of using new parameters can also bring about media clip. In fact: o if the offer can be rejected, using new parameters as late as possible. o if the offer should not be rejected(such as domain handover), using new parameters as soon as possible. So, in point of view, as we can distinguish the part of the modification, we'd better extend one guidance in SDP. 2. With precondition, something can not not precision enough. Without precondition, offerer can conclude that answerer accept the modifition with the answer.(It is not definitive precision, but practical). But with precondition, some Offer/Answer pairs and the state of precondition satisfied should be before user's confirmation. So, when should the two side using new parameters? o Just after the state of precondition satisfied. It may be the radical way, because precondition satisfied and user's confirmation are two differnt things. The answerer can discard all the media with new parameters before user's confirmation, and this would bring about media clip. o Until 200OK of Re-INVITE can be more reasonable here. But without clear definition, it can bring about media clip too. So, in point of view, this need further definition. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002B51F648257567_= Content-Type: text/html; charset="US-ASCII"
RFC3264 defined many for offerer's and answerer's behavior while during the modifcation of session parameters. The main aim is session continuity, or say that avoiding media clip during modificaion.

But I find that it is not complete, and something is not precision enough.

1. When should offerer using new parameters?
RFC3264 repeated many times of recv in two(the new and old one) parameters(address, port and so on). But when should the offerer using the new media type is beyond definition.
In point of view, it should be until the offerer find the answer using the new type( in signal level by answer or in media level by media content). But it is not complete:

o offer can be rejected. Using new parameters radically can bring about media clip.

o modification can be emergent, such as domain handover. Delay of using new parameters can also bring about media clip.

In fact:
o if the offer can be rejected, using new parameters as late as possible.

o if the offer should not be rejected(such as domain handover), using new parameters as soon as possible.

So, in point of view, as we can distinguish the part of the modification, we'd better extend one guidance in SDP.


2. With precondition, something can not not precision enough.
Without precondition, offerer can conclude that answerer accept the modifition with the answer.(It is not definitive precision, but practical).
But with precondition, some Offer/Answer pairs and the state of precondition satisfied should be before user's confirmation. So, when should the two side using new parameters?

o Just after the state of precondition satisfied. It may be the radical way, because precondition satisfied and user's confirmation are two differnt things. The answerer can discard all the media with new parameters before user's confirmation, and this would bring about media clip.

o Until 200OK of Re-INVITE can be more reasonable here. But without clear definition, it can bring about media clip too.

So, in point of view, this need further definition. 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002B51F648257567_=-- From ingemar.s.johansson@ericsson.com Tue Feb 24 02:57:13 2009 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 6A2CA3A6AFE for ; Tue, 24 Feb 2009 02:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 mvZLRAFGmGZc for ; Tue, 24 Feb 2009 02:57:12 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 352E13A6AFD for ; Tue, 24 Feb 2009 02:57:12 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1E36722CCA for ; Tue, 24 Feb 2009 11:57:29 +0100 (CET) X-AuditID: c1b4fb3c-a8a80bb00000127c-c3-49a3c8dfe63a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DD98C22D4A for ; Tue, 24 Feb 2009 11:15:59 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 11:15:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 11:15:22 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mmusic-sdp-media-capabilities-06 Thread-Index: AcmWaM0/k/UsYRocRcabyO19fr9R9g== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 24 Feb 2009 10:15:59.0438 (UTC) FILETIME=[E3806EE0:01C99668] X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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, 24 Feb 2009 10:57:13 -0000 Hi I have read through the last version of the SDP media Capabilities = negitiation draft.=20 Some comments below.=20 That said...., it pains me to see that the interest in this is soooo = low.=20 I believe that the authors would welcome more response to make this = become an RFC, it would be really sad if this work eventually shares the = same fate as SDPng just because the rest of the world did not see the = immediate benefit. You may not see the killer use cases today, perhaps there are no killer = use cases around but I have a strong feeling that the strengths of = SDPCapNeg and its extensions will show up when whe start to look at = capability exchange and negotiation of "richer media". Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D I believe the draft is in a good shape.=20 Possibly I wonder if it is not a better idea after all to move the = a=3Dbcap (bandwidth capability) back to this draft ?, this because I = beleieve bandwidth capabilities is strongly related to this draft = anyway. 1) Section 3.3.4.1 :=20 I believe the ABNF is correct, however I believe that the line m=3D["+"] *["|"] should read ["+"]m=3D *["|"] ? 2) Section 3.3.4.2 :=20 I believe 1*WSP should be removed ? 3) Section 3.3.5 : [Editors note: it could simplify processing if all capabilities referenced by latent or potential configurations became media-level attributes/capabilities when transformed into media configurations. Are there examples where session-level attributes must be negotiated at the media level? Perhaps we need some sort of "session configuration" or "scfg=3D" to handle the session-level fields. Perhaps that could be somehow added to the sescap attribute defined below.] Personally I don't see the use case. 4) Section 3.3.8 [Editors' note: We have considered a form of the lcfg: attribute that would permit an offerer to indicate that the configuration is available for immediate acceptance via an answer with a corresponding (new) m-line in the answer. This would permit the establishment of the media streams to take place in one SDP exchange; at the same time, non-negotiating endpoints could be offered a simple configuration as in the above example. Ultimately, when all endpoints understand the current specification, this would permit an offer with latent configurations only, and an answer with the m-lines for the accepted media streams.] I would believe that this could be specified in a future version,=20 possibly with a new option tag especially as the (new) m-line thing = can cause some havoc elsewhere. /Ingemar *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVP - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From dwing@cisco.com Tue Feb 24 12:25:14 2009 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 8E31C3A66B4 for ; Tue, 24 Feb 2009 12:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=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 EfMFmC1gL6fE for ; Tue, 24 Feb 2009 12:25:11 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7179E3A6403 for ; Tue, 24 Feb 2009 12:25:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,260,1233532800"; d="scan'208";a="146799600" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2009 20:25:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1OKPU8N019027; Tue, 24 Feb 2009 12:25:30 -0800 Received: from dwingwxp01 ([128.107.103.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1OKPUQ1015108; Tue, 24 Feb 2009 20:25:30 GMT From: "Dan Wing" To: "'Ingemar Johansson S'" , References: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> Date: Tue, 24 Feb 2009 12:25:31 -0800 Message-ID: <00e001c996be$0a2158c0$37a36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> Thread-Index: AcmWaM0/k/UsYRocRcabyO19fr9R9gAVIrlQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4642; t=1235507130; x=1236371130; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Comments=20on=20draft-ietf-m music-sdp-media-capabilities-06 |Sender:=20; bh=ScKJ+l/EXAI+IORunCz2uYk9YyB0HQsnAD3YehCydLs=; b=pyYj63X2jgsxTVtWG4iRmAa7A6NF+ued9BjyK4pN03Dq4pyR7rNebQIXXH 99tf4XQU1gEevaM3xUtQjq+83FtVoCjWqSubrbk4GIp4ZyWFh+3tB14oy0mH HHcDujY3PA; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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, 24 Feb 2009 20:25:14 -0000 =20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Ingemar Johansson S > Sent: Tuesday, February 24, 2009 2:15 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Comments on=20 > draft-ietf-mmusic-sdp-media-capabilities-06 >=20 > Hi >=20 > I have read through the last version of the SDP media=20 > Capabilities negitiation draft.=20 > Some comments below.=20 >=20 > That said...., it pains me to see that the interest in this=20 > is soooo low.=20 > I believe that the authors would welcome more response to=20 > make this become an RFC, it would be really sad if this work=20 > eventually shares the same fate as SDPng just because the=20 > rest of the world did not see the immediate benefit. > You may not see the killer use cases today, perhaps there are=20 > no killer use cases around but I have a strong feeling that=20 > the strengths of SDPCapNeg and its extensions will show up=20 > when whe start to look at capability exchange and negotiation=20 > of "richer media". I strongly support draft-ietf-mmusic-sdp-media-capabilities. It is necessary to allow negotiating AVP versus AVPF versus SAVP=20 versus SAVPF (and whatever is defined later), and as you say will help complex combinations of audio and video media -- which we are all anxious to deploy and use. Unlike SDPng, SDP Capabilities Negotiation is backwards=20 compatible with plain SDP. To deploy SDPng, every SIP=20 element (UA, B2BUA, SBC, proxy) on the path had to handle multipart MIME, but supporting multipart MIME wasn't required=20 in RFC3261. Hence, SDPng could never see deployment for years and years after multipart MIME was declared mandatory. SDP Capabilities Negotiation does not suffer from SDPng's flaw. SDP Capabilities Negotiation should be advanced. -d > Regards > Ingemar >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > I believe the draft is in a good shape.=20 > Possibly I wonder if it is not a better idea after all to=20 > move the a=3Dbcap (bandwidth capability) back to this draft ?,=20 > this because I beleieve bandwidth capabilities is strongly=20 > related to this draft anyway. >=20 > 1) Section 3.3.4.1 :=20 > I believe the ABNF is correct, however I believe that the line > m=3D["+"] *["|"] > should read > ["+"]m=3D *["|"] ? > 2) Section 3.3.4.2 :=20 > I believe 1*WSP should be removed ? >=20 > 3) Section 3.3.5 : > [Editors note: it could simplify processing if > all capabilities referenced by latent or potential configurations > became media-level attributes/capabilities when transformed into > media configurations. Are there examples where session-level > attributes must be negotiated at the media level? Perhaps we need > some sort of "session configuration" or "scfg=3D" to handle the > session-level fields. Perhaps that could be somehow added to the > sescap attribute defined below.] > Personally I don't see the use case. >=20 > 4) Section 3.3.8 > [Editors' note: We have considered a form of the lcfg:=20 > attribute that > would permit an offerer to indicate that the configuration is > available for immediate acceptance via an answer with a=20 > corresponding > (new) m-line in the answer. This would permit the establishment of > the media streams to take place in one SDP exchange; at the same > time, non-negotiating endpoints could be offered a simple > configuration as in the above example. Ultimately, when all > endpoints understand the current specification, this would=20 > permit an > offer with latent configurations only, and an answer with=20 > the m-lines > for the accepted media streams.] > I would believe that this could be specified in a future version,=20 > possibly with a new option tag especially as the (new)=20 > m-line thing can cause some havoc elsewhere. >=20 > /Ingemar > *******************************************=20 > Ingemar Johansson=20 > Senior Research Engineer, IETF "nethead"=20 > EAB/TVP - Multimedia Technologies=20 > Ericsson Research Ericsson AB=20 > Box 920 S-971 28 Lule=E5, Sweden=20 > Tel: +46 (0)10 7143042=20 > ECN: 852-43042=20 > ECC: 852-19042 > Mobile: +46 (0)730 783289=20 > Visit http://labs.ericsson.com ! > *******************************************=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bob_gilman@comcast.net Tue Feb 24 13:32:36 2009 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 6ADB93A69A6 for ; Tue, 24 Feb 2009 13:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNpIJbLk+5Pm for ; Tue, 24 Feb 2009 13:32:35 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 32FC03A66B4 for ; Tue, 24 Feb 2009 13:32:35 -0800 (PST) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id KwwM1b01K0vp7WLA7xYvkx; Tue, 24 Feb 2009 21:32:55 +0000 Received: from [192.168.1.101] ([67.176.84.91]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id KxYu1b0091yDsSj8RxYuia; Tue, 24 Feb 2009 21:32:55 +0000 Message-ID: <49A4678D.2070503@comcast.net> Date: Tue, 24 Feb 2009 14:33:01 -0700 From: Bob Gilman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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, 24 Feb 2009 21:32:36 -0000 Ingemar- Thanks for looking at this draft. My responses below. -Bob Ingemar Johansson S wrote: > Hi > > I have read through the last version of the SDP media Capabilities negitiation draft. > Some comments below. > > That said...., it pains me to see that the interest in this is soooo low. > I believe that the authors would welcome more response to make this become an RFC, it would be really sad if this work eventually shares the same fate as SDPng just because the rest of the world did not see the immediate benefit. > You may not see the killer use cases today, perhaps there are no killer use cases around but I have a strong feeling that the strengths of SDPCapNeg and its extensions will show up when whe start to look at capability exchange and negotiation of "richer media". > > Regards > Ingemar > > ============================== > I believe the draft is in a good shape. > Possibly I wonder if it is not a better idea after all to move the a=bcap (bandwidth > capability) back to this draft ?, this because I beleieve bandwidth capabilities is > strongly related to this draft anyway. > > 1) Section 3.3.4.1 : > I believe the ABNF is correct, however I believe that the line > m=["+"] *["|"] > should read > ["+"]m= *["|"] ? [rrg]: You're correct. > 2) Section 3.3.4.2 : > I believe 1*WSP should be removed ? [rrg]: Do you mean section 3.3.4.3? If so, you're correct. > > 3) Section 3.3.5 : > [Editors note: it could simplify processing if > all capabilities referenced by latent or potential configurations > became media-level attributes/capabilities when transformed into > media configurations. Are there examples where session-level > attributes must be negotiated at the media level? Perhaps we need > some sort of "session configuration" or "scfg=" to handle the > session-level fields. Perhaps that could be somehow added to the > sescap attribute defined below.] > Personally I don't see the use case. [rrg]: Are you saying it would be OK to restrict capabilities referenced by potential or latent configurations to media level only? > > 4) Section 3.3.8 > [Editors' note: We have considered a form of the lcfg: attribute that > would permit an offerer to indicate that the configuration is > available for immediate acceptance via an answer with a corresponding > (new) m-line in the answer. This would permit the establishment of > the media streams to take place in one SDP exchange; at the same > time, non-negotiating endpoints could be offered a simple > configuration as in the above example. Ultimately, when all > endpoints understand the current specification, this would permit an > offer with latent configurations only, and an answer with the m-lines > for the accepted media streams.] > I would believe that this could be specified in a future version, > possibly with a new option tag especially as the (new) m-line thing > can cause some havoc elsewhere. [rrg]: I have no problem with deferring such work until such time as capability negotiation is ubiquitous. > > /Ingemar > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Luleå, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > ------------------------------------------------------------- Bob Gilman bob_gilman@comcast.net +1 303 898 9780 From christer.holmberg@ericsson.com Tue Feb 24 14:11:17 2009 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 12EC93A6A11 for ; Tue, 24 Feb 2009 14:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.325 X-Spam-Level: X-Spam-Status: No, score=-5.325 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 S7M-L0q3NKbO for ; Tue, 24 Feb 2009 14:11:16 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A94243A6862 for ; Tue, 24 Feb 2009 14:11:15 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A96BB2073C; Tue, 24 Feb 2009 23:08:56 +0100 (CET) X-AuditID: c1b4fb3c-a8a80bb00000127c-29-49a46ff83014 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8254D20715; Tue, 24 Feb 2009 23:08:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 23:08:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 23:08:55 +0100 Message-ID: In-Reply-To: <00e001c996be$0a2158c0$37a36b80@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 thread-index: AcmWaM0/k/UsYRocRcabyO19fr9R9gAVIrlQAAOrRNA= References: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> <00e001c996be$0a2158c0$37a36b80@cisco.com> From: "Christer Holmberg" To: "Dan Wing" , "Ingemar Johansson S" , X-OriginalArrivalTime: 24 Feb 2009 22:08:56.0729 (UTC) FILETIME=[7CC10890:01C996CC] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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, 24 Feb 2009 22:11:17 -0000 Hi,=20 >I strongly support draft-ietf-mmusic-sdp-media-capabilities. It is = necessary to allow negotiating AVP versus AVPF versus SAVP versus SAVPF = (and whatever is defined later), and as you say will help=20 >complex combinations of audio and video media -- which we are all = anxious to deploy and use. > >Unlike SDPng, SDP Capabilities Negotiation is backwards compatible with = plain SDP.=20 > >To deploy SDPng, every SIP element (UA, B2BUA, SBC, proxy) on the path = had to handle multipart MIME, but supporting=20 >multipart MIME wasn't required in RFC3261. I think the SIP body handling draft does require it, doesn't it? Regards, Christer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > I believe the draft is in a good shape.=20 > Possibly I wonder if it is not a better idea after all to move the=20 > a=3Dbcap (bandwidth capability) back to this draft ?, this because I=20 > beleieve bandwidth capabilities is strongly related to this draft=20 > anyway. >=20 > 1) Section 3.3.4.1 :=20 > I believe the ABNF is correct, however I believe that the line > m=3D["+"] *["|"] should read > ["+"]m=3D *["|"] ? > 2) Section 3.3.4.2 :=20 > I believe 1*WSP should be removed ? >=20 > 3) Section 3.3.5 : > [Editors note: it could simplify processing if > all capabilities referenced by latent or potential configurations > became media-level attributes/capabilities when transformed into > media configurations. Are there examples where session-level > attributes must be negotiated at the media level? Perhaps we need > some sort of "session configuration" or "scfg=3D" to handle the > session-level fields. Perhaps that could be somehow added to the > sescap attribute defined below.] > Personally I don't see the use case. >=20 > 4) Section 3.3.8 > [Editors' note: We have considered a form of the lcfg:=20 > attribute that > would permit an offerer to indicate that the configuration is > available for immediate acceptance via an answer with a=20 > corresponding > (new) m-line in the answer. This would permit the establishment of > the media streams to take place in one SDP exchange; at the same > time, non-negotiating endpoints could be offered a simple > configuration as in the above example. Ultimately, when all > endpoints understand the current specification, this would permit=20 > an > offer with latent configurations only, and an answer with the=20 > m-lines > for the accepted media streams.] > I would believe that this could be specified in a future version,=20 > possibly with a new option tag especially as the (new) m-line thing=20 > can cause some havoc elsewhere. >=20 > /Ingemar > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead"=20 > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > 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 dwing@cisco.com Tue Feb 24 14:17:32 2009 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 5C43428C14D for ; Tue, 24 Feb 2009 14:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_14=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 OKwI3-eL1q8f for ; Tue, 24 Feb 2009 14:17:31 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3E94F28C143 for ; Tue, 24 Feb 2009 14:17:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,261,1233532800"; d="scan'208";a="146861026" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2009 22:17:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1OMHoRc031490; Tue, 24 Feb 2009 14:17:50 -0800 Received: from dwingwxp01 (dhcp-128-107-163-55.cisco.com [128.107.163.55]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1OMHoD6013177; Tue, 24 Feb 2009 22:17:50 GMT From: "Dan Wing" To: "'Christer Holmberg'" , "'Ingemar Johansson S'" , References: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> <00e001c996be$0a2158c0$37a36b80@cisco.com> Date: Tue, 24 Feb 2009 14:17:51 -0800 Message-ID: <019c01c996cd$bb534b30$37a36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmWaM0/k/UsYRocRcabyO19fr9R9gAVIrlQAAOrRNAAAGX5IA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4252; t=1235513870; x=1236377870; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Comments=20on=20draft-ietf-m music-sdp-media-capabilities-06 |Sender:=20; bh=2TedoM1yafrGXtjyhmDPcrSbulhr43LsKEpU58t6OWk=; b=OE7froMPDpxcgpaiFdcY/jumG8vp24j7GjuKegNxun+xNk/lgBcB3JnxoD 8GgPUhM8iAXorCFF9G5k55MBSCpPcoU30hUELtxLMoC7kg5QF+otXWs6Wu6F jEYx6IbVjk; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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, 24 Feb 2009 22:17:32 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, February 24, 2009 2:09 PM > To: Dan Wing; Ingemar Johansson S; mmusic@ietf.org > Subject: RE: [MMUSIC] Comments on=20 > draft-ietf-mmusic-sdp-media-capabilities-06 >=20 >=20 > Hi,=20 >=20 > >I strongly support draft-ietf-mmusic-sdp-media-capabilities.=20 > It is necessary to allow negotiating AVP versus AVPF versus=20 > SAVP versus SAVPF (and whatever is defined later), and as you=20 > say will help=20 > >complex combinations of audio and video media -- which we=20 > are all anxious to deploy and use. > > > >Unlike SDPng, SDP Capabilities Negotiation is backwards=20 > compatible with plain SDP.=20 > > > >To deploy SDPng, every SIP element (UA, B2BUA, SBC, proxy)=20 > on the path had to handle multipart MIME, but supporting=20 > >multipart MIME wasn't required in RFC3261. >=20 > I think the SIP body handling draft does require it, doesn't it? Yes. But nothing requires someone to implement that once it becomes an RFC. Multipart MIME should have been a MUST in RFC3261; this was an oversight (I can only guess). -d > Regards, >=20 > Christer >=20 >=20 >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > I believe the draft is in a good shape.=20 > > Possibly I wonder if it is not a better idea after all to move the=20 > > a=3Dbcap (bandwidth capability) back to this draft ?, this because I = > > beleieve bandwidth capabilities is strongly related to this draft=20 > > anyway. > >=20 > > 1) Section 3.3.4.1 :=20 > > I believe the ABNF is correct, however I believe that the line > > m=3D["+"] *["|"] should read > > ["+"]m=3D *["|"] ? > > 2) Section 3.3.4.2 :=20 > > I believe 1*WSP should be removed ? > >=20 > > 3) Section 3.3.5 : > > [Editors note: it could simplify processing if > > all capabilities referenced by latent or potential configurations > > became media-level attributes/capabilities when transformed into > > media configurations. Are there examples where session-level > > attributes must be negotiated at the media level? =20 > Perhaps we need > > some sort of "session configuration" or "scfg=3D" to handle the > > session-level fields. Perhaps that could be somehow added to the > > sescap attribute defined below.] > > Personally I don't see the use case. > >=20 > > 4) Section 3.3.8 > > [Editors' note: We have considered a form of the lcfg:=20 > > attribute that > > would permit an offerer to indicate that the configuration is > > available for immediate acceptance via an answer with a=20 > > corresponding > > (new) m-line in the answer. This would permit the=20 > establishment of > > the media streams to take place in one SDP exchange; at the same > > time, non-negotiating endpoints could be offered a simple > > configuration as in the above example. Ultimately, when all > > endpoints understand the current specification, this=20 > would permit=20 > > an > > offer with latent configurations only, and an answer with the=20 > > m-lines > > for the accepted media streams.] > > I would believe that this could be specified in a future version,=20 > > possibly with a new option tag especially as the (new)=20 > m-line thing=20 > > can cause some havoc elsewhere. > >=20 > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead"=20 > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ingemar.s.johansson@ericsson.com Tue Feb 24 23:34:06 2009 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 9692E28C15B for ; Tue, 24 Feb 2009 23:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 0qUUmlo5MMt1 for ; Tue, 24 Feb 2009 23:34:05 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1C06528C1FD for ; Tue, 24 Feb 2009 23:34:05 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EEEE221DA6; Wed, 25 Feb 2009 08:23:24 +0100 (CET) X-AuditID: c1b4fb3c-ad289bb00000127c-39-49a4f16d1e24 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7AEF721184; Wed, 25 Feb 2009 08:21:17 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Feb 2009 08:21:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Feb 2009 08:20:08 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C7481A1@esealmw109.eemea.ericsson.se> In-Reply-To: <49A4678D.2070503@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 Thread-Index: AcmWx3WYwWh/zlkXTPuZVLjARchPTAATM83g References: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> <49A4678D.2070503@comcast.net> From: "Ingemar Johansson S" To: "Bob Gilman" X-OriginalArrivalTime: 25 Feb 2009 07:21:08.0440 (UTC) FILETIME=[A0CAED80:01C99719] X-Brightmail-Tracker: AAAAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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, 25 Feb 2009 07:34:06 -0000 Hi Comments to the ed. note in section 3.3.5.=20 Regards Ingemar > -----Original Message----- > From: Bob Gilman [mailto:bob_gilman@comcast.net]=20 > Sent: den 24 februari 2009 22:33 > To: Ingemar Johansson S > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Comments on=20 > draft-ietf-mmusic-sdp-media-capabilities-06 >=20 > Ingemar- > Thanks for looking at this draft. My responses below. > -Bob >=20 > Ingemar Johansson S wrote: > > Hi > >=20 > > I have read through the last version of the SDP media=20 > Capabilities negitiation draft.=20 > > Some comments below.=20 > >=20 > > That said...., it pains me to see that the interest in this=20 > is soooo low.=20 > > I believe that the authors would welcome more response to=20 > make this become an RFC, it would be really sad if this work=20 > eventually shares the same fate as SDPng just because the=20 > rest of the world did not see the immediate benefit. > > You may not see the killer use cases today, perhaps there=20 > are no killer use cases around but I have a strong feeling=20 > that the strengths of SDPCapNeg and its extensions will show=20 > up when whe start to look at capability exchange and=20 > negotiation of "richer media". > >=20 > > Regards > > Ingemar > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > I believe the draft is in a good shape.=20 > > Possibly I wonder if it is not a better idea after all to move the=20 > > a=3Dbcap (bandwidth > > capability) back to this draft ?, this because I beleieve bandwidth=20 > > capabilities is strongly related to this draft anyway. > >=20 > > 1) Section 3.3.4.1 :=20 > > I believe the ABNF is correct, however I believe that the line > > m=3D["+"] *["|"] should read > > ["+"]m=3D *["|"] ? > [rrg]: You're correct. >=20 > > 2) Section 3.3.4.2 :=20 > > I believe 1*WSP should be removed ? > [rrg]: Do you mean section 3.3.4.3? If so, you're correct. Yes :-) > >=20 > > 3) Section 3.3.5 : > > [Editors note: it could simplify processing if > > all capabilities referenced by latent or potential configurations > > became media-level attributes/capabilities when transformed into > > media configurations. Are there examples where session-level > > attributes must be negotiated at the media level? =20 > > Perhaps we need > > some sort of "session configuration" or "scfg=3D" to handle the > > session-level fields. Perhaps that could be somehow added to the > > sescap attribute defined below.] > > Personally I don't see the use case. > [rrg]: Are you saying it would be OK to restrict capabilities=20 > referenced by potential or latent configurations to media level = only? Not sure if I overlook something, as far as I can see I don't see any = problem with this restriction.I don't currently see any need for a = session configuration. Also, isn't there a risk in letting session level = attributes be negotiated on the media level. What happens if a potential = configuration for one media implies a change on a session level = attribute that also has a meaning for another media. That said I suspect = that I don't perhaps see the full picture, hope that others chime in.=20 > >=20 > > 4) Section 3.3.8 > > [Editors' note: We have considered a form of the lcfg:=20 > attribute that > > would permit an offerer to indicate that the configuration is > > available for immediate acceptance via an answer with a=20 > corresponding > > (new) m-line in the answer. This would permit the=20 > establishment of > > the media streams to take place in one SDP exchange; at the same > > time, non-negotiating endpoints could be offered a simple > > configuration as in the above example. Ultimately, when all > > endpoints understand the current specification, this=20 > would permit an > > offer with latent configurations only, and an answer=20 > with the m-lines > > for the accepted media streams.] > > I would believe that this could be specified in a future version,=20 > > possibly with a new option tag especially as the (new)=20 > m-line thing > > can cause some havoc elsewhere. > [rrg]: I have no problem with deferring such work until such time as > capability negotiation is ubiquitous. > >=20 > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead"=20 > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > >=20 >=20 >=20 > ------------------------------------------------------------- > Bob Gilman bob_gilman@comcast.net +1 303 898 9780 >=20 >=20 >=20 From richard@astri.org Thu Feb 26 00:18:00 2009 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 BC1EA28C2A9 for ; Thu, 26 Feb 2009 00:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLxnDC4OMhBR for ; Thu, 26 Feb 2009 00:18:00 -0800 (PST) Received: from mail1.astri.org (mail1.hkjcicm.org [218.188.84.5]) by core3.amsl.com (Postfix) with ESMTP id 72A3A28C1F1 for ; Thu, 26 Feb 2009 00:17:51 -0800 (PST) Received: (qmail 25154 invoked from network); 26 Feb 2009 08:18:02 -0000 X-NetworkBox-HamSign: 0101;OUT;astrihk1;77327d1ce2a9d42fccdccfa6f3ef6f7b; Received: from unknown (HELO ASPROEXG.astri.local) (10.6.2.21) by 172.16.1.240 with SMTP; 26 Feb 2009 08:18:01 -0000 Received: from [10.6.98.38] ([10.6.98.38]) by ASPROEXG.astri.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 16:18:29 +0800 Message-ID: <49A65012.1050802@astri.org> Date: Thu, 26 Feb 2009 16:17:22 +0800 From: Richard User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2009 08:18:29.0687 (UTC) FILETIME=[CE594C70:01C997EA] X-NetworkBox-BounceSign-astri: 0101;14301;4ee2a4c9 X-Scanned-By-astrihk1: Virus scan performed by network-box X-Scanned-By-astrihk1: Scanner file id is astrihk1-1235636281.745-25148-000 X-Scanned-By-astrihk1: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-astrihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 Cc: Fu Siu Ming Claudio Subject: [MMUSIC] RTCP and RTCP XR report 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: Thu, 26 Feb 2009 08:18:00 -0000 Hi, If the device supports both RTCP and RTCP XR, is there any rule governing the following: 1) whether RTCP reports and RTCP XR reports can be sent together, either as a compound packet or 2 separate packets? 2) if 2 separate packets are to be sent, how can the receiver determine whether the 2 reports are describing the statistics in the same sequence number interval? Thanks. Richard ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Stiemerling@nw.neclab.eu Thu Feb 26 02:32:04 2009 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 814D53A6BDE for ; Thu, 26 Feb 2009 02:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 1D4ca2Mca4Xu for ; Thu, 26 Feb 2009 02:32:03 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A77CB3A68F5 for ; Thu, 26 Feb 2009 02:32:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 987FE2C00030D for ; Thu, 26 Feb 2009 11:32:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiIzEjqubX0I for ; Thu, 26 Feb 2009 11:32:24 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 7AB802C0000EB for ; Thu, 26 Feb 2009 11:32:19 +0100 (CET) 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: Thu, 26 Feb 2009 11:32:17 +0100 Message-ID: <547F018265F92642B577B986577D671C70013E@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTSP: poll about who is implementing speed in its implementation Thread-Index: AcmX/X99x8TGiZZySXq33TfBCpJ6YQ== From: "Martin Stiemerling" To: Subject: [MMUSIC] RTSP: poll about who is implementing speed in its implementation 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: Thu, 26 Feb 2009 10:32:04 -0000 Hi all, There has been a discussion in the past, which is still ongoing, about = the speed/scale header semantics and their dependencies. (see the email = thread starting with Magnus' email Dec 02, 2008) We have not reached a consensus, not even rough consensus, on this issue = for a long time.=20 When going through the past discussion I always stumble about the = general question "is the speed semantics needed" and thus the header = itself?=20 Therefore a poll amongst the RTSP implementers: a) Who is actually implementing the speed header and the algorithm = behind? b) Who does know any deployment using this? Thanks, Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From Stiemerling@nw.neclab.eu Thu Feb 26 05:05:49 2009 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 6CFCA3A67F7 for ; Thu, 26 Feb 2009 05:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 r5A1rdRsMSBn for ; Thu, 26 Feb 2009 05:05:48 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 01FF33A6AAA for ; Thu, 26 Feb 2009 05:05:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 100E72C017B31 for ; Thu, 26 Feb 2009 14:06:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtutcclTSn8V for ; Thu, 26 Feb 2009 14:06:08 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id E61792C0000EB for ; Thu, 26 Feb 2009 14:06:03 +0100 (CET) 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: Thu, 26 Feb 2009 14:06:03 +0100 Message-ID: <547F018265F92642B577B986577D671C70016C@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTSP: Contradicting text in RFC2326bis and RFC 2616 Thread-Index: AcmYEvo0+IYS1PZ0TIa/1yo9uOA+cw== From: "Martin Stiemerling" To: Subject: [MMUSIC] RTSP: Contradicting text in RFC2326bis and RFC 2616 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: Thu, 26 Feb 2009 13:05:49 -0000 Hi all, Just to clarify the intended use of the Date header field. draft-ietf-mmusic-rfc2326bis-19.txt says this in Section 16.20. "Date": See [H14.18]. An RTSP message containing a body MUST include a Date header if the sending host has a clock. Servers SHOULD include a Date header in all other RTSP messages. When adding the text out of [H14.18] to RFC2326bis we end up with this, as the text "Servers SHOULD include a Date header in all other RTSP messages." contradicts the text in RFC 2616: Origin servers MUST include a Date header field in all responses, except in these cases: 1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option. 2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date. 3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.18.1 MUST be followed. Any guidance is welcome :) Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From tom.taylor@rogers.com Thu Feb 26 05:45:07 2009 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 16FA33A6A2B for ; Thu, 26 Feb 2009 05:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.753, 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 5KCXw0n-iYRp for ; Thu, 26 Feb 2009 05:45:03 -0800 (PST) Received: from smtp131.rog.mail.re2.yahoo.com (smtp131.rog.mail.re2.yahoo.com [206.190.53.36]) by core3.amsl.com (Postfix) with SMTP id 15A923A692E for ; Thu, 26 Feb 2009 05:45:02 -0800 (PST) Received: (qmail 33331 invoked from network); 26 Feb 2009 13:45:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dOKID7I2fbcFM9F0HlnMBxVesfIH3T3fJYvMskk3iz4/DC3LIYUR8IJW6TGXcCkqNj64vdyA4D4MJdulNR1hcUyMmce0S4nEdtJvSN01nsSGcnkVrLh3yPZLbvT6dl/leq9giF6QCc2LmHn9i7/o/zZPjPzQakemN352i3mI0Vg= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp131.rog.mail.re2.yahoo.com with SMTP; 26 Feb 2009 13:45:24 -0000 X-YMail-OSG: 6vG07hYVM1nV_7Oigh.8yL4e1p11dOgzT.0jcSKay966UhT44JU6kcdU7DT0uO29NA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A69CF2.9020008@rogers.com> Date: Thu, 26 Feb 2009 08:45:22 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Richard References: <49A65012.1050802@astri.org> In-Reply-To: <49A65012.1050802@astri.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fu Siu Ming Claudio , mmusic@ietf.org Subject: Re: [MMUSIC] RTCP and RTCP XR report 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: Thu, 26 Feb 2009 13:45:07 -0000 This is a question for the AVT list. I'll forward it on your behalf. Tom Taylor Richard wrote: > Hi, > > If the device supports both RTCP and RTCP XR, is there any rule > governing the following: > 1) whether RTCP reports and RTCP XR reports can be sent together, either > as a compound packet or 2 separate packets? > 2) if 2 separate packets are to be sent, how can the receiver determine > whether the 2 reports are describing the statistics in the same sequence > number interval? > > Thanks. > Richard > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > This message (including any attachments) is for the named > addressee(s)'s use only. It may contain sensitive, confidential, > private proprietary or legally privileged information intended for a > specific individual and purpose, and is protected by law. If you are > not the intended recipient, please immediately delete it and all copies > of it from your system, destroy any hard copies of it > and notify the sender. Any use, disclosure, copying, or distribution of > this message and/or any attachments is strictly prohibited. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > From Remi.Denis-Courmont@nokia.com Thu Feb 26 05:51:53 2009 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 70CC228C29A for ; Thu, 26 Feb 2009 05:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 R7+dVuTY8o0U for ; Thu, 26 Feb 2009 05:51:52 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2F88D28C297 for ; Thu, 26 Feb 2009 05:51:51 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1QDq1HD001294 for ; Thu, 26 Feb 2009 15:52:07 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 15:48:24 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 15:48:24 +0200 Received: from leon.remlab.net (esdhcp04047.research.nokia.com [172.21.40.47]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n1QDmMHw011924 for ; Thu, 26 Feb 2009 15:48:22 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: mmusic@ietf.org Date: Thu, 26 Feb 2009 15:48:39 +0200 User-Agent: KMail/1.11.0 (Linux/2.6.28.7; KDE/4.2.0; i686; ; ) References: <547F018265F92642B577B986577D671C70016C@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C70016C@VENUS.office> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902261548.39890.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 26 Feb 2009 13:48:24.0108 (UTC) FILETIME=[E4BE3EC0:01C99818] X-Nokia-AV: Clean Subject: Re: [MMUSIC] RTSP: Contradicting text in RFC2326bis and RFC 2616 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: Thu, 26 Feb 2009 13:51:53 -0000 On Thursday 26 February 2009 15:06:03 ext Martin Stiemerling wrote: > Hi all, > > Just to clarify the intended use of the Date header field. If the server has no accurate clock, it simply cannot fill the date field=20 (with meaningful informations at least). I guess dates are mostly useful fo= r=20 caching, which is possibly not very relevant for RTSP. At least, you surely cannot do media-level synchronization with that date,= =20 since the inaccuracy will likely be too high for such purpose. =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From root@core3.amsl.com Thu Feb 26 06:00:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 64E6528C285; Thu, 26 Feb 2009 06:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090226140001.64E6528C285@core3.amsl.com> Date: Thu, 26 Feb 2009 06:00:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-sdp-media-capabilities-07.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: Thu, 26 Feb 2009 14:00:01 -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 : SDP media capabilities Negotiation Author(s) : R. Gilman, et al. Filename : draft-ietf-mmusic-sdp-media-capabilities-07.txt Pages : 47 Date : 2009-02-26 Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This extension is designed to map easily to existing and future SDP media attributes, but not encodings or formatting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-07.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-sdp-media-capabilities-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-26055109.I-D@ietf.org> --NextPart-- From AVSHALOM@il.ibm.com Thu Feb 26 07:03:14 2009 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 5C4BC3A6968 for ; Thu, 26 Feb 2009 07:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 h0nlsornHa6w for ; Thu, 26 Feb 2009 07:03:13 -0800 (PST) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by core3.amsl.com (Postfix) with ESMTP id D9BC93A68F6 for ; Thu, 26 Feb 2009 07:03:12 -0800 (PST) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n1QF3R3W076718 for ; Thu, 26 Feb 2009 15:03:27 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n1QF3Pol1314920 for ; Thu, 26 Feb 2009 16:03:26 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1QF3FK3014199 for ; Thu, 26 Feb 2009 16:03:15 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1QF3FQM014166 for ; Thu, 26 Feb 2009 16:03:15 +0100 To: mmusic@ietf.org MIME-Version: 1.0 X-KeepSent: 1BC86DE8:67214793-C2257569:00500E16; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Avshalom Houri Message-ID: Date: Thu, 26 Feb 2009 17:03:13 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 26/02/2009 17:03:14, Serialize complete at 26/02/2009 17:03:14 Content-Type: multipart/alternative; boundary="=_alternative 0052AFFFC2257569_=" Cc: Uri Segev Subject: [MMUSIC] Question on Authentication in ICE & STUN 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: Thu, 26 Feb 2009 15:03:14 -0000 This is a multipart message in MIME format. --=_alternative 0052AFFFC2257569_= Content-Type: text/plain; charset="US-ASCII" (Question was raised by Uri Segev, CCd) Section 7.2 of the ICE draft indicates that: The agent MUST use a short term credential to authenticate the request and perform a message integrity check. The agent MUST consider the username to be valid if it consists of two values separated by a colon, where the first value is equal to the username fragment generated by the agent in an offer or answer for a session in-progress. It is possible (and in fact very likely) that an offerer will receive a Binding Request prior to receiving the answer from its peer. If this happens, the agent MUST immediately generate a response (including computation of the mapped address as described in Section 7.2.1.2. The agent has sufficient information at this point to generate the response; the password from the peer is not required. Once the answer is received, it MUST proceed with the remaining steps required, namely Section 7.2.1.3, Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several pairs to be queued up in the triggered check queue. Because the offerer will receive the Binding request before it knows the remote credentials, it doesn't have any way to authenticate the incoming request (as specified in the text above). However, RFC 5389 (STUN), section 10.1.2 (Receiving a Request or Indication): o If the USERNAME does not contain a username value currently valid within the server: * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). * If the message is an indication, the agent MUST silently discard the indication. If these checks pass, the agent continues to process the request or indication. Any response generated by a server MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. The response MUST NOT contain the USERNAME attribute. This means that the offerer STUN layer should reject the connectivity check and not give it to the ICE layer. Furthermore, if it would accept it, the server doesn't have a way to provide the response. Does the ICE spec requires different behavior from the STUN implementation? One more issue related to long term authentication: When the server is using a directory which stores only a hashed value of the password, compared to an encrypted password which can be retrieved or H(A1), is there any way to use long term credentials? (and for that matter also digest authentication in SIP)? --Avshalom --=_alternative 0052AFFFC2257569_= Content-Type: text/html; charset="US-ASCII" (Question was raised by Uri Segev, CCd)

Section 7.2 of the ICE draft indicates that:
   
   The agent MUST use a short term credential to authenticate the
   request and perform a message integrity check.  The agent MUST
   consider the username to be valid if it consists of two values
   separated by a colon, where the first value is equal to the username
   fragment generated by the agent in an offer or answer for a session
   in-progress.  It is possible (and in fact very likely) that an
   offerer will receive a Binding Request prior to receiving the answer
   from its peer.  If this happens, the agent MUST immediately generate
   a response (including computation of the mapped address as described
   in Section 7.2.1.2.  The agent has sufficient information at this
   point to generate the response; the password from the peer is not
   required.  Once the answer is received, it MUST proceed with the
   remaining steps required, namely Section 7.2.1.3, Section 7.2.1.4,
   and Section 7.2.1.5 for full implementations.  In cases where
   multiple STUN requests are received before the answer, this may cause
   several pairs to be queued up in the triggered check queue.

Because the offerer will receive the Binding request before it knows the
remote credentials, it doesn't have any way to authenticate the incoming
request (as specified in the text above).

However, RFC 5389 (STUN), section 10.1.2 (Receiving a Request or
Indication):

   o  If the USERNAME does not contain a username value currently valid
      within the server:

      *  If the message is a request, the server MUST reject the request
         with an error response.  This response MUST use an error code
         of 401 (Unauthorized).

      *  If the message is an indication, the agent MUST silently
         discard the indication.

   If these checks pass, the agent continues to process the request or
   indication.  Any response generated by a server MUST include the
   MESSAGE-INTEGRITY attribute, computed using the password utilized to
   authenticate the request.  The response MUST NOT contain the USERNAME
   attribute.

This means that the offerer STUN layer should reject the connectivity
check and not give it to the ICE layer. Furthermore, if it would accept
it, the server doesn't have a way to provide the response.

Does the ICE spec requires different behavior from the STUN
implementation?

One more issue related to long term authentication: When the server is
using a directory which stores only a hashed value of the password,
compared to an encrypted password which can be retrieved or H(A1), is
there any way to use long term credentials? (and for that matter also
digest authentication in SIP)?

--Avshalom

--=_alternative 0052AFFFC2257569_=-- From glavoie@media5corp.com Thu Feb 26 07:44:21 2009 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 A93AD28C11A for ; Thu, 26 Feb 2009 07:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] 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 c8V6QFbf1qXn for ; Thu, 26 Feb 2009 07:44:20 -0800 (PST) Received: from m5tmail1.m5t.com (m5tmail1.m5t.com [207.134.65.96]) by core3.amsl.com (Postfix) with ESMTP id 308593A693D for ; Thu, 26 Feb 2009 07:44:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Thu, 26 Feb 2009 10:44:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99829.23616F89" Message-ID: <6EF4CC794ECF2B409390605FDEA9012275339D@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on Authentication in ICE & STUN Thread-Index: AcmYI2pUe454JsRrQ9e91CvzEsnv5QAAEEPgAADQfaAAAISBQA== From: "Guylain Lavoie" To: "Avshalom Houri" , Cc: Uri Segev Subject: Re: [MMUSIC] Question on Authentication in ICE & STUN 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: Thu, 26 Feb 2009 15:44:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99829.23616F89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Avshalom, =20 When a binding request is sent, it must be authenticated with the password of the STUN server side . In this case, the answerer will authenticate the binding request it sends to the offerer using the password provided by the offerer . =20 The STUN server in the context of ICE will need to be a little more intelligent than just searching for the specific username in its database. Instead, it will need to parse the username and retrieve the local username fragment to find the correct password to use. In our ICE implementation, the STUN server implementation has a hook to request to its manager (the ICE implementation) what is the password associated with the username. The ICE implementation must then split the username and find the correct password. This allow the STUN layer to still be compliant with the specification while offering more flexibility. =20 Best Regards, Guylain =20 Guylain Lavoie Technical Product Manager M5T, a Division of Media5 Corporation Web: http://www.m5t.com =20 Email: glavoie@m5t.com =20 Tel: +1-819-829-1008, ext: 662 Fax: +1-819-829-1342 ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: February 26, 2009 10:03 AM To: mmusic@ietf.org Cc: Uri Segev Subject: [MMUSIC] Question on Authentication in ICE & STUN (Question was raised by Uri Segev, CCd)=20 Section 7.2 of the ICE draft indicates that:=20 =20 The agent MUST use a short term credential to authenticate the=20 request and perform a message integrity check. The agent MUST=20 consider the username to be valid if it consists of two values=20 separated by a colon, where the first value is equal to the username=20 fragment generated by the agent in an offer or answer for a session=20 in-progress. It is possible (and in fact very likely) that an=20 offerer will receive a Binding Request prior to receiving the answer=20 from its peer. If this happens, the agent MUST immediately generate=20 a response (including computation of the mapped address as described=20 in Section 7.2.1.2. The agent has sufficient information at this=20 point to generate the response; the password from the peer is not=20 required. Once the answer is received, it MUST proceed with the=20 remaining steps required, namely Section 7.2.1.3, Section 7.2.1.4,=20 and Section 7.2.1.5 for full implementations. In cases where=20 multiple STUN requests are received before the answer, this may cause several pairs to be queued up in the triggered check queue.=20 Because the offerer will receive the Binding request before it knows the remote credentials, it doesn't have any way to authenticate the incoming request (as specified in the text above).=20 However, RFC 5389 (STUN), section 10.1.2 (Receiving a Request or=20 Indication):=20 o If the USERNAME does not contain a username value currently valid=20 within the server:=20 * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code=20 of 401 (Unauthorized).=20 * If the message is an indication, the agent MUST silently=20 discard the indication.=20 If these checks pass, the agent continues to process the request or=20 indication. Any response generated by a server MUST include the=20 MESSAGE-INTEGRITY attribute, computed using the password utilized to=20 authenticate the request. The response MUST NOT contain the USERNAME attribute.=20 This means that the offerer STUN layer should reject the connectivity=20 check and not give it to the ICE layer. Furthermore, if it would accept=20 it, the server doesn't have a way to provide the response.=20 Does the ICE spec requires different behavior from the STUN=20 implementation?=20 One more issue related to long term authentication: When the server is=20 using a directory which stores only a hashed value of the password,=20 compared to an encrypted password which can be retrieved or H(A1), is=20 there any way to use long term credentials? (and for that matter also=20 digest authentication in SIP)?=20 --Avshalom=20 ------_=_NextPart_001_01C99829.23616F89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello =20 Avshalom,
 
When a binding request is sent, = it  must be authenticated with the = password of=20 the STUN server side . = In this=20 case, the answerer will authenticate the binding request it sends to the = offerer=20 using the password provided by the offerer .   
The STUN server in the context of ICE will need = to be a=20 little more intelligent than just searching for the specific username in = its=20 database. Instead, it will need to parse the username and retrieve the = local=20 username fragment to find the correct password to = use.
In our ICE implementation, the STUN server = implementation=20 has a hook to request to its manager (the ICE implementation) what is = the=20 password associated with the username. The ICE implementation must = then=20 split the username and find the correct password. This allow the STUN = layer to=20 still be compliant with the specification while offering more=20 flexibility.
 
Best Regards,
Guylain
 
Guylain Lavoie
Technical Product Manager
M5T, a Division of Media5 = Corporation
Web: http://www.m5t.com
=
Email: glavoie@m5t.com
=
Tel: +1-819-829-1008, ext: = 662
Fax: +1-819-829-1342
From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: February 26, 2009 10:03=20 AM
To: mmusic@ietf.org
Cc: Uri = Segev
Subject:=20 [MMUSIC] Question on Authentication in ICE & = STUN

(Question was raised by = Uri Segev,=20 CCd)

Section 7.2 of = the ICE draft=20 indicates that:
  =  =20
   The agent MUST use = a short term=20 credential to authenticate the
 =20  request and perform a message integrity check.  The agent = MUST=20
   consider the = username to be=20 valid if it consists of two values
   separated by a colon, where the first value is = equal to the=20 username
  =  fragment=20 generated by the agent in an offer or answer for a session =
   in-progress.  It is = possible (and in=20 fact very likely) that an
 =20  offerer will receive a Binding Request prior to receiving the=20 answer
   from = its peer.=20  If this happens, the agent MUST immediately generate =
   a response (including = computation of the=20 mapped address as described
 =20  in Section 7.2.1.2.  The agent has sufficient information at=20 this
   point = to generate=20 the response; the password from the peer is not
   required.  Once the = answer is=20 received, it MUST proceed with the
   remaining steps required, namely Section 7.2.1.3, = Section=20 7.2.1.4,
   and = Section=20 7.2.1.5 for full implementations.  In cases where
   multiple STUN requests are = received=20 before the answer, this may cause
   several pairs to be queued up in the triggered = check=20 queue.

Because the = offerer will=20 receive the Binding request before it knows the
remote credentials, it doesn't have any = way to=20 authenticate the incoming
request (as=20 specified in the text above).

However, RFC 5389 (STUN), section 10.1.2 (Receiving a Request = or=20
Indication): =

   o  If the USERNAME does = not contain=20 a username value currently valid
      within the server:

      *  If the = message is a=20 request, the server MUST reject the request
         with an error response. =  This=20 response MUST use an error code
         of 401 (Unauthorized). =

      * =  If the=20 message is an indication, the agent MUST silently
         discard = the=20 indication.

  =  If these=20 checks pass, the agent continues to process the request or =
   indication.  Any = response generated=20 by a server MUST include the
 =20  MESSAGE-INTEGRITY attribute, computed using the password utilized=20 to
  =  authenticate the=20 request.  The response MUST NOT contain the USERNAME =
   attribute. =

This means that the offerer STUN layer = should reject=20 the connectivity
check = and not give=20 it to the ICE layer. Furthermore, if it would accept
it, the server doesn't have a way to = provide the=20 response.

Does the = ICE spec=20 requires different behavior from the STUN
implementation?

One more=20 issue related to long term authentication: When the server is =
using a directory which stores only a = hashed value of=20 the password,
compared to = an=20 encrypted password which can be retrieved or H(A1), is
there any way to use long term = credentials? (and for=20 that matter also
digest=20 authentication in SIP)?

--Avshalom

------_=_NextPart_001_01C99829.23616F89-- From youness.alaoui@collabora.co.uk Thu Feb 26 09:55:12 2009 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 9E5743A6915 for ; Thu, 26 Feb 2009 09:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, SARE_LWSHORTT=1.24] 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 GmEmKkVfd9MG for ; Thu, 26 Feb 2009 09:55:11 -0800 (PST) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [195.10.223.82]) by core3.amsl.com (Postfix) with ESMTP id 2C0133A6838 for ; Thu, 26 Feb 2009 09:55:10 -0800 (PST) Received: from [192.168.1.128] (MTLXPQAK-1176055545.sdsl.bell.ca [70.25.46.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bhuna.collabora.co.uk (Postfix) with ESMTP id A63CAF53F6; Thu, 26 Feb 2009 17:55:25 +0000 (GMT) Message-ID: <49A6D786.2030809@collabora.co.uk> Date: Thu, 26 Feb 2009 12:55:18 -0500 From: Youness Alaoui User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Avshalom Houri References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Uri Segev , mmusic@ietf.org Subject: Re: [MMUSIC] Question on Authentication in ICE & STUN 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: Thu, 26 Feb 2009 17:55:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Avshalom Houri wrote: > (Question was raised by Uri Segev, CCd) > > Section 7.2 of the ICE draft indicates that: > > The agent MUST use a short term credential to authenticate the > request and perform a message integrity check. The agent MUST > consider the username to be valid if it consists of two values > separated by a colon, where the first value is equal to the username > fragment generated by the agent in an offer or answer for a session > in-progress. It is possible (and in fact very likely) that an > offerer will receive a Binding Request prior to receiving the answer > from its peer. If this happens, the agent MUST immediately generate > a response (including computation of the mapped address as described > in Section 7.2.1.2. The agent has sufficient information at this > point to generate the response; the password from the peer is not > required. Once the answer is received, it MUST proceed with the > remaining steps required, namely Section 7.2.1.3, Section 7.2.1.4, > and Section 7.2.1.5 for full implementations. In cases where > multiple STUN requests are received before the answer, this may cause > several pairs to be queued up in the triggered check queue. > > Because the offerer will receive the Binding request before it knows the > remote credentials, it doesn't have any way to authenticate the incoming > request (as specified in the text above). > Actually, it already has everything it needs to authenticate the incoming request. Since the incoming request will use the local password for generating the message-integrity, you can authenticate it without knowing the remote password. Also note that the spec says that the first part of the username must be your local ufrag, so you MUST make sure your ICE implementation will parse the username to verify the local ufrag part only, not generate the local:remote and try to compare it with the username. > However, RFC 5389 (STUN), section 10.1.2 (Receiving a Request or > Indication): > > o If the USERNAME does not contain a username value currently valid > within the server: > > * If the message is a request, the server MUST reject the request > with an error response. This response MUST use an error code > of 401 (Unauthorized). > > * If the message is an indication, the agent MUST silently > discard the indication. > > If these checks pass, the agent continues to process the request or > indication. Any response generated by a server MUST include the > MESSAGE-INTEGRITY attribute, computed using the password utilized to > authenticate the request. The response MUST NOT contain the USERNAME > attribute. > > This means that the offerer STUN layer should reject the connectivity > check and not give it to the ICE layer. Furthermore, if it would accept > it, the server doesn't have a way to provide the response. > No, the USERNAME does contain a valid username value, you just have to make sure that the ICE layer will parse the USERNAME and tell the STUN layer if it's valid or not (the RFC 5389 spec doesn't specify how the validity of the username needs to be verified). You also have everything you need since the STUN response will be using the same username and password as the one for the incoming request, so you still don't need the remote information to validate the message or respond to it. > Does the ICE spec requires different behavior from the STUN > implementation? > No, you just need to make sure your STUN implementation allows you to tell it if a username is valid or not and which password is associated with it, and not have a static list of username/passwords to check. You can have a look at the way it's implemented in libnice. Line 188 : http://git.collabora.co.uk/?p=user/kakaroto/libnice.git;a=blob;f=stun/stunagent.h;h=d47b1712029df3a024a95c4ec2f938347604ea80;hb=e6b909de1952609694a2b886ce4d217f41f9708d#l187 What my STUN layer does is that when you call stun_agent_validate() you give it a validater callback function that will get called with the username as argument, it validates the username and provides the corresponding password back to the STUN agent. You can also set the callback to stun_agent_default_validater, which takes a simple username/password structure to associate a username to a password. What the ICE layer does however is : Line 2137 : http://git.collabora.co.uk/?p=user/kakaroto/libnice.git;a=blob;f=agent/conncheck.c;h=36d05bfe2e6e779d305d433a1ffecb4bbf6ff977;hb=e6b909de1952609694a2b886ce4d217f41f9708d#l2137 Which is to set its own validater callback which will only check the first part of the username and compare it to the ufrag, then give the local password back to the STUN agent. > One more issue related to long term authentication: When the server is > using a directory which stores only a hashed value of the password, > compared to an encrypted password which can be retrieved or H(A1), is > there any way to use long term credentials? (and for that matter also > digest authentication in SIP)? Humm.. I'm not sure if I'm the right person to answer that, but my guess is that you would have to store the passwords plaintext on the server otherwise you can't use them for long term authentication (or SIP digest). Hope that helps. Youness. > > --Avshalom > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkmm14YACgkQqvxLNLvrsxxh6wCY7UleDflH86pD5bu5CYkA2CpB PwCfXl9uPW3VjFArBybvY2mh8OTFaK0= =aYio -----END PGP SIGNATURE----- From bob_gilman@comcast.net Thu Feb 26 12:46:37 2009 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 1310428C2F3 for ; Thu, 26 Feb 2009 12:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0EQSwlwRn2Z for ; Thu, 26 Feb 2009 12:46:35 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id A21AF3A680E for ; Thu, 26 Feb 2009 12:46:35 -0800 (PST) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Ljsn1b0020FhH24A2kmyqi; Thu, 26 Feb 2009 20:46:58 +0000 Received: from [192.168.1.101] ([67.176.84.91]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id Lkmw1b0061yDsSj8Ukmxul; Thu, 26 Feb 2009 20:46:58 +0000 Message-ID: <49A6FFC6.1050704@comcast.net> Date: Thu, 26 Feb 2009 13:47:02 -0700 From: Bob Gilman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C719AA1@esealmw109.eemea.ericsson.se> <49A4678D.2070503@comcast.net> <130EBB38279E9847BAAAE0B8F9905F8C7481A1@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C7481A1@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06 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: Thu, 26 Feb 2009 20:46:37 -0000 Ingemar- Your concern about conflicting session-level fields arising from media-level choices is what prompted me to suggest the restriction of capabilities to the media level. I certainly don't want capability processing to be burdened with choosing a set of media options in such a way that no conflicts arise at the session level. -Bob ------------------------------------------------------------- Bob Gilman bob_gilman@comcast.net +1 303 898 9780 Ingemar Johansson S wrote: > Hi > > Comments to the ed. note in section 3.3.5. > > Regards > Ingemar > > >> -----Original Message----- >> From: Bob Gilman [mailto:bob_gilman@comcast.net] >> Sent: den 24 februari 2009 22:33 >> To: Ingemar Johansson S >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Comments on >> draft-ietf-mmusic-sdp-media-capabilities-06 >> >> Ingemar- >> Thanks for looking at this draft. My responses below. >> -Bob >> >> Ingemar Johansson S wrote: >>> Hi >>> >>> I have read through the last version of the SDP media >> Capabilities negitiation draft. >>> Some comments below. >>> >>> That said...., it pains me to see that the interest in this >> is soooo low. >>> I believe that the authors would welcome more response to >> make this become an RFC, it would be really sad if this work >> eventually shares the same fate as SDPng just because the >> rest of the world did not see the immediate benefit. >>> You may not see the killer use cases today, perhaps there >> are no killer use cases around but I have a strong feeling >> that the strengths of SDPCapNeg and its extensions will show >> up when whe start to look at capability exchange and >> negotiation of "richer media". >>> Regards >>> Ingemar >>> >>> ============================== >>> I believe the draft is in a good shape. >>> Possibly I wonder if it is not a better idea after all to move the >>> a=bcap (bandwidth >>> capability) back to this draft ?, this because I beleieve bandwidth >>> capabilities is strongly related to this draft anyway. >>> >>> 1) Section 3.3.4.1 : >>> I believe the ABNF is correct, however I believe that the line >>> m=["+"] *["|"] should read >>> ["+"]m= *["|"] ? >> [rrg]: You're correct. >> >>> 2) Section 3.3.4.2 : >>> I believe 1*WSP should be removed ? >> [rrg]: Do you mean section 3.3.4.3? If so, you're correct. > Yes :-) > >>> 3) Section 3.3.5 : >>> [Editors note: it could simplify processing if >>> all capabilities referenced by latent or potential configurations >>> became media-level attributes/capabilities when transformed into >>> media configurations. Are there examples where session-level >>> attributes must be negotiated at the media level? >>> Perhaps we need >>> some sort of "session configuration" or "scfg=" to handle the >>> session-level fields. Perhaps that could be somehow added to the >>> sescap attribute defined below.] >>> Personally I don't see the use case. >> [rrg]: Are you saying it would be OK to restrict capabilities >> referenced by potential or latent configurations to media level only? > Not sure if I overlook something, as far as I can see I don't see any problem with this restriction.I don't currently see any need for a session configuration. Also, isn't there a risk in letting session level attributes be negotiated on the media level. What happens if a potential configuration for one media implies a change on a session level attribute that also has a meaning for another media. That said I suspect that I don't perhaps see the full picture, hope that others chime in. > >>> 4) Section 3.3.8 >>> [Editors' note: We have considered a form of the lcfg: >> attribute that >>> would permit an offerer to indicate that the configuration is >>> available for immediate acceptance via an answer with a >> corresponding >>> (new) m-line in the answer. This would permit the >> establishment of >>> the media streams to take place in one SDP exchange; at the same >>> time, non-negotiating endpoints could be offered a simple >>> configuration as in the above example. Ultimately, when all >>> endpoints understand the current specification, this >> would permit an >>> offer with latent configurations only, and an answer >> with the m-lines >>> for the accepted media streams.] >>> I would believe that this could be specified in a future version, >>> possibly with a new option tag especially as the (new) >> m-line thing >>> can cause some havoc elsewhere. >> [rrg]: I have no problem with deferring such work until such time as >> capability negotiation is ubiquitous. >>> /Ingemar >>> ******************************************* >>> Ingemar Johansson >>> Senior Research Engineer, IETF "nethead" >>> EAB/TVP - Multimedia Technologies >>> Ericsson Research Ericsson AB >>> Box 920 S-971 28 Luleå, Sweden >>> Tel: +46 (0)10 7143042 >>> ECN: 852-43042 >>> ECC: 852-19042 >>> Mobile: +46 (0)730 783289 >>> Visit http://labs.ericsson.com ! >>> ******************************************* >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> ------------------------------------------------------------- >> Bob Gilman bob_gilman@comcast.net +1 303 898 9780 >> >> >> > From jaehwan@vidiator.com Fri Feb 27 01:55:22 2009 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 55A803A6AC3 for ; Fri, 27 Feb 2009 01:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCikdDOl7L0Y for ; Fri, 27 Feb 2009 01:55:21 -0800 (PST) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id 302C43A6B48 for ; Fri, 27 Feb 2009 01:55:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 18:53:54 +0900 Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C70016C@VENUS.office> References: <547F018265F92642B577B986577D671C70016C@VENUS.office> From: "Jaehwan Kim" To: "Martin Stiemerling" , Subject: Re: [MMUSIC] RTSP: Contradicting text in RFC2326bis and RFC 2616 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, 27 Feb 2009 09:55:22 -0000 Hi Martin, Yes. It looks like contradiction at the text of draft-ietf-mmusic-rfc2326bis-19.txt. You might simply remove 2326bis' and remake new text... 1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option. [jh] 100 came from HTTP but still meaningful even in RTSP. =20 2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date. [jh] yes. The purpose of Date header is 1) cache, 2) logging, 3) a reference of the management of system for different locations or countries. But not the all case we can make Date. One use case would be the disconnection between server and realtime encoder. Still we can make a date which could be very useful for the analysis of the problem. 3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.18.1 MUST be followed. [jh] RTSP allows client sends Request. Then, this is not limited just to Server, but also to client. But is there anyone who saw so-called 'no clock server or client'? In case of HTTP, it might be. But in RTSP server? We use timestamp in RTP or whatever we call 'streaming media', don't we? If it is not the case for RTSP, we are happy with simple text with above only two cases. Regards, Jaehwan Vidiator From igor.curcio@nokia.com Fri Feb 27 06:47:06 2009 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 099663A6452; Fri, 27 Feb 2009 06:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 LwDyNJ2ayMJM; Fri, 27 Feb 2009 06:47:03 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2EEAB3A6899; Fri, 27 Feb 2009 06:47:03 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1REl4pW013315; Fri, 27 Feb 2009 08:47:23 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 16:47:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 16:47:21 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 27 Feb 2009 15:47:20 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Fri, 27 Feb 2009 15:47:20 +0100 From: To: , Date: Fri, 27 Feb 2009 15:47:19 +0100 Thread-Topic: Call for Papers / WoWMoM '09 / Industry Track Thread-Index: AcmQyHjcjWlgubC1Sh2jzSR4f49cjQAE2akQAAE/ykAB15EyIAAAx+CQACmrTTA= Message-ID: <08485F91AF534543877F9738F761DCFE27E902D05A@NOK-EUMSG-01.mgdnok.nokia.com> References: <499a58b2.0aa1660a.24ce.ffffc36e@mx.google.com> <238382595265324EA50F6134BB42DCAF034F7343@FRVELSMBS22.ad2.ad.alcatel.com> <499a8530.0aec660a.29ef.0b97@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D5408BCADD8@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408BCADD8@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_08485F91AF534543877F9738F761DCFE27E902D05ANOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2009 14:47:21.0296 (UTC) FILETIME=[4B7C0D00:01C998EA] X-Nokia-AV: Clean Subject: [MMUSIC] Call for Papers / WoWMoM '09 / Industry Track 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, 27 Feb 2009 14:47:06 -0000 --_000_08485F91AF534543877F9738F761DCFE27E902D05ANOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 10th IEEE International Symposium on a World of Wireless, Mobile and Multim= edia Networks 15-19 June 2009, Kos, Greece Call For Papers -- Industrial Track http://www.ics.forth.gr/wowmom09/callforindustrialpapers.html Important dates: * Paper submission deadline: 15 March 2009 (HARD DEADLINE) * Acceptance notification: 29 March 2009 * Camera-ready copy deadline: 11 April 2009 IEEE WoWMoM 2009 http://www.ics.forth.gr/wowmom09/index.html is soliciting = original and previously unpublished research papers from industry researche= rs and professionals for a one-day Industry Session. Specific topics of int= erest include, but are not limited to: * Conversational Mobile Multimedia * (Personal) Mobile Broadcast Delivery and Applications * Mobile broadcast implementation issues (including, but not limited to, DV= B-H, MBMS, DMB, ATSC-M/H, MediaFLO, etc.) * Mobile P2P distribution of real-time Multimedia * Scalable Media architectures for mobile networks * Social Multimedia and co-creation * 3D Video modeling and applications * Context-based real-time media * Semantic description and scene context extraction of real-time media * Multimodal sensing and context. The Industry Session track is intended to specially highlight system experi= ences and proofs-of-concept in the areas above. Like regular papers, the In= dustry Session papers will undergo a review process by an International TPC= and will appear in the conference proceedings. However, the selection criteria for Industry Session papers are slightly di= fferent. In particular, papers should describe applications, prototypes or = experiences of clear industry relevance. Papers with narrow algorithmic foc= us or only high-level design details are discouraged. A key goal of this se= ssion is to present systems-oriented research that exposes the academic and= research communities to real-life issues and problems being faced in indus= try. Accordingly, papers will be evaluated, less on the novelty of specific= algorithmic content, but by the originality and general applicability of i= nsights that can be inferred from the authors' implementation experience. Papers must be formatted according to the guidelines given in http://www.ic= s.forth.gr/wowmom09/papersubmission.html and submitted by the authors to BO= TH the Industry Chairs by midnight US Pacific Time of 15 March 2009. Industry Chairs: Igor D.D. Curcio (Nokia Research Center), E-mail: igor.curcio AT nokia.com Kumar Ramaswamy (Thomson), E-mail: kumar.ramaswamy AT thomson.net --_000_08485F91AF534543877F9738F761DCFE27E902D05ANOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
10th IEEE= =20 International Symposium on a World of Wireless, Mobile and Multimedia=20 Networks
15-19 Jun= e 2009,=20 Kos, Greece
 

Call For Papers -- Industrial= =20 Track

http= ://www.ics.forth.gr/wowmom09/callforindustrialpapers.html=

 

Important dates:

* Paper submission deadline: 15 Marc= h=20 2009 (HARD DEADLINE)

* Acceptance notification: 29 March 2009

* Camera-ready copy deadline: 11 April=20 2009

 

IEEE WoWMoM 2009 http://www.ics.forth.gr/wowmom09/index.html i= s=20 soliciting original and previously unpublished research papers from industr= y=20 researchers and professionals for a one-day Industry Session. Specific topi= cs of=20 interest include, but are not limited to:

* Conversational Mobile Multimedia

* (Personal) Mobile Broadcast Delivery and=20 Applications

* Mobile broadcast implementation issues (in= cluding,=20 but not limited to, DVB-H, MBMS, DMB, ATSC-M/H, MediaFLO, etc.)

* Mobile P2P distribution of real-time=20 Multimedia

* Scalable Media architectures for mobile=20 networks

* Social Multimedia and co-creation

* 3D Video modeling and applications<= /P>

* Context-based real-time media

* Semantic description and scene context ext= raction=20 of real-time media

* Multimodal sensing and context.

 

The Industry Session track is intended to sp= ecially=20 highlight system experiences and proofs-of-concept in the areas above. Like= =20 regular papers, the Industry Session papers will undergo a review process b= y an=20 International TPC and will appear in the conference proceedings.

However, the selection criteria for Industry= Session=20 papers are slightly different. In particular, papers should describe=20 applications, prototypes or experiences of clear industry relevance. Papers= with=20 narrow algorithmic focus or only high-level design details are discouraged.= A=20 key goal of this session is to present systems-oriented research that expos= es=20 the academic and research communities to real-life issues and problems bein= g=20 faced in industry. Accordingly, papers will be evaluated, less on the novel= ty of=20 specific algorithmic content, but by the originality and general applicabil= ity=20 of insights that can be inferred from the authors' implementation=20 experience.

Papers must be formatted according to the gu= idelines=20 given in http://www.ics.forth.gr/wowmom09/papersubmission.html and submitted by the authors to BOTH the Industry Ch= airs=20 by midnight US Pacific Time of 15 March 2009.

 

Industry Chairs:

Igor D.D. Curcio (Nokia Research Center), E-= mail:=20 igor.curcio AT nokia.com

Kumar Ramaswamy (Thomson), E-mail:=20 kumar.ramaswamy AT=20 thomson.net

--_000_08485F91AF534543877F9738F761DCFE27E902D05ANOKEUMSG01mgd_-- From jf.mule@cablelabs.com Fri Feb 27 08:31:36 2009 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 EC77828C25A for ; Fri, 27 Feb 2009 08:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 HfeWHOqARm53 for ; Fri, 27 Feb 2009 08:31:36 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 14CF528C22E for ; Fri, 27 Feb 2009 08:31:36 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n1RGVsQ7017305; Fri, 27 Feb 2009 09:31:55 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 27 Feb 2009 09:31:55 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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, 27 Feb 2009 09:31:34 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601A1A352@srvxchg3.cablelabs.com> In-Reply-To: <499DC7B1.5030002@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-connectivity-precon-05.txt Thread-Index: AcmS1KukqlXDrXbHTryuXPhxS7BhJwGDT3Ag References: <9AAEDF491EF7CA48AB587781B8F5D7C60150BB53@srvxchg3.cablelabs.com> <49461C9D.6000508@ericsson.com> <499DC7B1.5030002@ericsson.com> From: "Jean-Francois Mule" To: "Gonzalo Camarillo" X-Approved: ondar Cc: fandreas@cisco.com, oran@cisco.com, Joerg Ott , dwing@cisco.com, mmusic@ietf.org Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-connectivity-precon-05.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: Fri, 27 Feb 2009 16:31:37 -0000 Gonzalo, First, as indicated privately to you, my apologies for the delay in getting to this. Reviewing the draft while doing the proto write-up, I have a few comments that need to be discussed. The main one is the use of the defunct RTP No-op mechanism in avt in several places in the document. Please read below and let me know if you think it is fair to update the document. If you think it would cause additional delays for no good reasons, I could be convinced to put some editorial changes in the proto write-up. Jean-Francois. 1. aBNF in Section 3.1 change=20 < precondition-type =3D "conn" | "qos" | token with > precondition-type =3D "conn" / "qos" / token 2. RTP No-op to be changed to RTP keepalive I believe RTP No-op is not progressing in AVT, yet this ID points to it in several places. Consider referencing draft-ietf-avt-app-rtp-keepalive-05.txt instead. RTP No-op appears in sections 3.2, 4 an entire paragraph on page 8 in section 4.2, in section 6 and rtpmap attribute page 12 (as well as the informative ref. section). This is what makes me uncomfortable to request publication without an ID update. It is mostly informative but it appears in several places in the document. 3. Section 4 and the informative text Paragraph 1 says: " The following rules guide which connectivity verification mechanism to use:" All of this text is informative. Should those rules be at least RECOMMENDED (SHOULD?)?=20 4. References: stun-bis in now RFC 5389 I-D.ietf-avt-rtp-no-op per the above comments. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Thursday, February 19, 2009 1:57 PM > To: Jean-Francois Mule; Joerg Ott > Cc: fandreas@cisco.com; dwing@cisco.com; oran@cisco.com; > mmusic@ietf.org > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-connectivity-precon- > 05.txt >=20 > Jean Francois, Joerg, >=20 > when do you think you will get around to requesting the publication > of > the draft below? >=20 > Thanks, >=20 > Gonzalo >=20 > -------- Original Message -------- > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-connectivity-precon- > 05.txt > Date: Mon, 15 Dec 2008 11:00:13 +0200 > From: Gonzalo Camarillo > To: Jean-Francois Mule > CC: fandreas@cisco.com, dwing@cisco.com, oran@cisco.com, > mmusic@ietf.org, Joerg Ott >=20 > Hi Jean Francois, >=20 > we have not received any further comments on the draft. So, you can > go > ahead request its publication as soon as you get some time to the > PROTO > writeup. >=20 > Thanks, >=20 > Gonzalo >=20 > -------- Original Message -------- > Subject: WGLC: draft-ietf-mmusic-connectivity-precon-05.txt > Date: Fri, 24 Oct 2008 05:49:37 -0600 > From: Jean-Francois Mule > To: > CC: Joerg Ott , Gonzalo Camarillo > , , > , >=20 >=20 > This is to announce the Working Group Last Call on > draft-ietf-mmusic-connectivity-precon-05. >=20 > The WGLC starts today and will end on November 7 2008. Please > send > your comments and any open issues to the MMUSIC list and the > authors. >=20 > Thank you in advance for taking the time to read this document and > provide your review comments. >=20 > Jean-Francois. > jfm@cablelabs.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20