From exim@www1.ietf.org Sat Jan 3 00:21:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07473 for ; Sat, 3 Jan 2004 00:21:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AceDN-0003de-Bi for mmusic-archive@odin.ietf.org; Sat, 03 Jan 2004 00:20:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i035KjWr013986 for mmusic-archive@odin.ietf.org; Sat, 3 Jan 2004 00:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AceDN-0003dV-7w for mmusic-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 00:20:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07444 for ; Sat, 3 Jan 2004 00:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AceDK-0000z9-00 for mmusic-web-archive@ietf.org; Sat, 03 Jan 2004 00:20:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AceCi-0000rN-00 for mmusic-web-archive@ietf.org; Sat, 03 Jan 2004 00:20:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AceA3-0000hy-00 for mmusic-web-archive@ietf.org; Sat, 03 Jan 2004 00:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ace9k-0003Rt-Us; Sat, 03 Jan 2004 00:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ace8q-0003Qn-6G for mmusic@optimus.ietf.org; Sat, 03 Jan 2004 00:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07262 for ; Sat, 3 Jan 2004 00:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ace8d-0000f0-00 for mmusic@ietf.org; Sat, 03 Jan 2004 00:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ace4a-0000Tl-00 for mmusic@ietf.org; Sat, 03 Jan 2004 00:11:41 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1Ace0F-0000Kz-00 for mmusic@ietf.org; Sat, 03 Jan 2004 00:07:11 -0500 Date: Fri, 02 Jan 2004 21:00:17 -0800 From: rtspspec-bugs-request@lists.sourceforge.net Message-Id: To: mmusic@ietf.org Reply-to: mmusic@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_goobox-28713-1073106387-0001-2" Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #112 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_goobox-28713-1073106387-0001-2 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Comment: The following content can be customized provided that: Comment: 1) These MIME headers are preserved (you may change the charset Comment: or drop format=flowed). Comment: 2) This content is manually quoted-printable encoded, it MUST NOT Comment: contain 8-bit text. Comment: 'goobox' below is replaced by server name. Content-Transfer-Encoding: quoted-printable CORRUPTED MESSAGE This is the Courier Mail Server 0.36.1 on goobox. I received the following message for delivery to your address. Unfortunately, this message apparently fails to comply with Internet mail formatting protocols, and I can only deliver mail which has been properly formatted in accordance with Internet standards. Instead of rejecting that message as undeliverable, I saved it as the following attachment, which you can open with any editor or word processor. Please notify the original sender that their message was not properly formatted by their mail software. The specific mail protocol error is as follows: ----------------------------------------------------------------------------- The following message contains 8-bit content, but does not have the required MIME headers for 8-bit data transport. See for more information. ----------------------------------------------------------------------------- --=_goobox-28713-1073106387-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="message.txt" X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.36.1 Content-Transfer-Encoding: quoted-printable Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 02 Jan 2004 21:05:52 -0800 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.23.140] by localhost with POP3 = (fetchmail-6.2.0) for robla@localhost (single-drop); Fri, 02 Jan 2004 21= :05:52 -0800 (PST) Received: from mail.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1= /SSLv3,168bits,DES-CBC3-SHA) by serpico.real.com with esmtp; Fri, 02 Jan= 2004 21:02:45 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=3Dsc8-sf-= list1.sourceforge.net) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:A= ES256-SHA:256) (Exim 4.30) id 1AcdvE-00013r-FU for robla@real.com; Fri, = 02 Jan 2004 21:02:00 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=3Dprojects.source= forge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.24) id 1Ac= dvB-0001by-Hj for robla@real.com; Fri, 02 Jan 2004 21:01:57 -0800 Date: Fri, 02 Jan 2004 21:00:17 -0800 From: rtspspec-bugs-request@lists.sourceforge.net Subject: Rtspspec-bugs digest, Vol 1 #112 - 1 msg X-Mailer: Mailman v2.0.9-sf.net MIME-version: 1.0 Content-type: text/plain Old-To: rtspspec-bugs@lists.sourceforge.net Sender: rtspspec-bugs-admin@lists.sourceforge.net Errors-To: rtspspec-bugs-admin@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Score: 1.3 (+) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on = serpico.real.com X-Spam-Status: No, hits=3D-4.7 required=3D5.0 tests=3DBAYES_00,NO_REAL_N= AME autolearn=3Dno version=3D2.61 X-Spam-Level: To: mmusic@ietf.org Reply-to: mmusic@ietf.org This is an automatic digest of bugs submitted and changed on the RTSP bu= g tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rts= pspec-bugs digest" Today's Topics: 1. =3D?GB2312?B?wM/F89PR1Nq0y7j4xPqw3cTqo6E=3D?=3D (=3D?GB2312?B?uuPL= 2bTv?=3D) --__--__-- Message: 1 From: =3D?GB2312?B?uuPL2bTv?=3D To: rtspspec-bugs@lists.sourceforge.net Reply-To: =BA=E3=CB=D9=B4=EF Date: Fri, 2 Jan 2004 16:47:39 +0800 Subject: [rtspspec-bugs] =3D?GB2312?B?wM/F89PR1Nq0y7j4xPqw3cTqo6E=3D?=3D =D7=F0=BE=B4=B5=C4=C0=CF=BF=CD=BB=A7=A3=BA =A1=A1=A1=A1=C4=FA=BA=C3=A3=A1 =A1=A1=A1=A1=CB=EA=CE=B4=BD=AB=D6=C1=A3=AC=CC=D8=D4=DA=B4=CB=B8=F8=C4=FA= =B0=DD=B8=F6=D4=E7=C4=EA=A3=AC=D7=A3=C4=FA=D0=C2=C4=EA=BF=EC=C0=D6=A1=A2= =BA=CF=BC=D2=CD=C5=D4=B2=A1=A2=CD=F2=CA=C2=C8=E7=D2=E2=A3=A1 =A1=A1=A1=A1 =A1=A1=A1=A1=BA=E3=CB=D9=B4=EF=C4=DC=D3=D0=BD=F1=CC=EC=C0=EB=B2=BB=BF=AA= =C4=FA=B5=C4=D6=A7=B3=D6=D3=EB=BA=F1=B0=AE=A3=AC=CE=AA=BB=D8=B1=A8=C0=CF= =BF=CD=BB=A7=CE=D2=C3=C7=D3=EB=A1=A1DELL=B5=E7=C4=D4=BA=CF=D7=F7=A3=AC=D1= =A1=D3=C3=B6=A5 =BC=B6=C6=B7=C5=C6=B7=FE=CE=F1=C6=F7=A3=AC=CC=D8=B1=F0=B7=EE=CB=CD=A3=A1 =B4=D32003=C4=EA01=D4=C201=C8=D5---2004=C4=EA2=D4=C21=C8=D5=D4=DA=CE= =D2=CB=BE=C9=EA=C7=EBDELL=B7=FE=CE=F1=C6=F7=BF=D5=BC=E4=B5=C4=D3=C5=BB=DD= =C8=E7=CF=C2=A3=BA A=A1=A2400M=BF=D5=BC=E4=A3=A8200M=A1=A1WEB=A3=AC=D6=A7=B3=D6ASP=A1=A2CG= I=A1=A2ACCESS=A1=A2=C2=DB=CC=B3=A3=A9 + =CB=CD1=B8=F6100M=A1=A1MAIL=A1=A1= =CC=D8=BC=DB150=D4=AA=A3=BB B=A1=A2600M=BF=D5=BC=E4=A3=A8300M=A1=A1WEB=A3=AC=D6=A7=B3=D6ASP=A1=A2CG= I=A1=A2ACCESS=A1=A2=C2=DB=CC=B3=A3=A9 + =CB=CD1=B8=F6100M=A1=A1MAIL=A1=A1= =CC=D8=BC=DB200=D4=AA=A3=BB C=A1=A2800M=BF=D5=BC=E4=A3=A8400M=A1=A1WEB=A3=AC=D6=A7=B3=D6ASP=A1=A2CG= I=A1=A2ACCESS=A1=A2=C2=DB=CC=B3=A3=A9 + =CB=CD1=B8=F6100M=A1=A1MAIL=A1=A1= =CC=D8=BC=DB300=D4=AA=A3=BB =CC=D8=BC=DB=BF=D5=BC=E4=BC=D3=A1=A160=D4=AA=CB=CD=B9=FA=BC=CA=B6=A5=BC=B6= =D3=F2=C3=FB=BC=D3=A3=AC=BC=D3=A1=A1200=D4=AA=CB=CD=B9=FA=C4=DA=D3=F2=C3= =FB=A3=BB=C1=ED=CD=F8=D5=BE=CD=C6=B9=E3=B4=F2=A1=A18.5=D5=DB=D3=C5=BB=DD= =A1=A3 =A1=A1=A1=A1=B3=CF=D0=C5=CE=AA=B1=BE=A3=AC=CE=D2=C3=C7=B3=D0=C5=B5=A1=A1= 24=D0=A1=CA=B1=CE=AA=C4=FA=B7=FE=CE=F1=A3=AC=CD=AC=CA=B1=D6=A7=B3=D6QQ24= =D0=A1=CA=B1=D4=DA=CF=DF=D7=C9=D1=AF=A3=A1 =A1=A1=A1=A1=CD=AC=CA=B1=D2=B2=BB=B6=D3=AD=C4=FA=BC=D3=C8=EB=CE=D2=C3=C7= =B4=FA=C0=ED=C9=CC=D0=D0=C1=D0=C0=B4=A3=AC=CE=D2=C3=C7=BD=AB=B8=F8=C4=FA= =B8=FC=BC=D3=D3=C5=BB=DD=B5=C4=B7=FE=CE=F1=A3=A1 24=D0=A1=CA=B1=C8=C8=CF=DF=A3=BA0592-- 8667174 / 8919334 / 8375020=A1=A1= /=A1=A18345012 =A1=A1=A1=A1=A1=A1=A1=A1=B4=AB=D5=E6=A3=BA0592--6026652 =A1=A1=A1=A1 =D3=CA=BC=FE=A3=BA dns88@tom.com QQ=D4=DA=CF=DF=A3=BA 40327558 / 33925614 =D7=A3=C4=FA=BA=C3=D4=CB=CC=EC=CC=EC=D3=D0=A1=A2=D0=D2=D4=CB=B3=A3=B0=E9= =CB=E6=A1=A2=BA=EF=C4=EA=CD=F2=CA=C2=C8=E7=D2=E2! =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=BA=E3=CB=D9=B4=EF=CD=F8=C2=E7 *****=B4=CB=D3=CA=BC=FE=CE=AA=C9=CC=D2=B5=D0=C5=BA=AF=A3=AC=C8=E7=B9=FB=B8= =F8=C4=FA=D4=EC=B3=C9=B2=BB=B1=E3=C7=EB=D4=AD=C1=C2=A3=AC=D0=BB=D0=BB=A3= =A1 This mail is a business letter .If you are uninterested in this ,plea= se delete it ; If you do not hope to receive this mail again ,please go to dns88@tom.co= m , fill ni your mail address ,and we will filter it out of our mail list! =A1= =A1 Thank your! =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 ********************************************** End of Rtspspec-bugs Digest --=_goobox-28713-1073106387-0001-2-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 5 12:04:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24763 for ; Mon, 5 Jan 2004 12:04:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY8p-0003aX-UK for mmusic-archive@odin.ietf.org; Mon, 05 Jan 2004 12:03:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05H3lur013792 for mmusic-archive@odin.ietf.org; Mon, 5 Jan 2004 12:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY8p-0003aN-On for mmusic-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 12:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24751 for ; Mon, 5 Jan 2004 12:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdY8j-0003ZH-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 12:03:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdY4Z-0003Td-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 11:59:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdY3G-0003QA-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 11:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY3F-00038m-LX; Mon, 05 Jan 2004 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY2c-00037k-Gi for mmusic@optimus.ietf.org; Mon, 05 Jan 2004 11:57:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24619 for ; Mon, 5 Jan 2004 11:57:19 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdY2b-0003Oq-00 for mmusic@ietf.org; Mon, 05 Jan 2004 11:57:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdY0j-0003Ln-00 for mmusic@ietf.org; Mon, 05 Jan 2004 11:55:26 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AdXzm-0003IO-00 for mmusic@ietf.org; Mon, 05 Jan 2004 11:54:26 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i05GsP403051 for ; Mon, 5 Jan 2004 18:54:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 Jan 2004 18:54:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 18:54:24 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 18:54:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps Date: Mon, 5 Jan 2004 18:54:23 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps Thread-Index: AcPFbaUGjb7jm+0US2S7Xk1xLHGblwL8s4/gAJMGfkA= To: , Cc: X-OriginalArrivalTime: 05 Jan 2004 16:54:24.0093 (UTC) FILETIME=[926C90D0:01C3D3AC] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Stig & Sami Thanks for the ideas. I'm thinking along the same lines as Sami, with = the addition that it makes some sense to seperate the initial = "announement channel discovery /boot-strapping" from the announcement = protocol (i.e. make it an assumption). So a seperate specification would = be needed to cover just this. For the "get the details from a web page" option no additional spec is = really needed (I guess a FLUTE URL is an option). For the simple = "register me with IANA" option, it'd be a very small (unecesary?) spec, = with whatever SSM and IPv6 complications the authors dare to tackle. = Etc, etc. Any thoughts? Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 5 12:04:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24780 for ; Mon, 5 Jan 2004 12:04:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY8t-0003au-FU for mmusic-archive@odin.ietf.org; Mon, 05 Jan 2004 12:03:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05H3pGJ013810 for mmusic-archive@odin.ietf.org; Mon, 5 Jan 2004 12:03:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY8t-0003af-CE for mmusic-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 12:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24756 for ; Mon, 5 Jan 2004 12:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdY8n-0003ZI-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 12:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdY4Z-0003Tl-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 11:59:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdY3G-0003QB-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 11:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY3F-00038e-8W; Mon, 05 Jan 2004 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdY2b-00037e-9y for mmusic@optimus.ietf.org; Mon, 05 Jan 2004 11:57:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24612 for ; Mon, 5 Jan 2004 11:57:18 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdY2Z-0003Od-00 for mmusic@ietf.org; Mon, 05 Jan 2004 11:57:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdY0h-0003LP-00 for mmusic@ietf.org; Mon, 05 Jan 2004 11:55:24 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AdXzP-0003IH-00 for mmusic@ietf.org; Mon, 05 Jan 2004 11:54:03 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i05Gs2622767 for ; Mon, 5 Jan 2004 18:54:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 Jan 2004 18:54:02 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 18:54:01 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe024.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 18:54:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Apps Date: Mon, 5 Jan 2004 18:54:01 +0200 Message-ID: Thread-Topic: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Apps Thread-Index: AcPFS5WyXZaVJxqYSemqmEHSj9tlCQME8egQAJNGpxA= To: , Cc: X-OriginalArrivalTime: 05 Jan 2004 16:54:01.0904 (UTC) FILETIME=[8532CB00:01C3D3AC] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Philippe & Sami > > Secondly could you explain if/why there is a specific need for a > > "joint" work > > between program guides and their mulitcast distribution ? The IMG philosphy is to keep these orthogonal. i.e. the multicast (and = unicast) delivery protocol should be distinct from the application = metadata (we are not dealing with the intricacies of the latter in = MMUSIC). One aspect of delivery which is important to metadata (and many = other data) is consistency. For this reason a "metadata envelope" = decsribing the bare minimum to maintain and expire metadata is under = work. Currently the idea is to seperate multicast delivery prtocol and = metadata envelope (i.e. seperate specificatons) so the same envelope can = be used regarless of the underlying multicats distribution methods. = Other ideas and opinions are very welcome! Happy New Year, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 5 12:26:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25401 for ; Mon, 5 Jan 2004 12:26:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYU3-0004jH-4f for mmusic-archive@odin.ietf.org; Mon, 05 Jan 2004 12:25:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05HPhff018173 for mmusic-archive@odin.ietf.org; Mon, 5 Jan 2004 12:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYU3-0004j2-1M for mmusic-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 12:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25381 for ; Mon, 5 Jan 2004 12:25:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdYTr-0004Hd-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 12:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdYP8-00047g-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 12:20:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdYL0-0003y7-00 for mmusic-web-archive@ietf.org; Mon, 05 Jan 2004 12:16:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYKf-0004QM-JL; Mon, 05 Jan 2004 12:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYKJ-0004PP-PN for mmusic@optimus.ietf.org; Mon, 05 Jan 2004 12:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25048 for ; Mon, 5 Jan 2004 12:15:36 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdYKD-0003xd-00 for mmusic@ietf.org; Mon, 05 Jan 2004 12:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdYGw-0003pA-00 for mmusic@ietf.org; Mon, 05 Jan 2004 12:12:11 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AdYDH-0003i7-00 for mmusic@ietf.org; Mon, 05 Jan 2004 12:08:23 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id D79636A077; Mon, 5 Jan 2004 18:07:52 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 4E04619C46; Mon, 5 Jan 2004 18:07:52 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id D51AD19C45; Mon, 5 Jan 2004 18:07:51 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA29218; Mon, 5 Jan 2004 18:07:51 +0100 (MET) Subject: RE: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Apps To: Rod.Walsh@nokia.com Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 5 Jan 2004 18:04:17 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 05/01/2004 18:09:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi Rod, my point was: there maybe reasons to adapt a format to the transport (e.g. RTP...) but in the case of *reliable* multicast I dont see any need for a difference with HTTP? then this consistency issue is purely a matter of format , so I understand the subject does not include/relate to transport except that you want reliable transport for this metadata format, right ? regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: cc: Subject: RE: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Rod.Walsh@nokia.com Apps Sent by: Classification: mmusic-admin@ietf.org 05/01/2004 17:54 Hi Philippe & Sami > > Secondly could you explain if/why there is a specific need for a > > "joint" work > > between program guides and their mulitcast distribution ? The IMG philosphy is to keep these orthogonal. i.e. the multicast (and unicast) delivery protocol should be distinct from the application metadata (we are not dealing with the intricacies of the latter in MMUSIC). One aspect of delivery which is important to metadata (and many other data) is consistency. For this reason a "metadata envelope" decsribing the bare minimum to maintain and expire metadata is under work. Currently the idea is to seperate multicast delivery prtocol and metadata envelope (i.e. seperate specificatons) so the same envelope can be used regarless of the underlying multicats distribution methods. Other ideas and opinions are very welcome! Happy New Year, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 7 03:12:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27112 for ; Wed, 7 Jan 2004 03:12:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae8nJ-0005R2-Tz for mmusic-archive@odin.ietf.org; Wed, 07 Jan 2004 03:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i078C1Mo020891 for mmusic-archive@odin.ietf.org; Wed, 7 Jan 2004 03:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae8nJ-0005Qs-Ol for mmusic-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 03:12:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27103 for ; Wed, 7 Jan 2004 03:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae8nH-0001H2-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 03:11:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae8lS-0001Dc-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 03:10:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae8kj-00019U-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 03:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae8kb-0005CN-Rd; Wed, 07 Jan 2004 03:09:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae8jj-00054I-OO for mmusic@optimus.ietf.org; Wed, 07 Jan 2004 03:08:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26988 for ; Wed, 7 Jan 2004 03:08:16 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae8jf-00018B-00 for mmusic@ietf.org; Wed, 07 Jan 2004 03:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae8hl-00013P-00 for mmusic@ietf.org; Wed, 07 Jan 2004 03:06:18 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ae8h8-0000yW-00 for mmusic@ietf.org; Wed, 07 Jan 2004 03:05:38 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0785c610934 for ; Wed, 7 Jan 2004 10:05:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 10:05:37 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 10:05:36 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 10:05:35 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 10:05:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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, 7 Jan 2004 10:05:33 +0200 Message-ID: Thread-Topic: IMG Reqs & FW v01 Internet-drafts: review please! Thread-Index: AcPGP+7Dh3ugFWP1SBW31OxEdtjb6gOqfvJQ To: Cc: , , , X-OriginalArrivalTime: 07 Jan 2004 08:05:34.0543 (UTC) FILETIME=[06F6F5F0:01C3D4F5] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: IMG Reqs & FW v01 Internet-drafts: review please! Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Jean-Pierre HAPPY NEW YEAR!!! I'm looking forward to the TVA input - please do it in any way which is = easiest and fastest. The cross-organizational work practices are = unimportant: the content is and there's enough of us with a foot in both = broadcast and Internet worlds to bridge the gap. As Joerg stated, wider input and deployment for IMGs is only a good = think. (Alough I like to think I, and some others in Nokia, have some = expertise in broadcast too - if that's not being too immodest :) Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 7 06:08:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02886 for ; Wed, 7 Jan 2004 06:08:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBXz-0004jn-5d for mmusic-archive@odin.ietf.org; Wed, 07 Jan 2004 06:08:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07B8Nxs018205 for mmusic-archive@odin.ietf.org; Wed, 7 Jan 2004 06:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBXz-0004jY-21 for mmusic-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 06:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02860 for ; Wed, 7 Jan 2004 06:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeBXv-0001ZM-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 06:08:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeBVx-0001So-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 06:06:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeBUo-0001My-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 06:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBUn-0003kn-KQ; Wed, 07 Jan 2004 06:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBTp-0003jM-3X for mmusic@optimus.ietf.org; Wed, 07 Jan 2004 06:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02719 for ; Wed, 7 Jan 2004 06:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeBTl-0001IW-00 for mmusic@ietf.org; Wed, 07 Jan 2004 06:04:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeBS9-0001EV-00 for mmusic@ietf.org; Wed, 07 Jan 2004 06:02:22 -0500 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx with esmtp (Exim 4.12) id 1AeBRb-00017s-00 for mmusic@ietf.org; Wed, 07 Jan 2004 06:01:48 -0500 Received: from oleane ([194.206.151.59]) by smtp6.clb.oleane.net with SMTP id i07B1IO0028258 for ; Wed, 7 Jan 2004 12:01:18 +0100 Message-ID: <025c01c3d50e$901ec560$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Wed, 7 Jan 2004 12:08:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0259_01C3D516.F1A7AB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [MMUSIC] WiFi Voice Conference - Paris Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0259_01C3D516.F1A7AB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The WiFi Voice Conference will stand in Paris next May 25 to 28, 2004. QoS, security, roaming, interoperability, architectures : distinguished = experts=20 and key players in the field will address these questions with detailed = and=20 technical explanations.=20 =20 More details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm ------=_NextPart_000_0259_01C3D516.F1A7AB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The WiFi Voice Conference will stand in Paris next = May 25 to=20 28, 2004.
QoS, security, roaming, interoperability, architectures :=20 distinguished experts
and key players in the field will address = these=20 questions with detailed and
technical explanations. =
 
More=20 details at:
http://www.upperside.fr/wifivoice04/wifivoice04intro.htm<= /A>
------=_NextPart_000_0259_01C3D516.F1A7AB00-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 7 17:02:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08101 for ; Wed, 7 Jan 2004 17:02:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLkn-0004Pl-50 for mmusic-archive@odin.ietf.org; Wed, 07 Jan 2004 17:02:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07M2HCn016968 for mmusic-archive@odin.ietf.org; Wed, 7 Jan 2004 17:02:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLkn-0004PY-12 for mmusic-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 17:02:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07847 for ; Wed, 7 Jan 2004 17:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLkk-0002is-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 17:02:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLhX-0001vr-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 16:58:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeLdz-00015e-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 16:55:16 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeLK7-0002jV-IX for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 16:34:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLJQ-0002oQ-SV; Wed, 07 Jan 2004 16:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeL5w-0002Oq-Iq for mmusic@optimus.ietf.org; Wed, 07 Jan 2004 16:20:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02762 for ; Wed, 7 Jan 2004 16:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeL5l-0004VC-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeL0R-0004ND-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:14:24 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AeKzJ-0004Id-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:13:14 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i07LCVVO018790; Wed, 7 Jan 2004 13:12:33 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB81117; Wed, 7 Jan 2004 16:12:30 -0500 (EST) Message-ID: <3FFC763E.3080600@cisco.com> Date: Wed, 07 Jan 2004 16:12:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen CC: "Kumar, Rajesh" , Kevin Boyle , Stephen Casner , Colin Perkins , mmusic@ietf.org, "Mostafa, Mohamed" , "Abdelhamid, Hisham" , mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I recently encountered an interesting case relevant to this while making up an example for MSRP. In MSRP the port number is not used, except for the distinction between a zero and non-zero value. There is a requirement that some random non-zero value be inserted and then ignored. If there are multiple MSRP media sessions in the same SDP body, must they have differing port numbers? Paul Flemming Andreasen wrote: > > "Kumar, Rajesh" wrote: > > >>AVT members, >> >>There was some confusion on this issue in the recent TIA TR.30.1 meeting >>in Orlando, Florida. >> >>Could someone officially confirm or deny whether multiple "m=" lines >>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) >>cannot be assigned the same port number? > > > The consensus of this discussion is that is that they cannot (assuming they > use the same IP address). > > -- Flemming > > > >>If they can be assigned the >>same port number, then it is possible to selectively associate RFC 2733 >>FEC with some payload types such as those that carry voice band data. >>Otherwise, there is a hole in SDP that does not permit selective, >>payload-specific declaration of FEC. I am aware of the fact that in RFC >>2733 the use of and level of FEC is a transmitter prerogative and that a >>transmitter may choose to selectively utilize FEC based on payload type >>transmitted. >> >>Thanks, >> >>Rajesh >> >> >>>-----Original Message----- >>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>Sent: Friday, December 12, 2003 4:21 AM >>>To: Kevin Boyle >>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; >> >>Mostafa, Mohamed; >> >>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>>Kevin Boyle wrote: >>> >>> >>>> >>>>All, >>>> >>>>Looking back at this email stream, one question remains outstanding >>> >>in >> >>>>my mind: >>>> >>>>What if the two m= lines have the SAME media type? For instance: >>>> >>>>m=audio 49232 RTP/AVP 18 >>>>m=image 49233 UDPTL t38 >>>>m=audio 49232 RTP/AVP 100 >>>>a=rtpmap:100 PCMU/8000 >>>>a=gpmd:100 vbd=yes >>>> >>>>For some of the SDP-based protocols, the order of appearance is >>> >>vital >> >>>>because it announces preference. >>> >>>Only for the media formats within a given "m=" line. Multiple "m=" >> >>lines >> >>>indicates a set of simultaneous media streams; not alternatives. >>> >>> >>> >>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, >>>>while utilizing G.729 for voice. As far as I can tell, this >>> >>construct >> >>>>is allowed, since both m lines using the same port number use a >>> >>media >> >>>>type of audio. >>>> >>>>Is my understanding correct? >>>> >>> >>>Not quite. Each "m=" line corresponds to a separate media stream. >> >>Also, >> >>>the consensus of this discussion has been that you are *not* allowed >> >>to >> >>>use the same port for different media lines, regardless of whether >> >>they >> >>>share the same top-level MIME type or not. >>> >>>-- Flemming >>> >>> >>>>Thanks, >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Stephen Casner [mailto:casner@acm.org] >>>>Sent: Friday, April 25, 2003 2:57 PM >>>>To: Rajesh Kumar >>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>paulej@cisco.com >>>> >>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>>Rajesh, >>>> >>>> >>>>>Is the use of multiple 'm=' lines with the same port number within >>>> >>>>an >>>> >>>>>SDP descriptor permitted? >>>> >>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so >>>>causes all of the payload formats listed on the m= lines to become >>>>part of a single RTP session (unless they are distinguished by some >>>>other aspect of addressing). Section 5.2 of the RTP spec addresses >>>>NOT multiplexing different media in the same RTP session. >>>> >>>> >>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>> >>are >> >>>>of >>>> >>>>>the same media type (e.g. audio, image, text etc.). >>>>> >>>>>Now consider the case in which two RTP media formats can use a >>>>>destination port but are registered under different MIME types. >>>> >>For >> >>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>> >>>>recourse >>>> >>>>>except to use multiple media lines with the same port number. For >>>> >>>>example: >>>> >>>>The "can use a destination port" is the tricky part. We may not >>>>agree. >>>> >>>> >>>>>m=audio 49232 RTP/AVP 0 >>>>>m=text 49232 RTP/AVP 100 >>>>>a=rtpmap:100 t140 >>>>> >>>>>My thought is that although this is unsual, it is not proscribed >>>> >>by >> >>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>> >>>>I believe this is proscribed by section 5.2 of the RTP spec because >>>>these two media should not be multiplexed in one RTP session. >>>> >>>>My bet is that the real example you are thinking about is fax or >>> >>modem >> >>>>over IP. We've been there before. >>>> >>>> -- Steve >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 7 17:03:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08143 for ; Wed, 7 Jan 2004 17:03:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLl3-0004RB-Kk for mmusic-archive@odin.ietf.org; Wed, 07 Jan 2004 17:02:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07M2Xbc017051 for mmusic-archive@odin.ietf.org; Wed, 7 Jan 2004 17:02:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLl3-0004Qw-Eo for mmusic-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 17:02:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07868 for ; Wed, 7 Jan 2004 17:02:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLkp-0002kH-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 17:02:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLhg-0001xP-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 16:59:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeLe0-0001GZ-00 for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 16:55:17 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeLK5-0002jW-BP for mmusic-web-archive@ietf.org; Wed, 07 Jan 2004 16:34:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLJR-0002oY-9o; Wed, 07 Jan 2004 16:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLCi-0002c8-Fq for mmusic@optimus.ietf.org; Wed, 07 Jan 2004 16:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02904 for ; Wed, 7 Jan 2004 16:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLCb-00056u-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:26:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeL6d-0004aq-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:20:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AeL3j-0004Pk-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:17:47 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i07LGcLG029949; Wed, 7 Jan 2004 16:16:41 -0500 (EST) Received: from PAULEJW2K1 (ssh-rtp-1.cisco.com [161.44.11.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AWB11707; Wed, 7 Jan 2004 13:16:36 -0800 (PST) Message-ID: <009701c3d563$40457c00$7f01a8c0@cisco.com> From: "Paul E. Jones" To: "Paul Kyzivat" , "Flemming Andreasen" Cc: "Kumar, Rajesh" , "Kevin Boyle" , "Stephen Casner" , "Colin Perkins" , , "Mostafa, Mohamed" , "Abdelhamid, Hisham" , References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> <3FFC763E.3080600@cisco.com> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Wed, 7 Jan 2004 16:14:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, While that sounds most unfortunate (I'd love to see an example if you have one), I think it would be exempt from this rule, because the port is just a dummy value. Paul ----- Original Message ----- From: "Paul Kyzivat" To: "Flemming Andreasen" Cc: "Kumar, Rajesh" ; "Kevin Boyle" ; "Stephen Casner" ; "Colin Perkins" ; ; "Mostafa, Mohamed" ; "Abdelhamid, Hisham" ; ; Sent: Wednesday, January 07, 2004 4:12 PM Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > I recently encountered an interesting case relevant to this while making > up an example for MSRP. > > In MSRP the port number is not used, except for the distinction between > a zero and non-zero value. There is a requirement that some random > non-zero value be inserted and then ignored. If there are multiple MSRP > media sessions in the same SDP body, must they have differing port numbers? > > Paul > > Flemming Andreasen wrote: > > > > "Kumar, Rajesh" wrote: > > > > > >>AVT members, > >> > >>There was some confusion on this issue in the recent TIA TR.30.1 meeting > >>in Orlando, Florida. > >> > >>Could someone officially confirm or deny whether multiple "m=" lines > >>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) > >>cannot be assigned the same port number? > > > > > > The consensus of this discussion is that is that they cannot (assuming they > > use the same IP address). > > > > -- Flemming > > > > > > > >>If they can be assigned the > >>same port number, then it is possible to selectively associate RFC 2733 > >>FEC with some payload types such as those that carry voice band data. > >>Otherwise, there is a hole in SDP that does not permit selective, > >>payload-specific declaration of FEC. I am aware of the fact that in RFC > >>2733 the use of and level of FEC is a transmitter prerogative and that a > >>transmitter may choose to selectively utilize FEC based on payload type > >>transmitted. > >> > >>Thanks, > >> > >>Rajesh > >> > >> > >>>-----Original Message----- > >>>From: Flemming Andreasen [mailto:fandreas@cisco.com] > >>>Sent: Friday, December 12, 2003 4:21 AM > >>>To: Kevin Boyle > >>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; > >> > >>Mostafa, Mohamed; > >> > >>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com > >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > >>> > >>> > >>> > >>>Kevin Boyle wrote: > >>> > >>> > >>>> > >>>>All, > >>>> > >>>>Looking back at this email stream, one question remains outstanding > >>> > >>in > >> > >>>>my mind: > >>>> > >>>>What if the two m= lines have the SAME media type? For instance: > >>>> > >>>>m=audio 49232 RTP/AVP 18 > >>>>m=image 49233 UDPTL t38 > >>>>m=audio 49232 RTP/AVP 100 > >>>>a=rtpmap:100 PCMU/8000 > >>>>a=gpmd:100 vbd=yes > >>>> > >>>>For some of the SDP-based protocols, the order of appearance is > >>> > >>vital > >> > >>>>because it announces preference. > >>> > >>>Only for the media formats within a given "m=" line. Multiple "m=" > >> > >>lines > >> > >>>indicates a set of simultaneous media streams; not alternatives. > >>> > >>> > >>> > >>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, > >>>>while utilizing G.729 for voice. As far as I can tell, this > >>> > >>construct > >> > >>>>is allowed, since both m lines using the same port number use a > >>> > >>media > >> > >>>>type of audio. > >>>> > >>>>Is my understanding correct? > >>>> > >>> > >>>Not quite. Each "m=" line corresponds to a separate media stream. > >> > >>Also, > >> > >>>the consensus of this discussion has been that you are *not* allowed > >> > >>to > >> > >>>use the same port for different media lines, regardless of whether > >> > >>they > >> > >>>share the same top-level MIME type or not. > >>> > >>>-- Flemming > >>> > >>> > >>>>Thanks, > >>>> > >>>>Kevin > >>>> > >>>>-----Original Message----- > >>>>From: Stephen Casner [mailto:casner@acm.org] > >>>>Sent: Friday, April 25, 2003 2:57 PM > >>>>To: Rajesh Kumar > >>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > >>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > >>>>paulej@cisco.com > >>>> > >>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > >>>> > >>>>Rajesh, > >>>> > >>>> > >>>>>Is the use of multiple 'm=' lines with the same port number within > >>>> > >>>>an > >>>> > >>>>>SDP descriptor permitted? > >>>> > >>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so > >>>>causes all of the payload formats listed on the m= lines to become > >>>>part of a single RTP session (unless they are distinguished by some > >>>>other aspect of addressing). Section 5.2 of the RTP spec addresses > >>>>NOT multiplexing different media in the same RTP session. > >>>> > >>>> > >>>>>In SDP, as it is defined, all the media formats on an 'm=' line > >>>> > >>are > >> > >>>>of > >>>> > >>>>>the same media type (e.g. audio, image, text etc.). > >>>>> > >>>>>Now consider the case in which two RTP media formats can use a > >>>>>destination port but are registered under different MIME types. > >>>> > >>For > >> > >>>>>example, text/t140 and audio/PCMU. In this case, there is no > >>>> > >>>>recourse > >>>> > >>>>>except to use multiple media lines with the same port number. For > >>>> > >>>>example: > >>>> > >>>>The "can use a destination port" is the tricky part. We may not > >>>>agree. > >>>> > >>>> > >>>>>m=audio 49232 RTP/AVP 0 > >>>>>m=text 49232 RTP/AVP 100 > >>>>>a=rtpmap:100 t140 > >>>>> > >>>>>My thought is that although this is unsual, it is not proscribed > >>>> > >>by > >> > >>>>>SDP syntax in RFC 2327 or in its latest internet draft. > >>>> > >>>>I believe this is proscribed by section 5.2 of the RTP spec because > >>>>these two media should not be multiplexed in one RTP session. > >>>> > >>>>My bet is that the real example you are thinking about is fax or > >>> > >>modem > >> > >>>>over IP. We've been there before. > >>>> > >>>> -- Steve > >>>> > >>>>_______________________________________________ > >>>>mmusic mailing list > >>>>mmusic@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jan 8 05:56:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16844 for ; Thu, 8 Jan 2004 05:56:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXpy-0008SE-2x for mmusic-archive@odin.ietf.org; Thu, 08 Jan 2004 05:56:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08AuQ2H032494 for mmusic-archive@odin.ietf.org; Thu, 8 Jan 2004 05:56:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXpx-0008S1-TA for mmusic-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 05:56:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16832 for ; Thu, 8 Jan 2004 05:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeXpu-0000p1-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 05:56:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeXo3-0000lq-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 05:54:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeXme-0000ie-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 05:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXmf-0008M5-Gg; Thu, 08 Jan 2004 05:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXmB-0008LJ-2l for mmusic@optimus.ietf.org; Thu, 08 Jan 2004 05:52:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16761 for ; Thu, 8 Jan 2004 05:52:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeXm7-0000hq-00 for mmusic@ietf.org; Thu, 08 Jan 2004 05:52:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeXkH-0000dw-00 for mmusic@ietf.org; Thu, 08 Jan 2004 05:50:35 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeXjr-0000Zp-00 for mmusic@ietf.org; Thu, 08 Jan 2004 05:50:07 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i08Ao8624591 for ; Thu, 8 Jan 2004 12:50:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 12:30:52 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jan 2004 12:30:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Thu, 8 Jan 2004 12:30:44 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> Thread-Topic: [MMUSIC] Re: Multiple 'm' lines with the same port number thread-index: AcPVZhSqudG3D+IoQluGau2O1iNt9QAa/3pg To: , , Cc: X-OriginalArrivalTime: 08 Jan 2004 10:30:45.0256 (UTC) FILETIME=[795E0880:01C3D5D2] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I would hate to see exceptions like these when building a generic SDP = parser with built it checks for compliancy. Why can't MSRP just follow that rule? Regards, Hisham > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > ext Paul E. Jones > Sent: 07.January.2004 23:15 > To: Paul Kyzivat; Flemming Andreasen > Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; > mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; > mgarakan@cisco.com > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >=20 >=20 > Paul, >=20 > While that sounds most unfortunate (I'd love to see an=20 > example if you have > one), I think it would be exempt from this rule, because the=20 > port is just a > dummy value. >=20 > Paul >=20 > ----- Original Message -----=20 > From: "Paul Kyzivat" > To: "Flemming Andreasen" > Cc: "Kumar, Rajesh" ; "Kevin Boyle" > ; "Stephen Casner" ; "Colin > Perkins" ; ; "Mostafa, Mohamed" > ; "Abdelhamid, Hisham" ; > ; > Sent: Wednesday, January 07, 2004 4:12 PM > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >=20 >=20 > > I recently encountered an interesting case relevant to this=20 > while making > > up an example for MSRP. > > > > In MSRP the port number is not used, except for the=20 > distinction between > > a zero and non-zero value. There is a requirement that some random > > non-zero value be inserted and then ignored. If there are=20 > multiple MSRP > > media sessions in the same SDP body, must they have differing port > numbers? > > > > Paul > > > > Flemming Andreasen wrote: > > > > > > "Kumar, Rajesh" wrote: > > > > > > > > >>AVT members, > > >> > > >>There was some confusion on this issue in the recent TIA=20 > TR.30.1 meeting > > >>in Orlando, Florida. > > >> > > >>Could someone officially confirm or deny whether multiple=20 > "m=3D" lines > > >>with the SAME media type (e.g. "audio") and protocol=20 > (e.g. RTP/AVP) > > >>cannot be assigned the same port number? > > > > > > > > > The consensus of this discussion is that is that they=20 > cannot (assuming > they > > > use the same IP address). > > > > > > -- Flemming > > > > > > > > > > > >>If they can be assigned the > > >>same port number, then it is possible to selectively=20 > associate RFC 2733 > > >>FEC with some payload types such as those that carry=20 > voice band data. > > >>Otherwise, there is a hole in SDP that does not permit selective, > > >>payload-specific declaration of FEC. I am aware of the=20 > fact that in RFC > > >>2733 the use of and level of FEC is a transmitter=20 > prerogative and that a > > >>transmitter may choose to selectively utilize FEC based=20 > on payload type > > >>transmitted. > > >> > > >>Thanks, > > >> > > >>Rajesh > > >> > > >> > > >>>-----Original Message----- > > >>>From: Flemming Andreasen [mailto:fandreas@cisco.com] > > >>>Sent: Friday, December 12, 2003 4:21 AM > > >>>To: Kevin Boyle > > >>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins;=20 > mmusic@ietf.org; > > >> > > >>Mostafa, Mohamed; > > >> > > >>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com > > >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the=20 > same port number > > >>> > > >>> > > >>> > > >>>Kevin Boyle wrote: > > >>> > > >>> > > >>>> > > >>>>All, > > >>>> > > >>>>Looking back at this email stream, one question remains=20 > outstanding > > >>> > > >>in > > >> > > >>>>my mind: > > >>>> > > >>>>What if the two m=3D lines have the SAME media type? For=20 > instance: > > >>>> > > >>>>m=3Daudio 49232 RTP/AVP 18 > > >>>>m=3Dimage 49233 UDPTL t38 > > >>>>m=3Daudio 49232 RTP/AVP 100 > > >>>>a=3Drtpmap:100 PCMU/8000 > > >>>>a=3Dgpmd:100 vbd=3Dyes > > >>>> > > >>>>For some of the SDP-based protocols, the order of appearance is > > >>> > > >>vital > > >> > > >>>>because it announces preference. > > >>> > > >>>Only for the media formats within a given "m=3D" line.=20 > Multiple "m=3D" > > >> > > >>lines > > >> > > >>>indicates a set of simultaneous media streams; not alternatives. > > >>> > > >>> > > >>> > > >>>>So, this shows preference for T.38 fax relay over PCMU=20 > VBD for fax, > > >>>>while utilizing G.729 for voice. As far as I can tell, this > > >>> > > >>construct > > >> > > >>>>is allowed, since both m lines using the same port number use a > > >>> > > >>media > > >> > > >>>>type of audio. > > >>>> > > >>>>Is my understanding correct? > > >>>> > > >>> > > >>>Not quite. Each "m=3D" line corresponds to a separate media = stream. > > >> > > >>Also, > > >> > > >>>the consensus of this discussion has been that you are=20 > *not* allowed > > >> > > >>to > > >> > > >>>use the same port for different media lines, regardless=20 > of whether > > >> > > >>they > > >> > > >>>share the same top-level MIME type or not. > > >>> > > >>>-- Flemming > > >>> > > >>> > > >>>>Thanks, > > >>>> > > >>>>Kevin > > >>>> > > >>>>-----Original Message----- > > >>>>From: Stephen Casner [mailto:casner@acm.org] > > >>>>Sent: Friday, April 25, 2003 2:57 PM > > >>>>To: Rajesh Kumar > > >>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > > >>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > > >>>>paulej@cisco.com > > >>>> > > >>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same=20 > port number > > >>>> > > >>>>Rajesh, > > >>>> > > >>>> > > >>>>>Is the use of multiple 'm=3D' lines with the same port=20 > number within > > >>>> > > >>>>an > > >>>> > > >>>>>SDP descriptor permitted? > > >>>> > > >>>>Presuming that the multiple m=3D lines are all RTP/AVP,=20 > then doing so > > >>>>causes all of the payload formats listed on the m=3D=20 > lines to become > > >>>>part of a single RTP session (unless they are=20 > distinguished by some > > >>>>other aspect of addressing). Section 5.2 of the RTP=20 > spec addresses > > >>>>NOT multiplexing different media in the same RTP session. > > >>>> > > >>>> > > >>>>>In SDP, as it is defined, all the media formats on an 'm=3D' = line > > >>>> > > >>are > > >> > > >>>>of > > >>>> > > >>>>>the same media type (e.g. audio, image, text etc.). > > >>>>> > > >>>>>Now consider the case in which two RTP media formats can use a > > >>>>>destination port but are registered under different MIME types. > > >>>> > > >>For > > >> > > >>>>>example, text/t140 and audio/PCMU. In this case, there is no > > >>>> > > >>>>recourse > > >>>> > > >>>>>except to use multiple media lines with the same port=20 > number. For > > >>>> > > >>>>example: > > >>>> > > >>>>The "can use a destination port" is the tricky part. We may not > > >>>>agree. > > >>>> > > >>>> > > >>>>>m=3Daudio 49232 RTP/AVP 0 > > >>>>>m=3Dtext 49232 RTP/AVP 100 > > >>>>>a=3Drtpmap:100 t140 > > >>>>> > > >>>>>My thought is that although this is unsual, it is not=20 > proscribed > > >>>> > > >>by > > >> > > >>>>>SDP syntax in RFC 2327 or in its latest internet draft. > > >>>> > > >>>>I believe this is proscribed by section 5.2 of the RTP=20 > spec because > > >>>>these two media should not be multiplexed in one RTP session. > > >>>> > > >>>>My bet is that the real example you are thinking about is fax or > > >>> > > >>modem > > >> > > >>>>over IP. We've been there before. > > >>>> > > >>>> -- Steve > > >>>> > > >>>>_______________________________________________ > > >>>>mmusic mailing list > > >>>>mmusic@ietf.org > > >>>>https://www1.ietf.org/mailman/listinfo/mmusic > > >>> > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jan 8 09:37:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24328 for ; Thu, 8 Jan 2004 09:37:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebHe-0002Fz-Pi for mmusic-archive@odin.ietf.org; Thu, 08 Jan 2004 09:37:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08EbE9U008669 for mmusic-archive@odin.ietf.org; Thu, 8 Jan 2004 09:37:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebHe-0002Fk-42 for mmusic-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 09:37:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24272 for ; Thu, 8 Jan 2004 09:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebHE-0005cb-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 09:36:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebCD-0005Rh-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 09:31:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeb84-0005FF-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 09:27:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeb7l-0001oH-JA; Thu, 08 Jan 2004 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeb7X-0001nt-Jl for mmusic@optimus.ietf.org; Thu, 08 Jan 2004 09:26:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24076 for ; Thu, 8 Jan 2004 09:26:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeb7Q-0005EP-00 for mmusic@ietf.org; Thu, 08 Jan 2004 09:26:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeb5A-00054V-00 for mmusic@ietf.org; Thu, 08 Jan 2004 09:24:21 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeazy-0004ns-00; Thu, 08 Jan 2004 09:18:58 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08EHpGN011084; Thu, 8 Jan 2004 06:17:52 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFC21371; Thu, 8 Jan 2004 09:17:50 -0500 (EST) Message-ID: <3FFD668E.4030709@cisco.com> Date: Thu, 08 Jan 2004 09:17:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, I have an open mind about this right now. It seems to be a matter of picking your favorite poison, since neither alternative is ideal: - ensure that the ports used are unique even though they are ignored - change SDP - something that is not very popular. So far, aside from me there are two votes, one on each side. From the point of view of SIMPLE it is of course logistically simpler to leave SDP alone. Paul P.S. It seems that simple wasn't on the mailing list, so I have added it. hisham.khartabil@nokia.com wrote: > I would hate to see exceptions like these when building a generic SDP parser with built it checks for compliancy. > Why can't MSRP just follow that rule? > > Regards, > Hisham > > >>-----Original Message----- >>From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>ext Paul E. Jones >>Sent: 07.January.2004 23:15 >>To: Paul Kyzivat; Flemming Andreasen >>Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>mgarakan@cisco.com >>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >> >> >>Paul, >> >>While that sounds most unfortunate (I'd love to see an >>example if you have >>one), I think it would be exempt from this rule, because the >>port is just a >>dummy value. >> >>Paul >> >>----- Original Message ----- >>From: "Paul Kyzivat" >>To: "Flemming Andreasen" >>Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>; "Stephen Casner" ; "Colin >>Perkins" ; ; "Mostafa, Mohamed" >>; "Abdelhamid, Hisham" ; >>; >>Sent: Wednesday, January 07, 2004 4:12 PM >>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >> >> >> >>>I recently encountered an interesting case relevant to this >> >>while making >> >>>up an example for MSRP. >>> >>>In MSRP the port number is not used, except for the >> >>distinction between >> >>>a zero and non-zero value. There is a requirement that some random >>>non-zero value be inserted and then ignored. If there are >> >>multiple MSRP >> >>>media sessions in the same SDP body, must they have differing port >> >>numbers? >> >>>Paul >>> >>>Flemming Andreasen wrote: >>> >>>>"Kumar, Rajesh" wrote: >>>> >>>> >>>> >>>>>AVT members, >>>>> >>>>>There was some confusion on this issue in the recent TIA >>>> >>TR.30.1 meeting >> >>>>>in Orlando, Florida. >>>>> >>>>>Could someone officially confirm or deny whether multiple >>>> >>"m=" lines >> >>>>>with the SAME media type (e.g. "audio") and protocol >>>> >>(e.g. RTP/AVP) >> >>>>>cannot be assigned the same port number? >>>> >>>> >>>>The consensus of this discussion is that is that they >>> >>cannot (assuming >>they >> >>>>use the same IP address). >>>> >>>>-- Flemming >>>> >>>> >>>> >>>> >>>>>If they can be assigned the >>>>>same port number, then it is possible to selectively >>>> >>associate RFC 2733 >> >>>>>FEC with some payload types such as those that carry >>>> >>voice band data. >> >>>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>>payload-specific declaration of FEC. I am aware of the >>>> >>fact that in RFC >> >>>>>2733 the use of and level of FEC is a transmitter >>>> >>prerogative and that a >> >>>>>transmitter may choose to selectively utilize FEC based >>>> >>on payload type >> >>>>>transmitted. >>>>> >>>>>Thanks, >>>>> >>>>>Rajesh >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>>To: Kevin Boyle >>>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>> >>mmusic@ietf.org; >> >>>>>Mostafa, Mohamed; >>>>> >>>>> >>>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>> >>same port number >> >>>>>> >>>>>> >>>>>>Kevin Boyle wrote: >>>>>> >>>>>> >>>>>> >>>>>>>All, >>>>>>> >>>>>>>Looking back at this email stream, one question remains >>>>>> >>outstanding >> >>>>>in >>>>> >>>>> >>>>>>>my mind: >>>>>>> >>>>>>>What if the two m= lines have the SAME media type? For >>>>>> >>instance: >> >>>>>>>m=audio 49232 RTP/AVP 18 >>>>>>>m=image 49233 UDPTL t38 >>>>>>>m=audio 49232 RTP/AVP 100 >>>>>>>a=rtpmap:100 PCMU/8000 >>>>>>>a=gpmd:100 vbd=yes >>>>>>> >>>>>>>For some of the SDP-based protocols, the order of appearance is >>>>>> >>>>>vital >>>>> >>>>> >>>>>>>because it announces preference. >>>>>> >>>>>>Only for the media formats within a given "m=" line. >>>>> >>Multiple "m=" >> >>>>>lines >>>>> >>>>> >>>>>>indicates a set of simultaneous media streams; not alternatives. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>So, this shows preference for T.38 fax relay over PCMU >>>>>> >>VBD for fax, >> >>>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>>> >>>>>construct >>>>> >>>>> >>>>>>>is allowed, since both m lines using the same port number use a >>>>>> >>>>>media >>>>> >>>>> >>>>>>>type of audio. >>>>>>> >>>>>>>Is my understanding correct? >>>>>>> >>>>>> >>>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>>> >>>>>Also, >>>>> >>>>> >>>>>>the consensus of this discussion has been that you are >>>>> >>*not* allowed >> >>>>>to >>>>> >>>>> >>>>>>use the same port for different media lines, regardless >>>>> >>of whether >> >>>>>they >>>>> >>>>> >>>>>>share the same top-level MIME type or not. >>>>>> >>>>>>-- Flemming >>>>>> >>>>>> >>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>>To: Rajesh Kumar >>>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>paulej@cisco.com >>>>>>> >>>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>> >>port number >> >>>>>>>Rajesh, >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Is the use of multiple 'm=' lines with the same port >>>>>>> >>number within >> >>>>>>>an >>>>>>> >>>>>>> >>>>>>>>SDP descriptor permitted? >>>>>>> >>>>>>>Presuming that the multiple m= lines are all RTP/AVP, >>>>>> >>then doing so >> >>>>>>>causes all of the payload formats listed on the m= >>>>>> >>lines to become >> >>>>>>>part of a single RTP session (unless they are >>>>>> >>distinguished by some >> >>>>>>>other aspect of addressing). Section 5.2 of the RTP >>>>>> >>spec addresses >> >>>>>>>NOT multiplexing different media in the same RTP session. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>> >>>>>are >>>>> >>>>> >>>>>>>of >>>>>>> >>>>>>> >>>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>>> >>>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>>destination port but are registered under different MIME types. >>>>>>> >>>>>For >>>>> >>>>> >>>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>>> >>>>>>>recourse >>>>>>> >>>>>>> >>>>>>>>except to use multiple media lines with the same port >>>>>>> >>number. For >> >>>>>>>example: >>>>>>> >>>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>>agree. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>>a=rtpmap:100 t140 >>>>>>>> >>>>>>>>My thought is that although this is unsual, it is not >>>>>>> >>proscribed >> >>>>>by >>>>> >>>>> >>>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>> >>>>>>>I believe this is proscribed by section 5.2 of the RTP >>>>>> >>spec because >> >>>>>>>these two media should not be multiplexed in one RTP session. >>>>>>> >>>>>>>My bet is that the real example you are thinking about is fax or >>>>>> >>>>>modem >>>>> >>>>> >>>>>>>over IP. We've been there before. >>>>>>> >>>>>>> -- Steve >>>>>>> >>>>>>>_______________________________________________ >>>>>>>mmusic mailing list >>>>>>>mmusic@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jan 8 09:44:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24641 for ; Thu, 8 Jan 2004 09:44:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebNq-0002ya-Sl for mmusic-archive@odin.ietf.org; Thu, 08 Jan 2004 09:43:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08EhcFa011434 for mmusic-archive@odin.ietf.org; Thu, 8 Jan 2004 09:43:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebNq-0002y6-Kw for mmusic-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 09:43:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24635 for ; Thu, 8 Jan 2004 09:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebNn-0006GD-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 09:43:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebM2-00061u-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 09:41:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AebKf-0005n2-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 09:40:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebKM-0002ZD-0k; Thu, 08 Jan 2004 09:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebJd-0002YW-PU for mmusic@optimus.ietf.org; Thu, 08 Jan 2004 09:39:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24389 for ; Thu, 8 Jan 2004 09:39:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebJS-0005k1-00 for mmusic@ietf.org; Thu, 08 Jan 2004 09:39:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebF6-0005Yd-00 for mmusic@ietf.org; Thu, 08 Jan 2004 09:34:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AebBg-0005L8-00; Thu, 08 Jan 2004 09:31:04 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2004 06:30:33 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i08ETvQu011300; Thu, 8 Jan 2004 06:29:57 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFC22277; Thu, 8 Jan 2004 09:29:56 -0500 (EST) Message-ID: <3FFD6964.40108@cisco.com> Date: Thu, 08 Jan 2004 09:29:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: Flemming Andreasen , mmusic@ietf.org, simple@ietf.org Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> <3FFC763E.3080600@cisco.com> <009701c3d563$40457c00$7f01a8c0@cisco.com> <3FFC811D.7000900@cisco.com> <01bc01c3d5ad$ccc077d0$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments inline. Paul P.S. I have added simple to the list, and removed most of the individual names, since my last posting was sent to the chair for screening. Paul E. Jones wrote: > Paul, > > >>>While that sounds most unfortunate >> >>What is most unfortunate? >>- that MSRP ignores the port number from the m-line >>- that different dummy port numbers might have to be used >>- ??? > > > That there is a different dummy port number inserted. Why not require that > they be consistent or just remove the port number from URL and rely on the > SDP port number when SDP is used? Is the URL used outside of SDP? From > what I've gathered, the URL is temporary and only used for session > identification. > > However, doing that does open the question that started this discussion... > would it be a problem for multiple m= lines to have the same port number. > It might be that you have two message sessions between to devices that > advertised the same TCP port, but are uniquely identified by the session > URL. Then we potentially have an SDP violation, I guess. That is a very likely scenario. >>The reason it is ignored is that an a-line containing a URL is used, and >>specifies all the addressing needed. The alternative was assembling a >>URL from pieces of the m-line, c-line, and an a-line. There really is no >>nice answer. The SDP syntax works tolerably for RTP and UDP but presents >>problems for more complex transports. > > > So, I can agree with not necessarily wanting to assemble a URL from various > pieces of data here and there. I don't want to propose that you necessarily > change the URL, but keep the port number consistent. As you point out above, keeping the port number consistent between the url and the m-line could lead to a violation. And the concept of having to put the same information in two places isn't especially appealing anyway. > I'm definitely aware of the issues with SDP "growing" to accomodate things > other than RTP and such. However, I don't have a good feel for whether > people are truly interested in making a big changed to something like SDPng > or just evolving SDP. It seems like evolving SDP is winning favor, though > I'd like to hear opinions on that. In the case that we do evolve SDP for a > number of years, we should try to do it in as consistent a manner as > possible. Certainly nobody is going to wait for SDPng to be adopted before introducing something line MSRP. There has to be a way to use it with SDP. > Now, as for this port number issue. As the document is now written, the > ports are unique and there is no violation to speak of... just confused me > when I saw it. I'd personally rather insert an exception into SDP to allow > TCP session to have the same port number than to create bogus port numbers. > A change in the SDP text along those lines would not break the spirit of the > present text and should not break anything. I guess this would be up to MMUSIC to deal with. As I mentioned in my reply to Hisham, it is probably the case that the path of least resistance for MSRP is to live with the uniqueness requirement. In any case, the two approaches don't conflict. MSRP can simply state that while the port numbers are ignored they must still conform to the SDP standard. Then if SDP changes to permit duplicate ports in this case then we are all set. >> > (I'd love to see an example if you have one), >> >>I've attached a message from the SIMPLE list. Note that the SDP is not >>intended to be complete - just the key parts needed to make the point. > > > Thanks. I also just looked at draft-ietf-simple-message-sessions-02.txt > briefly. I'm certainly not an expert on this subject matter, but I've > learned a little :) > > >> > I think it would be exempt from this rule, because the port is just a >>>dummy value. >> >>That would be nice. It may be necessary to clarify that somewhere. > > You might have already hashed all of these issues through already and I do > apologize if that is the case. (But, when I get explicitly copied on > something, I tend to pay more attention than when mailing list dialog goes > passing by.) > > I would like to hear your comments on what I've suggested and asked above. > > Thanks, > Paul > > >>Paul >> >> >>>Paul >>> >>>----- Original Message ----- >>>From: "Paul Kyzivat" >>>To: "Flemming Andreasen" >>>Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>>; "Stephen Casner" ; "Colin >>>Perkins" ; ; "Mostafa, Mohamed" >>>; "Abdelhamid, Hisham" ; >>>; >>>Sent: Wednesday, January 07, 2004 4:12 PM >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>> >>>>I recently encountered an interesting case relevant to this while making >>>>up an example for MSRP. >>>> >>>>In MSRP the port number is not used, except for the distinction between >>>>a zero and non-zero value. There is a requirement that some random >>>>non-zero value be inserted and then ignored. If there are multiple MSRP >>>>media sessions in the same SDP body, must they have differing port >>> >>>numbers? >>> >>> >>>>Paul >>>> >>>>Flemming Andreasen wrote: >>>> >>>> >>>>>"Kumar, Rajesh" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>AVT members, >>>>>> >>>>>>There was some confusion on this issue in the recent TIA TR.30.1 >>>>> > meeting > >>>>>>in Orlando, Florida. >>>>>> >>>>>>Could someone officially confirm or deny whether multiple "m=" lines >>>>>>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) >>>>>>cannot be assigned the same port number? >>>>> >>>>> >>>>>The consensus of this discussion is that is that they cannot (assuming >>>> >>>they >>> >>> >>>>>use the same IP address). >>>>> >>>>>-- Flemming >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>If they can be assigned the >>>>>>same port number, then it is possible to selectively associate RFC >>>>> > 2733 > >>>>>>FEC with some payload types such as those that carry voice band data. >>>>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>>>payload-specific declaration of FEC. I am aware of the fact that in >>>>> > RFC > >>>>>>2733 the use of and level of FEC is a transmitter prerogative and that >>>>> > a > >>>>>>transmitter may choose to selectively utilize FEC based on payload >>>>> > type > >>>>>>transmitted. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Rajesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>>>To: Kevin Boyle >>>>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; >>>>>> >>>>>>Mostafa, Mohamed; >>>>>> >>>>>> >>>>>> >>>>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port >>>>>> > number > >>>>>>> >>>>>>> >>>>>>>Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>All, >>>>>>>> >>>>>>>>Looking back at this email stream, one question remains outstanding >>>>>>> >>>>>>in >>>>>> >>>>>> >>>>>> >>>>>>>>my mind: >>>>>>>> >>>>>>>>What if the two m= lines have the SAME media type? For instance: >>>>>>>> >>>>>>>>m=audio 49232 RTP/AVP 18 >>>>>>>>m=image 49233 UDPTL t38 >>>>>>>>m=audio 49232 RTP/AVP 100 >>>>>>>>a=rtpmap:100 PCMU/8000 >>>>>>>>a=gpmd:100 vbd=yes >>>>>>>> >>>>>>>>For some of the SDP-based protocols, the order of appearance is >>>>>>> >>>>>>vital >>>>>> >>>>>> >>>>>> >>>>>>>>because it announces preference. >>>>>>> >>>>>>>Only for the media formats within a given "m=" line. Multiple "m=" >>>>>> >>>>>>lines >>>>>> >>>>>> >>>>>> >>>>>>>indicates a set of simultaneous media streams; not alternatives. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, >>>>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>>>> >>>>>>construct >>>>>> >>>>>> >>>>>> >>>>>>>>is allowed, since both m lines using the same port number use a >>>>>>> >>>>>>media >>>>>> >>>>>> >>>>>> >>>>>>>>type of audio. >>>>>>>> >>>>>>>>Is my understanding correct? >>>>>>>> >>>>>>> >>>>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>>>> >>>>>>Also, >>>>>> >>>>>> >>>>>> >>>>>>>the consensus of this discussion has been that you are *not* allowed >>>>>> >>>>>>to >>>>>> >>>>>> >>>>>> >>>>>>>use the same port for different media lines, regardless of whether >>>>>> >>>>>>they >>>>>> >>>>>> >>>>>> >>>>>>>share the same top-level MIME type or not. >>>>>>> >>>>>>>-- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Thanks, >>>>>>>> >>>>>>>>Kevin >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>>>To: Rajesh Kumar >>>>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>>paulej@cisco.com >>>>>>>> >>>>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>>>>>> >>>>>>>>Rajesh, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Is the use of multiple 'm=' lines with the same port number within >>>>>>>> >>>>>>>>an >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>SDP descriptor permitted? >>>>>>>> >>>>>>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so >>>>>>>>causes all of the payload formats listed on the m= lines to become >>>>>>>>part of a single RTP session (unless they are distinguished by some >>>>>>>>other aspect of addressing). Section 5.2 of the RTP spec addresses >>>>>>>>NOT multiplexing different media in the same RTP session. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>> >>>>>>are >>>>>> >>>>>> >>>>>> >>>>>>>>of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>>>> >>>>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>>>destination port but are registered under different MIME types. >>>>>>>> >>>>>>For >>>>>> >>>>>> >>>>>> >>>>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>> >>>>>>>>recourse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>except to use multiple media lines with the same port number. For >>>>>>>> >>>>>>>>example: >>>>>>>> >>>>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>>>agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>>>a=rtpmap:100 t140 >>>>>>>>> >>>>>>>>>My thought is that although this is unsual, it is not proscribed >>>>>>>> >>>>>>by >>>>>> >>>>>> >>>>>> >>>>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>> >>>>>>>>I believe this is proscribed by section 5.2 of the RTP spec because >>>>>>>>these two media should not be multiplexed in one RTP session. >>>>>>>> >>>>>>>>My bet is that the real example you are thinking about is fax or >>>>>>> >>>>>>modem >>>>>> >>>>>> >>>>>> >>>>>>>>over IP. We've been there before. >>>>>>>> >>>>>>>> -- Steve >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>mmusic mailing list >>>>>>>>mmusic@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>_______________________________________________ >>>>>mmusic mailing list >>>>>mmusic@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jan 8 14:16:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06568 for ; Thu, 8 Jan 2004 14:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AefdW-0000ME-GY for mmusic-archive@odin.ietf.org; Thu, 08 Jan 2004 14:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08JG6kD001370 for mmusic-archive@odin.ietf.org; Thu, 8 Jan 2004 14:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AefdW-0000M1-8V for mmusic-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:16:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06451 for ; Thu, 8 Jan 2004 14:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AefdT-00003i-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 14:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AefaW-0007bx-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 14:13:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AefUB-0007D7-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 14:06:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AefTn-00088U-Am; Thu, 08 Jan 2004 14:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeTP0-0001yy-36 for mmusic@optimus.ietf.org; Thu, 08 Jan 2004 01:12:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26179 for ; Thu, 8 Jan 2004 01:12:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeTOx-0004DR-00 for mmusic@ietf.org; Thu, 08 Jan 2004 01:12:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeTN2-000496-00 for mmusic@ietf.org; Thu, 08 Jan 2004 01:10:17 -0500 Received: from rrcs-midsouth-24-199-215-15.biz.rr.com ([24.199.215.15] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AeTL7-00045E-00 for mmusic@ietf.org; Thu, 08 Jan 2004 01:08:17 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id i0868CbB001363; Thu, 8 Jan 2004 01:08:12 -0500 Message-ID: <01bc01c3d5ad$ccc077d0$0401a8c0@berlin> From: "Paul E. Jones" To: "Paul Kyzivat" , "Paul E. Jones" Cc: "Flemming Andreasen" , "Kumar, Rajesh" , "Kevin Boyle" , "Stephen Casner" , "Colin Perkins" , , "Mostafa, Mohamed" , "Abdelhamid, Hisham" , References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> <3FFC763E.3080600@cisco.com> <009701c3d563$40457c00$7f01a8c0@cisco.com> <3FFC811D.7000900@cisco.com> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Thu, 8 Jan 2004 01:08:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, > > While that sounds most unfortunate > > What is most unfortunate? > - that MSRP ignores the port number from the m-line > - that different dummy port numbers might have to be used > - ??? That there is a different dummy port number inserted. Why not require that they be consistent or just remove the port number from URL and rely on the SDP port number when SDP is used? Is the URL used outside of SDP? From what I've gathered, the URL is temporary and only used for session identification. However, doing that does open the question that started this discussion... would it be a problem for multiple m= lines to have the same port number. It might be that you have two message sessions between to devices that advertised the same TCP port, but are uniquely identified by the session URL. Then we potentially have an SDP violation, I guess. > The reason it is ignored is that an a-line containing a URL is used, and > specifies all the addressing needed. The alternative was assembling a > URL from pieces of the m-line, c-line, and an a-line. There really is no > nice answer. The SDP syntax works tolerably for RTP and UDP but presents > problems for more complex transports. So, I can agree with not necessarily wanting to assemble a URL from various pieces of data here and there. I don't want to propose that you necessarily change the URL, but keep the port number consistent. I'm definitely aware of the issues with SDP "growing" to accomodate things other than RTP and such. However, I don't have a good feel for whether people are truly interested in making a big changed to something like SDPng or just evolving SDP. It seems like evolving SDP is winning favor, though I'd like to hear opinions on that. In the case that we do evolve SDP for a number of years, we should try to do it in as consistent a manner as possible. Now, as for this port number issue. As the document is now written, the ports are unique and there is no violation to speak of... just confused me when I saw it. I'd personally rather insert an exception into SDP to allow TCP session to have the same port number than to create bogus port numbers. A change in the SDP text along those lines would not break the spirit of the present text and should not break anything. > > (I'd love to see an example if you have one), > > I've attached a message from the SIMPLE list. Note that the SDP is not > intended to be complete - just the key parts needed to make the point. Thanks. I also just looked at draft-ietf-simple-message-sessions-02.txt briefly. I'm certainly not an expert on this subject matter, but I've learned a little :) > > I think it would be exempt from this rule, because the port is just a > > dummy value. > > That would be nice. It may be necessary to clarify that somewhere. You might have already hashed all of these issues through already and I do apologize if that is the case. (But, when I get explicitly copied on something, I tend to pay more attention than when mailing list dialog goes passing by.) I would like to hear your comments on what I've suggested and asked above. Thanks, Paul > > Paul > > > Paul > > > > ----- Original Message ----- > > From: "Paul Kyzivat" > > To: "Flemming Andreasen" > > Cc: "Kumar, Rajesh" ; "Kevin Boyle" > > ; "Stephen Casner" ; "Colin > > Perkins" ; ; "Mostafa, Mohamed" > > ; "Abdelhamid, Hisham" ; > > ; > > Sent: Wednesday, January 07, 2004 4:12 PM > > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > > > > >>I recently encountered an interesting case relevant to this while making > >>up an example for MSRP. > >> > >>In MSRP the port number is not used, except for the distinction between > >>a zero and non-zero value. There is a requirement that some random > >>non-zero value be inserted and then ignored. If there are multiple MSRP > >>media sessions in the same SDP body, must they have differing port > > > > numbers? > > > >>Paul > >> > >>Flemming Andreasen wrote: > >> > >>>"Kumar, Rajesh" wrote: > >>> > >>> > >>> > >>>>AVT members, > >>>> > >>>>There was some confusion on this issue in the recent TIA TR.30.1 meeting > >>>>in Orlando, Florida. > >>>> > >>>>Could someone officially confirm or deny whether multiple "m=" lines > >>>>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) > >>>>cannot be assigned the same port number? > >>> > >>> > >>>The consensus of this discussion is that is that they cannot (assuming > >> > > they > > > >>>use the same IP address). > >>> > >>>-- Flemming > >>> > >>> > >>> > >>> > >>>>If they can be assigned the > >>>>same port number, then it is possible to selectively associate RFC 2733 > >>>>FEC with some payload types such as those that carry voice band data. > >>>>Otherwise, there is a hole in SDP that does not permit selective, > >>>>payload-specific declaration of FEC. I am aware of the fact that in RFC > >>>>2733 the use of and level of FEC is a transmitter prerogative and that a > >>>>transmitter may choose to selectively utilize FEC based on payload type > >>>>transmitted. > >>>> > >>>>Thanks, > >>>> > >>>>Rajesh > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] > >>>>>Sent: Friday, December 12, 2003 4:21 AM > >>>>>To: Kevin Boyle > >>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; > >>>> > >>>>Mostafa, Mohamed; > >>>> > >>>> > >>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com > >>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > >>>>> > >>>>> > >>>>> > >>>>>Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> > >>>>>>All, > >>>>>> > >>>>>>Looking back at this email stream, one question remains outstanding > >>>>> > >>>>in > >>>> > >>>> > >>>>>>my mind: > >>>>>> > >>>>>>What if the two m= lines have the SAME media type? For instance: > >>>>>> > >>>>>>m=audio 49232 RTP/AVP 18 > >>>>>>m=image 49233 UDPTL t38 > >>>>>>m=audio 49232 RTP/AVP 100 > >>>>>>a=rtpmap:100 PCMU/8000 > >>>>>>a=gpmd:100 vbd=yes > >>>>>> > >>>>>>For some of the SDP-based protocols, the order of appearance is > >>>>> > >>>>vital > >>>> > >>>> > >>>>>>because it announces preference. > >>>>> > >>>>>Only for the media formats within a given "m=" line. Multiple "m=" > >>>> > >>>>lines > >>>> > >>>> > >>>>>indicates a set of simultaneous media streams; not alternatives. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, > >>>>>>while utilizing G.729 for voice. As far as I can tell, this > >>>>> > >>>>construct > >>>> > >>>> > >>>>>>is allowed, since both m lines using the same port number use a > >>>>> > >>>>media > >>>> > >>>> > >>>>>>type of audio. > >>>>>> > >>>>>>Is my understanding correct? > >>>>>> > >>>>> > >>>>>Not quite. Each "m=" line corresponds to a separate media stream. > >>>> > >>>>Also, > >>>> > >>>> > >>>>>the consensus of this discussion has been that you are *not* allowed > >>>> > >>>>to > >>>> > >>>> > >>>>>use the same port for different media lines, regardless of whether > >>>> > >>>>they > >>>> > >>>> > >>>>>share the same top-level MIME type or not. > >>>>> > >>>>>-- Flemming > >>>>> > >>>>> > >>>>> > >>>>>>Thanks, > >>>>>> > >>>>>>Kevin > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: Stephen Casner [mailto:casner@acm.org] > >>>>>>Sent: Friday, April 25, 2003 2:57 PM > >>>>>>To: Rajesh Kumar > >>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > >>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > >>>>>>paulej@cisco.com > >>>>>> > >>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > >>>>>> > >>>>>>Rajesh, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Is the use of multiple 'm=' lines with the same port number within > >>>>>> > >>>>>>an > >>>>>> > >>>>>> > >>>>>>>SDP descriptor permitted? > >>>>>> > >>>>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so > >>>>>>causes all of the payload formats listed on the m= lines to become > >>>>>>part of a single RTP session (unless they are distinguished by some > >>>>>>other aspect of addressing). Section 5.2 of the RTP spec addresses > >>>>>>NOT multiplexing different media in the same RTP session. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line > >>>>>> > >>>>are > >>>> > >>>> > >>>>>>of > >>>>>> > >>>>>> > >>>>>>>the same media type (e.g. audio, image, text etc.). > >>>>>>> > >>>>>>>Now consider the case in which two RTP media formats can use a > >>>>>>>destination port but are registered under different MIME types. > >>>>>> > >>>>For > >>>> > >>>> > >>>>>>>example, text/t140 and audio/PCMU. In this case, there is no > >>>>>> > >>>>>>recourse > >>>>>> > >>>>>> > >>>>>>>except to use multiple media lines with the same port number. For > >>>>>> > >>>>>>example: > >>>>>> > >>>>>>The "can use a destination port" is the tricky part. We may not > >>>>>>agree. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>m=audio 49232 RTP/AVP 0 > >>>>>>>m=text 49232 RTP/AVP 100 > >>>>>>>a=rtpmap:100 t140 > >>>>>>> > >>>>>>>My thought is that although this is unsual, it is not proscribed > >>>>>> > >>>>by > >>>> > >>>> > >>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. > >>>>>> > >>>>>>I believe this is proscribed by section 5.2 of the RTP spec because > >>>>>>these two media should not be multiplexed in one RTP session. > >>>>>> > >>>>>>My bet is that the real example you are thinking about is fax or > >>>>> > >>>>modem > >>>> > >>>> > >>>>>>over IP. We've been there before. > >>>>>> > >>>>>> -- Steve > >>>>>> > >>>>>>_______________________________________________ > >>>>>>mmusic mailing list > >>>>>>mmusic@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/mmusic > >>>>> > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jan 8 15:05:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06569 for ; Thu, 8 Jan 2004 14:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AefdW-0000Ma-Ou for mmusic-archive@odin.ietf.org; Thu, 08 Jan 2004 14:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08JG64q001390 for mmusic-archive@odin.ietf.org; Thu, 8 Jan 2004 14:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AefdW-0000MH-JQ for mmusic-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:16:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06454 for ; Thu, 8 Jan 2004 14:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AefdT-00003o-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 14:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AefaY-0007c6-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 14:13:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AefUB-0007D8-00 for mmusic-web-archive@ietf.org; Thu, 08 Jan 2004 14:06:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AefTm-000885-C8; Thu, 08 Jan 2004 14:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLoG-0004dt-JF for mmusic@optimus.ietf.org; Wed, 07 Jan 2004 17:05:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08504 for ; Wed, 7 Jan 2004 17:05:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLoC-0003Jj-00 for mmusic@ietf.org; Wed, 07 Jan 2004 17:05:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLl0-0002nY-00 for mmusic@ietf.org; Wed, 07 Jan 2004 17:02:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AeLi5-0001wH-00 for mmusic@ietf.org; Wed, 07 Jan 2004 16:59:29 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2004 21:59:24 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i07LwsLE011673; Wed, 7 Jan 2004 16:58:54 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB85514; Wed, 7 Jan 2004 16:58:53 -0500 (EST) Message-ID: <3FFC811D.7000900@cisco.com> Date: Wed, 07 Jan 2004 16:58:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: Flemming Andreasen , "Kumar, Rajesh" , Kevin Boyle , Stephen Casner , Colin Perkins , mmusic@ietf.org, "Mostafa, Mohamed" , "Abdelhamid, Hisham" , mgarakan@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> <3FFC763E.3080600@cisco.com> <009701c3d563$40457c00$7f01a8c0@cisco.com> Content-Type: multipart/mixed; boundary="------------010008030203010808000608" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------010008030203010808000608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit inline... Paul E. Jones wrote: > Paul, > > While that sounds most unfortunate What is most unfortunate? - that MSRP ignores the port number from the m-line - that different dummy port numbers might have to be used - ??? The reason it is ignored is that an a-line containing a URL is used, and specifies all the addressing needed. The alternative was assembling a URL from pieces of the m-line, c-line, and an a-line. There really is no nice answer. The SDP syntax works tolerably for RTP and UDP but presents problems for more complex transports. > (I'd love to see an example if you have one), I've attached a message from the SIMPLE list. Note that the SDP is not intended to be complete - just the key parts needed to make the point. > I think it would be exempt from this rule, because the port is just a > dummy value. That would be nice. It may be necessary to clarify that somewhere. Paul > Paul > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Flemming Andreasen" > Cc: "Kumar, Rajesh" ; "Kevin Boyle" > ; "Stephen Casner" ; "Colin > Perkins" ; ; "Mostafa, Mohamed" > ; "Abdelhamid, Hisham" ; > ; > Sent: Wednesday, January 07, 2004 4:12 PM > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > >>I recently encountered an interesting case relevant to this while making >>up an example for MSRP. >> >>In MSRP the port number is not used, except for the distinction between >>a zero and non-zero value. There is a requirement that some random >>non-zero value be inserted and then ignored. If there are multiple MSRP >>media sessions in the same SDP body, must they have differing port > > numbers? > >>Paul >> >>Flemming Andreasen wrote: >> >>>"Kumar, Rajesh" wrote: >>> >>> >>> >>>>AVT members, >>>> >>>>There was some confusion on this issue in the recent TIA TR.30.1 meeting >>>>in Orlando, Florida. >>>> >>>>Could someone officially confirm or deny whether multiple "m=" lines >>>>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) >>>>cannot be assigned the same port number? >>> >>> >>>The consensus of this discussion is that is that they cannot (assuming >> > they > >>>use the same IP address). >>> >>>-- Flemming >>> >>> >>> >>> >>>>If they can be assigned the >>>>same port number, then it is possible to selectively associate RFC 2733 >>>>FEC with some payload types such as those that carry voice band data. >>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>payload-specific declaration of FEC. I am aware of the fact that in RFC >>>>2733 the use of and level of FEC is a transmitter prerogative and that a >>>>transmitter may choose to selectively utilize FEC based on payload type >>>>transmitted. >>>> >>>>Thanks, >>>> >>>>Rajesh >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>To: Kevin Boyle >>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; >>>> >>>>Mostafa, Mohamed; >>>> >>>> >>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>>> >>>>> >>>>> >>>>>Kevin Boyle wrote: >>>>> >>>>> >>>>> >>>>>>All, >>>>>> >>>>>>Looking back at this email stream, one question remains outstanding >>>>> >>>>in >>>> >>>> >>>>>>my mind: >>>>>> >>>>>>What if the two m= lines have the SAME media type? For instance: >>>>>> >>>>>>m=audio 49232 RTP/AVP 18 >>>>>>m=image 49233 UDPTL t38 >>>>>>m=audio 49232 RTP/AVP 100 >>>>>>a=rtpmap:100 PCMU/8000 >>>>>>a=gpmd:100 vbd=yes >>>>>> >>>>>>For some of the SDP-based protocols, the order of appearance is >>>>> >>>>vital >>>> >>>> >>>>>>because it announces preference. >>>>> >>>>>Only for the media formats within a given "m=" line. Multiple "m=" >>>> >>>>lines >>>> >>>> >>>>>indicates a set of simultaneous media streams; not alternatives. >>>>> >>>>> >>>>> >>>>> >>>>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, >>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>> >>>>construct >>>> >>>> >>>>>>is allowed, since both m lines using the same port number use a >>>>> >>>>media >>>> >>>> >>>>>>type of audio. >>>>>> >>>>>>Is my understanding correct? >>>>>> >>>>> >>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>> >>>>Also, >>>> >>>> >>>>>the consensus of this discussion has been that you are *not* allowed >>>> >>>>to >>>> >>>> >>>>>use the same port for different media lines, regardless of whether >>>> >>>>they >>>> >>>> >>>>>share the same top-level MIME type or not. >>>>> >>>>>-- Flemming >>>>> >>>>> >>>>> >>>>>>Thanks, >>>>>> >>>>>>Kevin >>>>>> >>>>>>-----Original Message----- >>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>To: Rajesh Kumar >>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>paulej@cisco.com >>>>>> >>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>>>> >>>>>>Rajesh, >>>>>> >>>>>> >>>>>> >>>>>>>Is the use of multiple 'm=' lines with the same port number within >>>>>> >>>>>>an >>>>>> >>>>>> >>>>>>>SDP descriptor permitted? >>>>>> >>>>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so >>>>>>causes all of the payload formats listed on the m= lines to become >>>>>>part of a single RTP session (unless they are distinguished by some >>>>>>other aspect of addressing). Section 5.2 of the RTP spec addresses >>>>>>NOT multiplexing different media in the same RTP session. >>>>>> >>>>>> >>>>>> >>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>> >>>>are >>>> >>>> >>>>>>of >>>>>> >>>>>> >>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>> >>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>destination port but are registered under different MIME types. >>>>>> >>>>For >>>> >>>> >>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>> >>>>>>recourse >>>>>> >>>>>> >>>>>>>except to use multiple media lines with the same port number. For >>>>>> >>>>>>example: >>>>>> >>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>agree. >>>>>> >>>>>> >>>>>> >>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>a=rtpmap:100 t140 >>>>>>> >>>>>>>My thought is that although this is unsual, it is not proscribed >>>>>> >>>>by >>>> >>>> >>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>> >>>>>>I believe this is proscribed by section 5.2 of the RTP spec because >>>>>>these two media should not be multiplexed in one RTP session. >>>>>> >>>>>>My bet is that the real example you are thinking about is fax or >>>>> >>>>modem >>>> >>>> >>>>>>over IP. We've been there before. >>>>>> >>>>>> -- Steve >>>>>> >>>>>>_______________________________________________ >>>>>>mmusic mailing list >>>>>>mmusic@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > --------------010008030203010808000608 Content-Type: message/rfc822; name="mailbox-message://pkyzivat@cannon.cisco.com/cisco/SIP#85526760" Content-Disposition: inline; filename="mailbox-message://pkyzivat@cannon.cisco.com/cisco/SIP#85526760" Return-Path: Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB00766; Tue, 6 Jan 2004 16:13:37 -0500 (EST) Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i06LDVGN025680; Tue, 6 Jan 2004 13:13:31 -0800 (PST) Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id i06LCgNc014394; Tue, 6 Jan 2004 13:12:43 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyVZ-0001fL-Cj; Tue, 06 Jan 2004 16:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyV5-0001eZ-TM for simple@optimus.ietf.org; Tue, 06 Jan 2004 16:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03919 for ; Tue, 6 Jan 2004 16:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyUz-0000dj-00 for simple@ietf.org; Tue, 06 Jan 2004 16:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyPN-0000Ry-00 for simple@ietf.org; Tue, 06 Jan 2004 16:06:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AdyMS-0000Iw-00 for simple@ietf.org; Tue, 06 Jan 2004 16:03:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2004 13:10:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i06L2pVM028127; Tue, 6 Jan 2004 13:02:52 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFA99752; Tue, 6 Jan 2004 16:02:50 -0500 (EST) Message-ID: <3FFB227A.5070100@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <45730E094814E44488F789C1CDED27AE0219B153@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 16:02:50 -0500 Content-Transfer-Encoding: 7bit Chris Boulton wrote: > > [Chris Boulton] I think we can all recognize that this is a global > problem rather than msrp specific. I like Paul's idea of having an > attribute e.g. 'a=reconnect' to indicate the continuation of a session. > Just one question, the version number in the offer will have changed, > due to payload change, so how would the msrp client associate a > reconnect with an existing session, if multiple exist? > > e.g. Client A and B currently have 2 connection, one for messaging, one > for file transfer - client B is hosting. Client A detects failure in > one of the connections (Client B has not detected failure) and issues a > new offer via an 'update'. Client B receives the offer and realizes > it's a reconnect. How does client B know which of the two connections > we are attempting to reconnect? The attribute is associated with a particular media session. It can be inserted into the one for the session that is to be reconnected. It is inserted twice if both are to be reconnected. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both a=session:msrp://alicepc.atlanta.com:7777/iau39 a=version:1 Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 Alice then adds another session for file transfer: Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both a=version:1 m=message 9998 msrp/tcp * a=accept-types:application/pdf a=direction:passive a=sendonly a=session:msrp://alicepc.atlanta.com:7777/iau40 a=version:1 Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 m=message 9998 msrp/tcp * a=accept-types:application/pdf a=direction:active a=recvonly a=version:1 Bob later discovers something wrong with the file transfer: Bob->Alice (SIP): (re)INVITE sip:alice-gruu@atlanta.com c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 m=message 9999 msrp/tcp * a=accept-types:application/pdf a=direction:active a=recvonly a=version:2 Alice sees that the version for the first session is unchanged and so does nothing with it. But the version for the 2nd session is changed, so she starts listening again for a new connection, and responds: Alice->Bob (SIP): 200 OK c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:passive a=version:1 m=message 9999 msrp/tcp * a=accept-types:application/pdf a=direction:passive a=sendonly a=session:msrp://alicepc.atlanta.com:7777/iau41 a=version:2 A subsequent offer/answer that didn't want to change anything could use these same sdp bodies. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --------------010008030203010808000608-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jan 9 10:37:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06077 for ; Fri, 9 Jan 2004 10:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeygw-0003AJ-7d for mmusic-archive@odin.ietf.org; Fri, 09 Jan 2004 10:36:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Fasfm012160 for mmusic-archive@odin.ietf.org; Fri, 9 Jan 2004 10:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeygw-00039m-3h for mmusic-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 10:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05923 for ; Fri, 9 Jan 2004 10:36:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeygs-0000Wh-00 for mmusic-web-archive@ietf.org; Fri, 09 Jan 2004 10:36:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyf8-0000GS-00 for mmusic-web-archive@ietf.org; Fri, 09 Jan 2004 10:35:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeydF-000013-00 for mmusic-web-archive@ietf.org; Fri, 09 Jan 2004 10:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeydD-0002LD-On; Fri, 09 Jan 2004 10:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeycf-0002JL-AZ for mmusic@optimus.ietf.org; Fri, 09 Jan 2004 10:32:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04748 for ; Fri, 9 Jan 2004 10:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeycc-0007fq-01 for mmusic@ietf.org; Fri, 09 Jan 2004 10:32:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeyUt-0007If-00 for mmusic@ietf.org; Fri, 09 Jan 2004 10:24:27 -0500 Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx with esmtp (Exim 4.12) id 1AeyUC-0007CU-00 for mmusic@ietf.org; Fri, 09 Jan 2004 10:23:45 -0500 Received: from oleane ([194.206.151.59]) by smtp5.clb.oleane.net with SMTP id i09FNEf3025114 for ; Fri, 9 Jan 2004 16:23:14 +0100 Message-ID: <032a01c3d6c5$804df580$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Fri, 9 Jan 2004 16:30:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0327_01C3D6CD.E1CF3A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [MMUSIC] WiMAX Summit call for papers Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0327_01C3D6CD.E1CF3A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The dead line of the WiMAX Summit call for papers has been extended to = January 30th.=20 =20 All details at: http://www.upperside.fr/wimax04/wimax04intro.htm The WiMAX Summit will be held in Paris next May 2004 25-28=20 ------=_NextPart_000_0327_01C3D6CD.E1CF3A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The dead line of the WiMAX Summit call for = papers has=20 been extended to January 30th.=20
 
All details at:
 
http://www.uppe= rside.fr/wimax04/wimax04intro.htm
 
The WiMAX Summit  will be held in Paris next May 2004 25-28=20
------=_NextPart_000_0327_01C3D6CD.E1CF3A00-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 12 10:13:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01361 for ; Mon, 12 Jan 2004 10:13:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3kh-0007n8-0n for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 10:13:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CFDEFY029944 for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 10:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3kg-0007mt-Tn for mmusic-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 10:13:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01255 for ; Mon, 12 Jan 2004 10:13:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3ke-0006rM-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:13:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3io-0006mi-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:11:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag3hq-0006iA-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:10:18 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ag3hp-0003YR-UU for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:10:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3hd-0007Vh-EO; Mon, 12 Jan 2004 10:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3gz-0007PS-GL for mmusic@optimus.ietf.org; Mon, 12 Jan 2004 10:09:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00739 for ; Mon, 12 Jan 2004 10:09:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3gx-0006gq-00 for mmusic@ietf.org; Mon, 12 Jan 2004 10:09:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3f6-0006cc-00 for mmusic@ietf.org; Mon, 12 Jan 2004 10:07:29 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag3eU-0006TD-00; Mon, 12 Jan 2004 10:06:51 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2004 07:08:38 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0CF6EVO008153; Mon, 12 Jan 2004 07:06:17 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFE24930; Mon, 12 Jan 2004 10:06:13 -0500 (EST) Message-ID: <4002B7E5.8090700@cisco.com> Date: Mon, 12 Jan 2004 10:06:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org, mmusic@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My attempts to reach David Yon at the address he has listed in the comedia draft (yon@dialout.net) have bounced. Does anybody know whether he is still at Dialout.Net, or even if Dialout.Net still exists? Paul Paul Kyzivat wrote: > Ben, > > I'm copying David Yon on this since he is author of comedia. This > probably won't make any sense out of context to him, so I will > separately send him some of the earlier discussion. > > I don't recall what the current status of comedia is. It is currently > listed as a WG draft, but there don't seem to be any goals listed for it. > > Paul > > Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >>> >>> >>> Ben Campbell wrote: >>> >>>> (More comments on same email...) >>>> >>>> Paul Kyzivat wrote: >>>> >>>> [...] >>>> >>>>> >>>>> Using the same media lines for the replacement session solves the >>>>> association problem for any media type - MSRP, RTP, whatever. But >>>>> it also does leave the problem of distinguishing a "reconnect" >>>>> offer from a "don't change anything" offer. >>>> >>>> >>>> >>>> >>>> Would doing this, plus using the COMEDIA reconnect attribute help? >>>> (section 5 of current comedia draft.) >>> >>> >>> >>> >>> That would probably work. The feature in comedia didn't end up as I >>> hoped it would. While it does mean you have to do something special >>> (add the a=reconnect) attribute to cause a reconnect, having done >>> that once you then have to do something else (remove the a=reconnect) >>> in a subsequent exchange. >>> >>> I think it would be better if there were something like >>> a=version:nnn, which would just be a version number for a particular >>> media session. Then whenever it changes you reconnect. If the >>> attribute was absent it could be defaulted from the o-line. >> >> >> >> I agree that sounds like a better approach. Do you think there is any >> chance to convince the COMEDIA folks to follow the same approach? >> >>> >>> Paul >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 12 10:59:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03494 for ; Mon, 12 Jan 2004 10:59:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4T1-0001Ag-5C for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 10:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CFx3vT004501 for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 10:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4T1-0001AW-0i for mmusic-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 10:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03491 for ; Mon, 12 Jan 2004 10:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4Sy-0000ts-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4RA-0000rc-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:57:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag4Q5-0000ou-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 10:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4Q6-00014l-Jc; Mon, 12 Jan 2004 10:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4PE-00013l-PC for mmusic@optimus.ietf.org; Mon, 12 Jan 2004 10:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03412 for ; Mon, 12 Jan 2004 10:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4PC-0000mt-00 for mmusic@ietf.org; Mon, 12 Jan 2004 10:55:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4NM-0000ku-00 for mmusic@ietf.org; Mon, 12 Jan 2004 10:53:13 -0500 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag4Mh-0000hx-00; Mon, 12 Jan 2004 10:52:31 -0500 Received: from yon-lattitude.rfdsoftware.com (rt314.tactical-sw.com [216.41.119.98]) (authenticated) by [216.41.119.110] (8.10.2/8.10.2) with ESMTP id i0CFs2Z20692; Mon, 12 Jan 2004 10:54:02 -0500 Message-Id: <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 12 Jan 2004 10:51:40 -0500 To: Paul Kyzivat , simple@ietf.org, mmusic@ietf.org From: David Yon Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates In-Reply-To: <4002B7E5.8090700@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Here I am! :-) Dialout.Net is defunct, but at the moment I am still willing to support the comedia draft, although I have much less time available to me for it. My only concern with a "version" attribute is that it causes a reconnection by inference. I'm afraid that it would be rife with temptation to use it to version-stamp the session for other reasons that do not imply the impetus to reconnect. Is there some tangible scenario where "version" is superior to "reconnect"? At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >My attempts to reach David Yon at the address he has listed in the comedia >draft (yon@dialout.net) have bounced. Does anybody know whether he is >still at Dialout.Net, or even if Dialout.Net still exists? > > Paul > >Paul Kyzivat wrote: >>Ben, >>I'm copying David Yon on this since he is author of comedia. This >>probably won't make any sense out of context to him, so I will separately >>send him some of the earlier discussion. >>I don't recall what the current status of comedia is. It is currently >>listed as a WG draft, but there don't seem to be any goals listed for it. >> Paul >>Ben Campbell wrote: >> >>>Paul Kyzivat wrote: >>> >>>> >>>> >>>>Ben Campbell wrote: >>>> >>>>>(More comments on same email...) >>>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>>> >>>>>>Using the same media lines for the replacement session solves the >>>>>>association problem for any media type - MSRP, RTP, whatever. But it >>>>>>also does leave the problem of distinguishing a "reconnect" offer >>>>>>from a "don't change anything" offer. >>>>> >>>>> >>>>> >>>>> >>>>>Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>(section 5 of current comedia draft.) >>>> >>>> >>>> >>>> >>>>That would probably work. The feature in comedia didn't end up as I >>>>hoped it would. While it does mean you have to do something special >>>>(add the a=reconnect) attribute to cause a reconnect, having done that >>>>once you then have to do something else (remove the a=reconnect) in a >>>>subsequent exchange. >>>> >>>>I think it would be better if there were something like a=version:nnn, >>>>which would just be a version number for a particular media session. >>>>Then whenever it changes you reconnect. If the attribute was absent it >>>>could be defaulted from the o-line. >>> >>> >>> >>>I agree that sounds like a better approach. Do you think there is any >>>chance to convince the COMEDIA folks to follow the same approach? >>> >>>> >>>> Paul >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 12 13:22:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09484 for ; Mon, 12 Jan 2004 13:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6hT-0007rw-Gi for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 13:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CIM71D030248 for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 13:22:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6hT-0007rn-Dt for mmusic-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 13:22:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09462 for ; Mon, 12 Jan 2004 13:22:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6hR-0007Ii-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 13:22:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6fZ-0007Eh-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 13:20:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag6eT-0007BH-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 13:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6eT-0007jZ-Qx; Mon, 12 Jan 2004 13:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6dV-0007ej-1G for mmusic@optimus.ietf.org; Mon, 12 Jan 2004 13:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09314 for ; Mon, 12 Jan 2004 13:17:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6dS-000791-00 for mmusic@ietf.org; Mon, 12 Jan 2004 13:17:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6bk-00076z-00 for mmusic@ietf.org; Mon, 12 Jan 2004 13:16:13 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag6bB-00074D-00; Mon, 12 Jan 2004 13:15:37 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0CIEhVO006307; Mon, 12 Jan 2004 10:15:04 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFE43989; Mon, 12 Jan 2004 13:14:42 -0500 (EST) Message-ID: <4002E412.2070608@cisco.com> Date: Mon, 12 Jan 2004 13:14:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Yon wrote: > Here I am! :-) > > Dialout.Net is defunct, but at the moment I am still willing to support > the comedia draft, although I have much less time available to me for it. I was suspecting Dialout might be gone because attempts to access the web site timed out. Glad to hear that you are still around. Maybe you should submit a new version of comedia just to update your address. > My only concern with a "version" attribute is that it causes a > reconnection by inference. I'm afraid that it would be rife with > temptation to use it to version-stamp the session for other reasons that > do not imply the impetus to reconnect. Is there some tangible scenario > where "version" is superior to "reconnect"? I can see how you might consider reconnection by inference to be a negative. But in my view that is also its appeal. The point is to preserve the behavior that reuse of unchanged SDP acts as a no-op. Once you introduce the a=reconnect attribute, a subsequent offer/answer cycle that reuses sdp containing that will cause another reconnect, which isn't a no-op. By using a=version, it is the detection of a revised version number that causes the reconnect. So a subsequent offer/answer cycle using the same sdp will not see a change in version number and so will not cause another reconnect. This is of significance whenever there might be components that manipulate offers and answers in a generic way. For instance, if you have a UA that manages multiple media streams, there may be one component that decomposes the sdp and then interacts with a separate component in the UA for each stream. If there is a need to make a change in one stream, it may simply want to make a change in the description of the affected stream without dealing with the components responsible for other streams. In general, with the exception of a=reconnect, it can do this. I am not especially attached to the name "version". I am certainly willing to entertain some other name for the attribute that is clearer and less prone to invite abuse. E.g. we might consider a=reconnect:NNN. Paul > At 10:06 AM 1/12/2004, Paul Kyzivat wrote: > >> My attempts to reach David Yon at the address he has listed in the >> comedia draft (yon@dialout.net) have bounced. Does anybody know >> whether he is still at Dialout.Net, or even if Dialout.Net still exists? >> >> Paul >> >> Paul Kyzivat wrote: >> >>> Ben, >>> I'm copying David Yon on this since he is author of comedia. This >>> probably won't make any sense out of context to him, so I will >>> separately send him some of the earlier discussion. >>> I don't recall what the current status of comedia is. It is currently >>> listed as a WG draft, but there don't seem to be any goals listed for >>> it. >>> Paul >>> Ben Campbell wrote: >>> >>>> Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> (More comments on same email...) >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> >>>>>>> Using the same media lines for the replacement session solves the >>>>>>> association problem for any media type - MSRP, RTP, whatever. But >>>>>>> it also does leave the problem of distinguishing a "reconnect" >>>>>>> offer from a "don't change anything" offer. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>> (section 5 of current comedia draft.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> That would probably work. The feature in comedia didn't end up as I >>>>> hoped it would. While it does mean you have to do something special >>>>> (add the a=reconnect) attribute to cause a reconnect, having done >>>>> that once you then have to do something else (remove the >>>>> a=reconnect) in a subsequent exchange. >>>>> >>>>> I think it would be better if there were something like >>>>> a=version:nnn, which would just be a version number for a >>>>> particular media session. Then whenever it changes you reconnect. >>>>> If the attribute was absent it could be defaulted from the o-line. >>>> >>>> >>>> >>>> >>>> I agree that sounds like a better approach. Do you think there is >>>> any chance to convince the COMEDIA folks to follow the same approach? >>>> >>>>> >>>>> Paul >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 12 14:56:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13777 for ; Mon, 12 Jan 2004 14:56:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8Aa-0002UY-UT for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 14:56:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CJuGQP009571 for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 14:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8Aa-0002UI-QV for mmusic-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 14:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13767 for ; Mon, 12 Jan 2004 14:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8AX-0003o7-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 14:56:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag88o-0003kB-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 14:54:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag87P-0003eX-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 14:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag87R-0002N6-8i; Mon, 12 Jan 2004 14:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag86X-0002MO-82 for mmusic@optimus.ietf.org; Mon, 12 Jan 2004 14:52:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13522 for ; Mon, 12 Jan 2004 14:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag86U-0003ZV-00 for mmusic@ietf.org; Mon, 12 Jan 2004 14:52:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag84g-0003UM-00 for mmusic@ietf.org; Mon, 12 Jan 2004 14:50:11 -0500 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag83A-0003NS-00; Mon, 12 Jan 2004 14:48:37 -0500 Received: from yon-lattitude.rfdsoftware.com (rt314.tactical-sw.com [216.41.119.98]) (authenticated) by [216.41.119.110] (8.10.2/8.10.2) with ESMTP id i0CJoPZ31001; Mon, 12 Jan 2004 14:50:25 -0500 Message-Id: <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 12 Jan 2004 14:48:29 -0500 To: Paul Kyzivat From: David Yon Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates Cc: simple@ietf.org, mmusic@ietf.org In-Reply-To: <4002E412.2070608@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 01:14 PM 1/12/2004, Paul Kyzivat wrote: >David Yon wrote: >>Here I am! :-) >>Dialout.Net is defunct, but at the moment I am still willing to support >>the comedia draft, although I have much less time available to me for it. > >I was suspecting Dialout might be gone because attempts to access the web >site timed out. Glad to hear that you are still around. Maybe you should >submit a new version of comedia just to update your address. Yeah, I was waiting for other excuses to freshen comedia, but there are a couple of issues that have kept it deadlocked. While not all issues for an upcoming comedia-06 have been resolved, it would probably be worthwhile to spin it just to get discussion going again, even if there are known flaws. >>My only concern with a "version" attribute is that it causes a >>reconnection by inference. I'm afraid that it would be rife with >>temptation to use it to version-stamp the session for other reasons that >>do not imply the impetus to reconnect. Is there some tangible scenario >>where "version" is superior to "reconnect"? > >I can see how you might consider reconnection by inference to be a >negative. But in my view that is also its appeal. > >The point is to preserve the behavior that reuse of unchanged SDP acts as >a no-op. Once you introduce the a=reconnect attribute, a subsequent >offer/answer cycle that reuses sdp containing that will cause another >reconnect, which isn't a no-op. > >By using a=version, it is the detection of a revised version number that >causes the reconnect. So a subsequent offer/answer cycle using the same >sdp will not see a change in version number and so will not cause another >reconnect. > >This is of significance whenever there might be components that manipulate >offers and answers in a generic way. For instance, if you have a UA that >manages multiple media streams, there may be one component that decomposes >the sdp and then interacts with a separate component in the UA for each >stream. If there is a need to make a change in one stream, it may simply >want to make a change in the description of the affected stream without >dealing with the components responsible for other streams. In general, >with the exception of a=reconnect, it can do this. > >I am not especially attached to the name "version". I am certainly willing >to entertain some other name for the attribute that is clearer and less >prone to invite abuse. E.g. we might consider a=reconnect:NNN. "reconnect:NNN" would probably be a useful enhancement to "reconnect", and if connection reestablishment was the goal of "version", then I would vote for that. The only issue would be that of the original SDP exchange. It hardly seems appropriate to include a "reconnect" attribute in the initial exchange, but then when you want to negotiate a new connection and suddenly this attribute appears, what's the appropriate value for NNN? A couple of possibilities: a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it mandatory. b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". Therefore the first reconnection negotiation would have "a=reconnect:1". c) Make the omission imply "a=reconnect:", such that the first appearance of "reconnect" would be "a=reconnect:0". I would guess that (a) makes the most sense. Thoughts? Also, are there any possibilities of race conditions where the NNN would get out of sync between the two endpoints? If so, how would that be resolved? What about the additional state that must be tracked (the reconnection number)? I don't think that comedia-05 represents any additional state over connectionless media, which wouldn't be true for "reconnect:NNN". > Paul > >>At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >> >>>My attempts to reach David Yon at the address he has listed in the >>>comedia draft (yon@dialout.net) have bounced. Does anybody know whether >>>he is still at Dialout.Net, or even if Dialout.Net still exists? >>> >>> Paul >>> >>>Paul Kyzivat wrote: >>> >>>>Ben, >>>>I'm copying David Yon on this since he is author of comedia. This >>>>probably won't make any sense out of context to him, so I will >>>>separately send him some of the earlier discussion. >>>>I don't recall what the current status of comedia is. It is currently >>>>listed as a WG draft, but there don't seem to be any goals listed for it. >>>> Paul >>>>Ben Campbell wrote: >>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>> >>>>>> >>>>>>Ben Campbell wrote: >>>>>> >>>>>>>(More comments on same email...) >>>>>>> >>>>>>>Paul Kyzivat wrote: >>>>>>> >>>>>>>[...] >>>>>>> >>>>>>>> >>>>>>>>Using the same media lines for the replacement session solves the >>>>>>>>association problem for any media type - MSRP, RTP, whatever. But >>>>>>>>it also does leave the problem of distinguishing a "reconnect" >>>>>>>>offer from a "don't change anything" offer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>>>(section 5 of current comedia draft.) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>That would probably work. The feature in comedia didn't end up as I >>>>>>hoped it would. While it does mean you have to do something special >>>>>>(add the a=reconnect) attribute to cause a reconnect, having done >>>>>>that once you then have to do something else (remove the a=reconnect) >>>>>>in a subsequent exchange. >>>>>> >>>>>>I think it would be better if there were something like >>>>>>a=version:nnn, which would just be a version number for a particular >>>>>>media session. Then whenever it changes you reconnect. If the >>>>>>attribute was absent it could be defaulted from the o-line. >>>>> >>>>> >>>>> >>>>> >>>>>I agree that sounds like a better approach. Do you think there is any >>>>>chance to convince the COMEDIA folks to follow the same approach? >>>>> >>>>>> >>>>>> Paul >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 12 15:45:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18378 for ; Mon, 12 Jan 2004 15:45:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8wB-0004Qc-7G for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 15:45:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CKjRpn017018 for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 15:45:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8wB-0004QP-2o for mmusic-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 15:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18266 for ; Mon, 12 Jan 2004 15:45:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8w9-000713-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 15:45:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8vd-0006rt-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 15:45:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag8tq-0006gV-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 15:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8tp-0004Dk-NF; Mon, 12 Jan 2004 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8t2-0004CU-Iy for mmusic@optimus.ietf.org; Mon, 12 Jan 2004 15:42:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17878 for ; Mon, 12 Jan 2004 15:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8t1-0006a1-00 for mmusic@ietf.org; Mon, 12 Jan 2004 15:42:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8rK-0006Um-00 for mmusic@ietf.org; Mon, 12 Jan 2004 15:40:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8q0-0006PP-00; Mon, 12 Jan 2004 15:39:04 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2004 12:38:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0CKcULE022719; Mon, 12 Jan 2004 15:38:31 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFE61034; Mon, 12 Jan 2004 15:38:29 -0500 (EST) Message-ID: <400305C5.10009@cisco.com> Date: Mon, 12 Jan 2004 15:38:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Yon wrote: > > "reconnect:NNN" would probably be a useful enhancement to "reconnect", > and if connection reestablishment was the goal of "version", then I > would vote for that. That is certainly the driving force behind it at the moment. Unless someone can envision another use then I am happy to go along with this. > The only issue would be that of the original SDP exchange. It hardly > seems appropriate to include a "reconnect" attribute in the initial > exchange, but then when you want to negotiate a new connection and > suddenly this attribute appears, what's the appropriate value for NNN? > A couple of possibilities: > > a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it > mandatory. > > b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". > Therefore the first reconnection negotiation would have "a=reconnect:1". > > c) Make the omission imply "a=reconnect:", such that the first > appearance of "reconnect" would be "a=reconnect:0". > > I would guess that (a) makes the most sense. Thoughts? That seems reasonable. In practice the number doesn't mean much except that it change. It would work as well if it were an opaque token. When considered as a version number it makes more sense as an increasing number. How about a=connection:NNN? (With a default of 1.) This numbers the connections used to convey the media stream. This is clearly associated with connections, so it isn't prone to abuse, and it also conveys a clear semantic for the number. > Also, are there any possibilities of race conditions where the NNN would > get out of sync between the two endpoints? If so, how would that be > resolved? I don't believe there are any race conditions, though there is always the possibility of buggy endpoint getting confused. I don't think there are any race conditions because NNN isn't negotiated - it is always managed by one end and conveyed to the other end. In an offer/answer exchange, each side could conceivably provide its own value for a=reconnect:NNN. It is only meaningful when provided by a passive end to an active end, because it determines whether the active end should reconnect. In the case of MSRP, there is only one connection, so reconnection only makes sense in the direction of the original connection. In the case of comedia there could conceivably be two connections, one in each direction. If so, it is conceivable that an offer/answer exchange could have a=reconnect=NNN going both ways, and resulting in zero, one, or two reconnections. > What about the additional state that must be tracked (the reconnection > number)? I don't think that comedia-05 represents any additional state > over connectionless media, which wouldn't be true for "reconnect:NNN". There is extra implicit state in comedia. It must remember active, passive, or both, whether still listening if passive, whether connected if active, and ultimately the connection itself must be remembered as state. This adds a number that must be associated with the connection. Doesn't seem like a big burden. >> Paul >> >>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>> >>>> My attempts to reach David Yon at the address he has listed in the >>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>> exists? >>>> >>>> Paul >>>> >>>> Paul Kyzivat wrote: >>>> >>>>> Ben, >>>>> I'm copying David Yon on this since he is author of comedia. This >>>>> probably won't make any sense out of context to him, so I will >>>>> separately send him some of the earlier discussion. >>>>> I don't recall what the current status of comedia is. It is >>>>> currently listed as a WG draft, but there don't seem to be any >>>>> goals listed for it. >>>>> Paul >>>>> Ben Campbell wrote: >>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Ben Campbell wrote: >>>>>>> >>>>>>>> (More comments on same email...) >>>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> >>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>> whatever. But it also does leave the problem of distinguishing >>>>>>>>> a "reconnect" offer from a "don't change anything" offer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>> help? (section 5 of current comedia draft.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> That would probably work. The feature in comedia didn't end up as >>>>>>> I hoped it would. While it does mean you have to do something >>>>>>> special (add the a=reconnect) attribute to cause a reconnect, >>>>>>> having done that once you then have to do something else (remove >>>>>>> the a=reconnect) in a subsequent exchange. >>>>>>> >>>>>>> I think it would be better if there were something like >>>>>>> a=version:nnn, which would just be a version number for a >>>>>>> particular media session. Then whenever it changes you reconnect. >>>>>>> If the attribute was absent it could be defaulted from the o-line. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that sounds like a better approach. Do you think there is >>>>>> any chance to convince the COMEDIA folks to follow the same approach? >>>>>> >>>>>>> >>>>>>> Paul >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 12 16:37:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22585 for ; Mon, 12 Jan 2004 16:37:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9kS-0006Od-Cs for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 16:37:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CLbOS3024581 for mmusic-archive@odin.ietf.org; Mon, 12 Jan 2004 16:37:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9kR-0006OG-Ra for mmusic-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22553 for ; Mon, 12 Jan 2004 16:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9kP-00034g-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 16:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9ic-0002mU-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 16:35:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag9gY-0002SB-00 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 16:33:22 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ag9gR-0005mX-O4 for mmusic-web-archive@ietf.org; Mon, 12 Jan 2004 16:33:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9gD-0006BE-16; Mon, 12 Jan 2004 16:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9fc-0006Ah-Td for mmusic@optimus.ietf.org; Mon, 12 Jan 2004 16:32:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21766 for ; Mon, 12 Jan 2004 16:32:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9fa-0002Ir-00 for mmusic@ietf.org; Mon, 12 Jan 2004 16:32:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9dT-0001zN-00 for mmusic@ietf.org; Mon, 12 Jan 2004 16:30:11 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9b5-0001WH-00 for mmusic@ietf.org; Mon, 12 Jan 2004 16:27:43 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0CLR0m21717; Mon, 12 Jan 2004 16:27:00 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZMGN4RC4; Mon, 12 Jan 2004 16:27:01 -0500 Received: from nortelnetworks.com (acart1e1.ca.nortel.com [47.129.129.110]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWN2TS; Mon, 12 Jan 2004 16:27:00 -0500 Message-ID: <4003111E.5000008@nortelnetworks.com> Date: Mon, 12 Jan 2004 16:26:54 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen CC: mmusic@ietf.org, Colin Perkins , rkumar@cisco.com, Joerg Ott References: <3EB7A12B.C7F4F830@cisco.com> In-Reply-To: <3EB7A12B.C7F4F830@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-rajeshkumar-mmusic-gpmd-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The IESG ID tracker shows that the IESG requested changes to draft-rajeshkumar-mmusic-gpmd-03.txt. What was the nature of those changes, and where does the process stand? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jan 13 18:13:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21013 for ; Tue, 13 Jan 2004 18:13:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXiH-0001IB-6i for mmusic-archive@odin.ietf.org; Tue, 13 Jan 2004 18:12:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DNCjfU004963 for mmusic-archive@odin.ietf.org; Tue, 13 Jan 2004 18:12:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXiH-0001Hy-1r for mmusic-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 18:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20948 for ; Tue, 13 Jan 2004 18:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXiE-0004mb-00 for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 18:12:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXgq-0004i4-00 for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 18:11:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgXef-0004eD-00 for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 18:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXef-00015m-Qg; Tue, 13 Jan 2004 18:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXeG-00014T-Is for mmusic@optimus.ietf.org; Tue, 13 Jan 2004 18:08:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20537 for ; Tue, 13 Jan 2004 18:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXeD-0004bY-00 for mmusic@ietf.org; Tue, 13 Jan 2004 18:08:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXcJ-0004Ya-00 for mmusic@ietf.org; Tue, 13 Jan 2004 18:06:36 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AgXbW-0004VW-00 for mmusic@ietf.org; Tue, 13 Jan 2004 18:05:46 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2004 15:07:10 +0000 Received: from mbaugher-w2k07.cisco.com (sjc-vpn4-432.cisco.com [10.21.81.176]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i0DN59Qv002938; Tue, 13 Jan 2004 15:05:10 -0800 (PST) Message-Id: <6.0.0.22.2.20040113130519.03b82e38@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 13 Jan 2004 15:05:00 -0800 To: mmusic@ietf.org From: Mark Baugher Subject: Re: [MMUSIC] Re: Commetns on draft-ietf-mmusic-sdescriptions-02.txt Cc: Magnus Westerlund , Flemming Andreasen , Dan Wing , csp@isi.edu In-Reply-To: <6.0.0.22.2.20031213175329.03c4fd80@mira-sjc5-6.cisco.com> References: <3FD9B7EB.6000500@ericsson.com> <6.0.0.22.2.20031213175329.03c4fd80@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,RISK_FREE autolearn=no version=2.60 Magnus, All I wanted to refine my point about removing multicast from SDP security descriptions to be much more specific: We want to address only pairwise connections in sdescriptions. So this excludes from consideration multiple unicast endpoints in a multimedia session. We have discussed this with several people, and Colin suggested that we take this change to the mmusic list. The rationale for excluding multicast applies to everything that is not strictly pairwise: There is a lot group-security and SRTP-synchronization complexity that needs to be considered in a separate, non-trivial effort. We want to make this change because of a need to apply this specification to pairwise connections first and foremost. The only non-multicast feature that we know is affected by restricting our focus to pairwise connections is SIP forking, particularly with early media. The implication here is that we will not support this application with the pairwise SDP security descriptions spec. The pairwise sdescriptions should be consistent with future extensions to groups of endpoints - one of our added goals if we make this change. best regards, Mark At 05:57 PM 12/13/2003, Mark Baugher wrote: >Magnus, > My co-authors and I will address your issues prior to the next version > of the I-D, which we should submit within the next several weeks. > > I have one comment, however, and that concerns your comments on > multicast. We proposed to the last Wg meeting to drop multicast from the > draft altogether and focus just on the unicast - as a divide and conquer > strategy. I expect multicast functionality to be added in a subsequent > draft when people are actively designing systems to support it. > > This proposal was posted in the WG minutes to this list and I have > heard no dissent from anyone. > >cheers, Mark >At 04:43 AM 12/12/2003, Magnus Westerlund wrote: >>Hi, >> >>I have know read the draft and has thought about most of the open issues >>that the draft presents and the discussion during the IETF meeting. There >>are a couple of points below that, especially 5, that I believe requires >>further discussion and study. >> >> >>1. As a general thing I think authors should think about how the pages >>get clipped by the pages. For improved readability one should move any >>new sections, etc. that only gets a few line to the next page. One such >>example is to start the table of contents on the first page, instead of >>on the second. Another if the section 4 heading that are sole on the last >>line of a page. >> >>2. The table contents may be a bit to detailed, I would think that it >>would be acceptable to remove all third level items. >> >>3. The introduction contains a normative MUST. I don't think this is >>really appropriate. Please find another place to locate this normative >>text after the introduction. >> >>4. In the last paragraph of section 2, I think this section would benefit >>of being split into two paragraphs. >> >>5. I think that one must look over the multicast cases and divide them >>into different use cases. I think that removing all the multicast is a >>bad choice as there are situation where it seems to work. I would start >>by dividing the usage into scenarios where one can use the a=crypto >>successfully. >> >>- The one to many, using ASM case. This is a advertisement case. Only the >>intended sender declares his SSRC/ROC/SEQ to ensure that all receivers >>does not use the senders SSRC and causes a two time pad with it. As all >>receivers are unsynchronized unless other mechanism is used, there might >>happen SSRC collisions. However if you either don't encrypt the RTCP, >>which is the only thing they will send, it is not a problem. Also if RTCP >>encryption is used, it might be deemed acceptable with the low risk of >>two time pads that exist. However this is clearly a security trade off. >> >>- The one to many, using SSM, as the receivers can't send to anybody else >>there is no problem. If one uses unicast RTCP feedback, the same security >>consideration regarding RTCP two time pads apply, however the >>distribution of the offending packets will not be the same as for ASM use >>cases. >> >>- The multicast conference case, with a central session control instance. >>As all participants speak only with the central control entity it can >>ensure that SSRC, collision is avoided if the same key are used. However >>in this case it is probably better to use individual master keys for each >>sender. However there seems to be some need to fix the a=crypto syntax to >>support this case. >> >>- The multicast conference, each sender announces there attributes >>individually to each participant. In this case all should be required to >>use individual master keys. Thus there is no risk for two time pads. >> >>As I see it with a few changes to the a=crypto attribute multicast can be >>fixed. However there is need to flesh out the scenarios and ensure that >>the signalling works for these. >> >>So as a conclusion there is need for more work in the multicast >>environment. Also statement as the second bullet in 4.1.1.2 is not correct. >> >>6. void >> >>7. Section 5.1.1.1 the example line includes a extra "<" at the >>"lifetime" parameter. >> >>8. Section 5.1.1.1: How does one know what type of key that is specified >>in the key field. To my understanding there are a possibility for at >>least three different levels of keys in SRTP. A top level master key, a >>master key for a single SSRC, individual keys for streams. There is >>currently no way of differentiating or requiring a key to be of a certain type. >> >>9. In section 5.1.1.1 there is a rule that the key length must be correct >>for the signalled length. However a BASE64 encoded key|salt combination >>may need some padding. So I assume that key lengths changing it to up to >>the next base64 boundary is okay. >> >>10. Section 5.1.1.1: The lifetime parameter "from-to" is not clear about >>how the number of packets are calculated and applies to. Is this the >>total number of packets a master key can be used for, or does it applies >>to any derived key, and when one of the derived keys reach this number it >>needs to rekey? I don't think the text in section 5.3.1 really helps >>either, as it makes it impossible for individual participants to actually >>calculate how many packets that has been used by the master key. >> >>11. Section 5.2, I think this section could gain by an table that >>tabulates the crypto suits and its major parameters for easy access >>instead of the description. >> >>12. Section 5.3.1: The SRC parameter I think need to be better >>clarified. If one gives a ROC/SEQ is given, it MUST be given in relation >>to the SSRC for which it is valid. >> >>13. When it comes to offer answer for multicast, it must be made clear >>how one uses SRC to ensure that a joining participant selects a SSRC that >>will not collide. >> >>14. Section 5.3.1, what is an invalid SSRC? How do you know. >> >>15. How is the the usage of late binding and shared master key indicated, >>to allow a receiver to determine what is used. >> >>16. Section 5.3.2, It says that 2^0 is 1, as this being a frequency, key >>derivation should be performed every packet. I would recommend to remove >>this wrong motivation, and simply state it as being an exception. >> >>17. In 6.1.1.2 you have a restriction that from-to must only be used in >>"recvonly", doesn't this depend on the scoping of these attributes. As >>pointed out in point 10, the from to context is not clear. >> >>18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one? >> >>19. In 6.1.2.1 Shouldn't there be a rule requiring the use of SRC with >>SSRC when common master key is used. >> >>20. In 6.1.2.1, Before the open issue, there is a statement that the is >>no need for optional parameters. I think this is not, true or what is >>meant with optional parameters must be clarified, there are certain use >>case that definitely will require use of certain parameters. >> >>21. In 6.1.3.2 , there is text saying that session parameters shall be >>ignored, I don't agree with that. >> >>22. In 6.1.3, In the paragraph after the bullets, one may get the >>impression that multiple sources only are needed in multicast. That is >>not true. Also in unicast a single end-point may need to use multiple >>SSRCs, for example for retransmission. >> >>23. In 7.3, I think the RECOMMEND to use a key management protocol if not >>carried in authenticated and encrypted transport format, should be a SHOULD. >> >>24, Section 7.3, Question, How does one know that the signalling over >>network (b) even is encrypted. >> >>25. Section 8: "key-params" does not need to be recursively defined, the >>second "key-params", needs only to be a "key-param" >> >>26. Section 8.1: key-method-ext, isn't this a "token"? I think >>restricting the usage of other special characters then "_" is possibly to >>restricted. >> >>27. Section 8.2, is really decimal form for SSRC the best form. I would >>recommend a format in hex instead, e.g. 8*HEX, as an SSRC really is a 32 >>bit binary identifier, not a number in its normal sense. >> >>28. Section 10.2.1, I think that you should review the standard IANA >>registration levels in RFC 2434, I think that for the key method, it is >>probably, "standards action" that is the right one. >> >>29. Section 10.2.2: I don't think that SRTP crypto suit registrations >>needs only to take "inline" into consideration. I think it should say >>that it should be defined in relation to applicable key-methods. I also >>think that the IANA section should be a bit more explicit what really is >>required. >> >> >>Cheers >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jan 13 22:59:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01236 for ; Tue, 13 Jan 2004 22:59:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgcB3-0004yJ-5M for mmusic-archive@odin.ietf.org; Tue, 13 Jan 2004 22:58:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E3wj1m019107 for mmusic-archive@odin.ietf.org; Tue, 13 Jan 2004 22:58:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgcB3-0004y6-0o for mmusic-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 22:58:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01150 for ; Tue, 13 Jan 2004 22:58:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgcAz-0000JO-00 for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 22:58:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agc9C-0000CI-00 for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 22:56:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Agc88-00007c-00 for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 22:55:44 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Agbvr-00076a-9j for mmusic-web-archive@ietf.org; Tue, 13 Jan 2004 22:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agbvp-0004VP-5N; Tue, 13 Jan 2004 22:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbvH-0004Q1-2h for mmusic@optimus.ietf.org; Tue, 13 Jan 2004 22:42:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00749 for ; Tue, 13 Jan 2004 22:42:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgbvD-0007fW-00 for mmusic@ietf.org; Tue, 13 Jan 2004 22:42:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgbtG-0007Yz-00 for mmusic@ietf.org; Tue, 13 Jan 2004 22:40:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Agboz-0007Oo-00 for mmusic@ietf.org; Tue, 13 Jan 2004 22:35:57 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2004 19:35:50 -0800 Received: from cisco.com (sjc-vpn3-669.cisco.com [10.21.66.157]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i0E3ZDQu009953; Tue, 13 Jan 2004 19:35:14 -0800 (PST) Message-ID: <4004B8F1.7BC3FC2@cisco.com> Date: Tue, 13 Jan 2004 22:35:13 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: mmusic@ietf.org, Colin Perkins , rkumar@cisco.com, Joerg Ott References: <3EB7A12B.C7F4F830@cisco.com> <4003111E.5000008@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: draft-rajeshkumar-mmusic-gpmd-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At the risk of misrepresenting the IESG, let me offer my interpretation of the comments we got from the IESG: 1. Concerns about the mechanism itself inasmuch as it may be (mis)used to essentially redefine the meaning of an otherwise well-defined MIME type. You may also have general "bucket" MIME types, the meaning of which depend on parameters provided by something like gpmd. There are some concerns with what that means for interoperability. 2. Overlap with existing media feature tagging mechanims defined in RFCs 2533, 2534, 2912, 2938, and 2987 The authors have yet to figure out if and how those issues should be resolved. One option is simply to kill the draft and just fallback to the specifc vbd-definition already provided in ITU-T Recommendation V.150.1. The intent with the draft of course was precisely not to do that, but considering that the vbd-definition is really all we were after, this may be getting into being a bit of an overkill. The only "real" issue that would leave us with is getting the parameter registered, and although Standards Track RFCs are preferred for that, sdp-new does permit attributes to be registered per the "Specification Required" policy; for at least the vbd-specific usage of gpmd, I believe we would be close enough to pass that bar. -- Flemming Tom Taylor wrote: > The IESG ID tracker shows that the IESG requested changes to > draft-rajeshkumar-mmusic-gpmd-03.txt. What was the nature of those > changes, and where does the process stand? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 14 14:05:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03482 for ; Wed, 14 Jan 2004 14:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqK3-0000vG-CS for mmusic-archive@odin.ietf.org; Wed, 14 Jan 2004 14:04:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EJ4xsN003545 for mmusic-archive@odin.ietf.org; Wed, 14 Jan 2004 14:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqK3-0000v6-8y for mmusic-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 14:04:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03472 for ; Wed, 14 Jan 2004 14:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgqK0-0002uH-00 for mmusic-web-archive@ietf.org; Wed, 14 Jan 2004 14:04:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgqJ9-0002s9-00 for mmusic-web-archive@ietf.org; Wed, 14 Jan 2004 14:04:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgqIA-0002qH-00 for mmusic-web-archive@ietf.org; Wed, 14 Jan 2004 14:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqI9-0000n2-24; Wed, 14 Jan 2004 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqI3-0000mq-ME for mmusic@optimus.ietf.org; Wed, 14 Jan 2004 14:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03421 for ; Wed, 14 Jan 2004 14:02:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgqI1-0002p7-00 for mmusic@ietf.org; Wed, 14 Jan 2004 14:02:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgqH5-0002np-00 for mmusic@ietf.org; Wed, 14 Jan 2004 14:01:56 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AgqGr-0002mm-00 for mmusic@ietf.org; Wed, 14 Jan 2004 14:01:41 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0EJ0e422685; Wed, 14 Jan 2004 14:00:41 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZMGN56D8; Wed, 14 Jan 2004 14:00:41 -0500 Received: from nortelnetworks.com (acart1bz.ca.nortel.com [47.129.129.42]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNJLA; Wed, 14 Jan 2004 14:00:40 -0500 Message-ID: <400591D8.4070204@nortelnetworks.com> Date: Wed, 14 Jan 2004 14:00:40 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen , mmusic@ietf.org References: <3EB7A12B.C7F4F830@cisco.com> <4003111E.5000008@nortelnetworks.com> <4004B8F1.7BC3FC2@cisco.com> In-Reply-To: <4004B8F1.7BC3FC2@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: draft-rajeshkumar-mmusic-gpmd-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the update. I did see Ned Freed's remarks on the IESG I-D tracker, but wasn't sure if they were the cause of the remit to the authors. I know we've been there before, but one quick fix would be to add a parameter to the PCMU and PCMA MIME types to indicate voice-band data. Flemming Andreasen wrote: > At the risk of misrepresenting the IESG, let me offer my interpretation > of the comments we got from the IESG: > > 1. Concerns about the mechanism itself inasmuch as it may be (mis)used > to essentially redefine the meaning of an otherwise well-defined MIME > type. You may also have general "bucket" MIME types, the meaning of > which depend on parameters provided by something like gpmd. There are > some concerns with what that means for interoperability. > 2. Overlap with existing media feature tagging mechanims defined in RFCs > 2533, 2534, 2912, 2938, and 2987 > > The authors have yet to figure out if and how those issues should be > resolved. One option is simply to kill the draft and just fallback to > the specifc vbd-definition already provided in ITU-T Recommendation > V.150.1. The intent with the draft of course was precisely not to do > that, but considering that the vbd-definition is really all we were > after, this may be getting into being a bit of an overkill. The only > "real" issue that would leave us with is getting the parameter > registered, and although Standards Track RFCs are preferred for that, > sdp-new does permit attributes to be registered per the "Specification > Required" policy; for at least the vbd-specific usage of gpmd, I believe > we would be close enough to pass that bar. > > -- Flemming > > > Tom Taylor wrote: > > >>The IESG ID tracker shows that the IESG requested changes to >>draft-rajeshkumar-mmusic-gpmd-03.txt. What was the nature of those >>changes, and where does the process stand? > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 14 21:31:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27042 for ; Wed, 14 Jan 2004 21:31:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxHx-0000Qb-HD for mmusic-archive@odin.ietf.org; Wed, 14 Jan 2004 21:31:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F2VHfs001641 for mmusic-archive@odin.ietf.org; Wed, 14 Jan 2004 21:31:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxHx-0000QO-DV for mmusic-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 21:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27022 for ; Wed, 14 Jan 2004 21:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxHu-00005L-00 for mmusic-web-archive@ietf.org; Wed, 14 Jan 2004 21:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxGv-00002n-00 for mmusic-web-archive@ietf.org; Wed, 14 Jan 2004 21:30:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgxGi-00000i-00 for mmusic-web-archive@ietf.org; Wed, 14 Jan 2004 21:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxGj-00009Y-9t; Wed, 14 Jan 2004 21:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxGN-00005Y-AJ for mmusic@optimus.ietf.org; Wed, 14 Jan 2004 21:29:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26939 for ; Wed, 14 Jan 2004 21:29:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxGK-0007nd-00 for mmusic@ietf.org; Wed, 14 Jan 2004 21:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxF2-0007lQ-00 for mmusic@ietf.org; Wed, 14 Jan 2004 21:28:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AgxEM-0007gx-00 for mmusic@ietf.org; Wed, 14 Jan 2004 21:27:34 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2004 18:27:14 -0800 Received: from cisco.com (sjc-vpn2-20.cisco.com [10.21.112.20]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0F2R2jQ021481; Wed, 14 Jan 2004 18:27:02 -0800 (PST) Message-ID: <4005FA75.4518F92A@cisco.com> Date: Wed, 14 Jan 2004 21:27:01 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: mmusic@ietf.org Subject: Re: [MMUSIC] Re: draft-rajeshkumar-mmusic-gpmd-03.txt References: <3EB7A12B.C7F4F830@cisco.com> <4003111E.5000008@nortelnetworks.com> <4004B8F1.7BC3FC2@cisco.com> <400591D8.4070204@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Taylor wrote: > Thanks for the update. I did see Ned Freed's remarks on the IESG I-D tracker, but > wasn't sure if they were the cause of the remit to the authors. > > I know we've been there before, but one quick fix would be to add a parameter to > the PCMU and PCMA MIME types to indicate voice-band data. > It wouldn't address the V.150.1 issue though, which is already using the gpmd parameter. Also, some medium bw codecs are capable of passing lower-rate modulations inband, so you could still support voice-band data with codecs other than PCMU and PCMA. Admittedly, the set of relevant codecs is fairly manageable in practice, but it would be nice to have a general parameter to address it. -- Flemming > > Flemming Andreasen wrote: > > > At the risk of misrepresenting the IESG, let me offer my interpretation > > of the comments we got from the IESG: > > > > 1. Concerns about the mechanism itself inasmuch as it may be (mis)used > > to essentially redefine the meaning of an otherwise well-defined MIME > > type. You may also have general "bucket" MIME types, the meaning of > > which depend on parameters provided by something like gpmd. There are > > some concerns with what that means for interoperability. > > 2. Overlap with existing media feature tagging mechanims defined in RFCs > > 2533, 2534, 2912, 2938, and 2987 > > > > The authors have yet to figure out if and how those issues should be > > resolved. One option is simply to kill the draft and just fallback to > > the specifc vbd-definition already provided in ITU-T Recommendation > > V.150.1. The intent with the draft of course was precisely not to do > > that, but considering that the vbd-definition is really all we were > > after, this may be getting into being a bit of an overkill. The only > > "real" issue that would leave us with is getting the parameter > > registered, and although Standards Track RFCs are preferred for that, > > sdp-new does permit attributes to be registered per the "Specification > > Required" policy; for at least the vbd-specific usage of gpmd, I believe > > we would be close enough to pass that bar. > > > > -- Flemming > > > > > > Tom Taylor wrote: > > > > > >>The IESG ID tracker shows that the IESG requested changes to > >>draft-rajeshkumar-mmusic-gpmd-03.txt. What was the nature of those > >>changes, and where does the process stand? > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jan 17 10:33:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10461 for ; Sat, 17 Jan 2004 10:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsRd-00066A-Uy for mmusic-archive@odin.ietf.org; Sat, 17 Jan 2004 10:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HFX54n023441 for mmusic-archive@odin.ietf.org; Sat, 17 Jan 2004 10:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsRd-000660-ON for mmusic-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 10:33:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10398 for ; Sat, 17 Jan 2004 10:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhsRa-0005ph-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:33:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhsQb-0005my-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:32:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhsPf-0005kW-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsPf-0005tV-3E; Sat, 17 Jan 2004 10:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZdq-00063z-31 for mmusic@optimus.ietf.org; Fri, 16 Jan 2004 14:28:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25704 for ; Fri, 16 Jan 2004 14:28:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZdn-0000A6-00 for mmusic@ietf.org; Fri, 16 Jan 2004 14:28:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZcr-00006x-00 for mmusic@ietf.org; Fri, 16 Jan 2004 14:27:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhZc3-00003J-00; Fri, 16 Jan 2004 14:26:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GJQ4gW018022; Fri, 16 Jan 2004 13:26:15 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40083AC6.4000101@dynamicsoft.com> Date: Fri, 16 Jan 2004 13:25:58 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> In-Reply-To: <400305C5.10009@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am fond of the choice of "connection:xx" if we are going to include it in the initial SDP--simply because it does not offer quite as much cognitive dissonance as discovering a "reconnect:xx" when one has not yet connected for the first time. Paul Kyzivat wrote: > > > David Yon wrote: > >> >> "reconnect:NNN" would probably be a useful enhancement to "reconnect", >> and if connection reestablishment was the goal of "version", then I >> would vote for that. > > > That is certainly the driving force behind it at the moment. > Unless someone can envision another use then I am happy to go along with > this. > >> The only issue would be that of the original SDP exchange. It hardly >> seems appropriate to include a "reconnect" attribute in the initial >> exchange, but then when you want to negotiate a new connection and >> suddenly this attribute appears, what's the appropriate value for >> NNN? A couple of possibilities: >> >> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make >> it mandatory. >> >> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >> Therefore the first reconnection negotiation would have "a=reconnect:1". >> >> c) Make the omission imply "a=reconnect:", such that the first >> appearance of "reconnect" would be "a=reconnect:0". >> >> I would guess that (a) makes the most sense. Thoughts? > > > That seems reasonable. > > In practice the number doesn't mean much except that it change. It would > work as well if it were an opaque token. > > When considered as a version number it makes more sense as an increasing > number. > > How about a=connection:NNN? (With a default of 1.) This numbers the > connections used to convey the media stream. This is clearly associated > with connections, so it isn't prone to abuse, and it also conveys a > clear semantic for the number. > >> Also, are there any possibilities of race conditions where the NNN >> would get out of sync between the two endpoints? If so, how would >> that be resolved? > > > I don't believe there are any race conditions, though there is always > the possibility of buggy endpoint getting confused. > > I don't think there are any race conditions because NNN isn't negotiated > - it is always managed by one end and conveyed to the other end. In an > offer/answer exchange, each side could conceivably provide its own value > for a=reconnect:NNN. It is only meaningful when provided by a passive > end to an active end, because it determines whether the active end > should reconnect. > > In the case of MSRP, there is only one connection, so reconnection only > makes sense in the direction of the original connection. > > In the case of comedia there could conceivably be two connections, one > in each direction. If so, it is conceivable that an offer/answer > exchange could have a=reconnect=NNN going both ways, and resulting in > zero, one, or two reconnections. > >> What about the additional state that must be tracked (the reconnection >> number)? I don't think that comedia-05 represents any additional >> state over connectionless media, which wouldn't be true for >> "reconnect:NNN". > > > There is extra implicit state in comedia. It must remember active, > passive, or both, whether still listening if passive, whether connected > if active, and ultimately the connection itself must be remembered as > state. This adds a number that must be associated with the connection. > Doesn't seem like a big burden. > >>> Paul >>> >>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>> >>>>> My attempts to reach David Yon at the address he has listed in the >>>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>>> exists? >>>>> >>>>> Paul >>>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> Ben, >>>>>> I'm copying David Yon on this since he is author of comedia. This >>>>>> probably won't make any sense out of context to him, so I will >>>>>> separately send him some of the earlier discussion. >>>>>> I don't recall what the current status of comedia is. It is >>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>> goals listed for it. >>>>>> Paul >>>>>> Ben Campbell wrote: >>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ben Campbell wrote: >>>>>>>> >>>>>>>>> (More comments on same email...) >>>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>>> whatever. But it also does leave the problem of distinguishing >>>>>>>>>> a "reconnect" offer from a "don't change anything" offer. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>> as I hoped it would. While it does mean you have to do something >>>>>>>> special (add the a=reconnect) attribute to cause a reconnect, >>>>>>>> having done that once you then have to do something else (remove >>>>>>>> the a=reconnect) in a subsequent exchange. >>>>>>>> >>>>>>>> I think it would be better if there were something like >>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>> particular media session. Then whenever it changes you >>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>> from the o-line. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that sounds like a better approach. Do you think there is >>>>>>> any chance to convince the COMEDIA folks to follow the same >>>>>>> approach? >>>>>>> >>>>>>>> >>>>>>>> Paul >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jan 17 10:33:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10464 for ; Sat, 17 Jan 2004 10:33:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsRe-00066X-MU for mmusic-archive@odin.ietf.org; Sat, 17 Jan 2004 10:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HFX6fE023459 for mmusic-archive@odin.ietf.org; Sat, 17 Jan 2004 10:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsRe-00066I-B7 for mmusic-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 10:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10407 for ; Sat, 17 Jan 2004 10:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhsRb-0005pm-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhsQc-0005n6-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:32:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhsPf-0005kX-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsPf-0005tn-Ly; Sat, 17 Jan 2004 10:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZsa-0007Bn-UT for mmusic@optimus.ietf.org; Fri, 16 Jan 2004 14:43:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26390 for ; Fri, 16 Jan 2004 14:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZsY-0000xF-00 for mmusic@ietf.org; Fri, 16 Jan 2004 14:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZrZ-0000sc-00 for mmusic@ietf.org; Fri, 16 Jan 2004 14:42:38 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhZqh-0000pA-00; Fri, 16 Jan 2004 14:41:43 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GJfWgW019444; Fri, 16 Jan 2004 13:41:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40083E66.3020903@dynamicsoft.com> Date: Fri, 16 Jan 2004 13:41:26 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> <40083AC6.4000101@dynamicsoft.com> In-Reply-To: <40083AC6.4000101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit However, on reflection, I wonder why we would make this a separate a-line attribute, rather than a parameter on the direction attribute. The whole purpose of the direction attribute is to specify how the connection is set up. Indicating a desire for a new connection seems to fit well into that purpose. Ben Campbell wrote: > I am fond of the choice of "connection:xx" if we are going to include it > in the initial SDP--simply because it does not offer quite as much > cognitive dissonance as discovering a "reconnect:xx" when one has not > yet connected for the first time. > > Paul Kyzivat wrote: > >> >> >> David Yon wrote: >> >>> >>> "reconnect:NNN" would probably be a useful enhancement to >>> "reconnect", and if connection reestablishment was the goal of >>> "version", then I would vote for that. >> >> >> >> That is certainly the driving force behind it at the moment. >> Unless someone can envision another use then I am happy to go along >> with this. >> >>> The only issue would be that of the original SDP exchange. It hardly >>> seems appropriate to include a "reconnect" attribute in the initial >>> exchange, but then when you want to negotiate a new connection and >>> suddenly this attribute appears, what's the appropriate value for >>> NNN? A couple of possibilities: >>> >>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make >>> it mandatory. >>> >>> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >>> Therefore the first reconnection negotiation would have "a=reconnect:1". >>> >>> c) Make the omission imply "a=reconnect:", such that the first >>> appearance of "reconnect" would be "a=reconnect:0". >>> >>> I would guess that (a) makes the most sense. Thoughts? >> >> >> >> That seems reasonable. >> >> In practice the number doesn't mean much except that it change. It >> would work as well if it were an opaque token. >> >> When considered as a version number it makes more sense as an >> increasing number. >> >> How about a=connection:NNN? (With a default of 1.) This numbers the >> connections used to convey the media stream. This is clearly >> associated with connections, so it isn't prone to abuse, and it also >> conveys a clear semantic for the number. >> >>> Also, are there any possibilities of race conditions where the NNN >>> would get out of sync between the two endpoints? If so, how would >>> that be resolved? >> >> >> >> I don't believe there are any race conditions, though there is always >> the possibility of buggy endpoint getting confused. >> >> I don't think there are any race conditions because NNN isn't >> negotiated - it is always managed by one end and conveyed to the other >> end. In an offer/answer exchange, each side could conceivably provide >> its own value for a=reconnect:NNN. It is only meaningful when provided >> by a passive end to an active end, because it determines whether the >> active end should reconnect. >> >> In the case of MSRP, there is only one connection, so reconnection >> only makes sense in the direction of the original connection. >> >> In the case of comedia there could conceivably be two connections, one >> in each direction. If so, it is conceivable that an offer/answer >> exchange could have a=reconnect=NNN going both ways, and resulting in >> zero, one, or two reconnections. >> >>> What about the additional state that must be tracked (the >>> reconnection number)? I don't think that comedia-05 represents any >>> additional state over connectionless media, which wouldn't be true >>> for "reconnect:NNN". >> >> >> >> There is extra implicit state in comedia. It must remember active, >> passive, or both, whether still listening if passive, whether >> connected if active, and ultimately the connection itself must be >> remembered as state. This adds a number that must be associated with >> the connection. Doesn't seem like a big burden. >> >>>> Paul >>>> >>>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>>> >>>>>> My attempts to reach David Yon at the address he has listed in the >>>>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>>>> exists? >>>>>> >>>>>> Paul >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> Ben, >>>>>>> I'm copying David Yon on this since he is author of comedia. This >>>>>>> probably won't make any sense out of context to him, so I will >>>>>>> separately send him some of the earlier discussion. >>>>>>> I don't recall what the current status of comedia is. It is >>>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>>> goals listed for it. >>>>>>> Paul >>>>>>> Ben Campbell wrote: >>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ben Campbell wrote: >>>>>>>>> >>>>>>>>>> (More comments on same email...) >>>>>>>>>> >>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>>>> whatever. But it also does leave the problem of >>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change >>>>>>>>>>> anything" offer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>>> as I hoped it would. While it does mean you have to do >>>>>>>>> something special (add the a=reconnect) attribute to cause a >>>>>>>>> reconnect, having done that once you then have to do something >>>>>>>>> else (remove the a=reconnect) in a subsequent exchange. >>>>>>>>> >>>>>>>>> I think it would be better if there were something like >>>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>>> particular media session. Then whenever it changes you >>>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>>> from the o-line. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I agree that sounds like a better approach. Do you think there >>>>>>>> is any chance to convince the COMEDIA folks to follow the same >>>>>>>> approach? >>>>>>>> >>>>>>>>> >>>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jan 17 10:33:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10498 for ; Sat, 17 Jan 2004 10:33:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsRk-00066x-Nr for mmusic-archive@odin.ietf.org; Sat, 17 Jan 2004 10:33:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HFXCfJ023485 for mmusic-archive@odin.ietf.org; Sat, 17 Jan 2004 10:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsRk-00066i-JE for mmusic-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 10:33:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10415 for ; Sat, 17 Jan 2004 10:33:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhsRc-0005pr-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:33:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhsQd-0005nE-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:32:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhsPf-0005kY-00 for mmusic-web-archive@ietf.org; Sat, 17 Jan 2004 10:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhsPe-0005tK-H0; Sat, 17 Jan 2004 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXng-0006cV-6r for mmusic@optimus.ietf.org; Fri, 16 Jan 2004 12:30:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22308 for ; Fri, 16 Jan 2004 12:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXne-00022o-00 for mmusic@ietf.org; Fri, 16 Jan 2004 12:30:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXmn-0001zS-00 for mmusic@ietf.org; Fri, 16 Jan 2004 12:29:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhXmK-0001vr-00; Fri, 16 Jan 2004 12:29:05 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GHSkgW007554; Fri, 16 Jan 2004 11:28:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40081F49.9080204@dynamicsoft.com> Date: Fri, 16 Jan 2004 11:28:41 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> <3FFD668E.4030709@cisco.com> In-Reply-To: <3FFD668E.4030709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the late reply--for some reason this just showed up in my inbox. (Or I just noticed it, anyway.) I don't see it as a problem to have MSRP mention that the ports must be distinct. We currently have a standard dummy value, rather than a random value. With this restriction, I think the answer is to say the sender can choose any legal non-zero value, and if multiple MSRP m-lines exist, they must have different port values. Is this sufficient? I don't see any reason to care about how a particular implementation goes about generating them. Paul Kyzivat wrote: > Hisham, > > I have an open mind about this right now. It seems to be a matter of > picking your favorite poison, since neither alternative is ideal: > - ensure that the ports used are unique even though they are ignored > - change SDP - something that is not very popular. > > So far, aside from me there are two votes, one on each side. From the > point of view of SIMPLE it is of course logistically simpler to leave > SDP alone. > > Paul > > P.S. It seems that simple wasn't on the mailing list, so I have added it. > > hisham.khartabil@nokia.com wrote: > >> I would hate to see exceptions like these when building a generic SDP >> parser with built it checks for compliancy. >> Why can't MSRP just follow that rule? >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>> ext Paul E. Jones >>> Sent: 07.January.2004 23:15 >>> To: Paul Kyzivat; Flemming Andreasen >>> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>> mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>> mgarakan@cisco.com >>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> Paul, >>> >>> While that sounds most unfortunate (I'd love to see an example if you >>> have >>> one), I think it would be exempt from this rule, because the port is >>> just a >>> dummy value. >>> >>> Paul >>> >>> ----- Original Message ----- From: "Paul Kyzivat" >>> To: "Flemming Andreasen" >>> Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>> ; "Stephen Casner" ; "Colin >>> Perkins" ; ; "Mostafa, Mohamed" >>> ; "Abdelhamid, Hisham" ; >>> ; >>> Sent: Wednesday, January 07, 2004 4:12 PM >>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>>> I recently encountered an interesting case relevant to this >>> >>> >>> while making >>> >>>> up an example for MSRP. >>>> >>>> In MSRP the port number is not used, except for the >>> >>> >>> distinction between >>> >>>> a zero and non-zero value. There is a requirement that some random >>>> non-zero value be inserted and then ignored. If there are >>> >>> >>> multiple MSRP >>> >>>> media sessions in the same SDP body, must they have differing port >>> >>> >>> numbers? >>> >>>> Paul >>>> >>>> Flemming Andreasen wrote: >>>> >>>>> "Kumar, Rajesh" wrote: >>>>> >>>>> >>>>> >>>>>> AVT members, >>>>>> >>>>>> There was some confusion on this issue in the recent TIA >>>>> >>>>> >>> TR.30.1 meeting >>> >>>>>> in Orlando, Florida. >>>>>> >>>>>> Could someone officially confirm or deny whether multiple >>>>> >>>>> >>> "m=" lines >>> >>>>>> with the SAME media type (e.g. "audio") and protocol >>>>> >>>>> >>> (e.g. RTP/AVP) >>> >>>>>> cannot be assigned the same port number? >>>>> >>>>> >>>>> >>>>> The consensus of this discussion is that is that they >>>> >>>> >>> cannot (assuming >>> they >>> >>>>> use the same IP address). >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>> >>>>>> If they can be assigned the >>>>>> same port number, then it is possible to selectively >>>>> >>>>> >>> associate RFC 2733 >>> >>>>>> FEC with some payload types such as those that carry >>>>> >>>>> >>> voice band data. >>> >>>>>> Otherwise, there is a hole in SDP that does not permit selective, >>>>>> payload-specific declaration of FEC. I am aware of the >>>>> >>>>> >>> fact that in RFC >>> >>>>>> 2733 the use of and level of FEC is a transmitter >>>>> >>>>> >>> prerogative and that a >>> >>>>>> transmitter may choose to selectively utilize FEC based >>>>> >>>>> >>> on payload type >>> >>>>>> transmitted. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Rajesh >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>> Sent: Friday, December 12, 2003 4:21 AM >>>>>>> To: Kevin Boyle >>>>>>> Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>>> >>>>>> >>> mmusic@ietf.org; >>> >>>>>> Mostafa, Mohamed; >>>>>> >>>>>> >>>>>>> Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>>> >>>>>> >>> same port number >>> >>>>>>> >>>>>>> >>>>>>> Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Looking back at this email stream, one question remains >>>>>>> >>>>>>> >>> outstanding >>> >>>>>> in >>>>>> >>>>>> >>>>>>>> my mind: >>>>>>>> >>>>>>>> What if the two m= lines have the SAME media type? For >>>>>>> >>>>>>> >>> instance: >>> >>>>>>>> m=audio 49232 RTP/AVP 18 >>>>>>>> m=image 49233 UDPTL t38 >>>>>>>> m=audio 49232 RTP/AVP 100 >>>>>>>> a=rtpmap:100 PCMU/8000 >>>>>>>> a=gpmd:100 vbd=yes >>>>>>>> >>>>>>>> For some of the SDP-based protocols, the order of appearance is >>>>>>> >>>>>>> >>>>>> vital >>>>>> >>>>>> >>>>>>>> because it announces preference. >>>>>>> >>>>>>> >>>>>>> Only for the media formats within a given "m=" line. >>>>>> >>>>>> >>> Multiple "m=" >>> >>>>>> lines >>>>>> >>>>>> >>>>>>> indicates a set of simultaneous media streams; not alternatives. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So, this shows preference for T.38 fax relay over PCMU >>>>>>> >>>>>>> >>> VBD for fax, >>> >>>>>>>> while utilizing G.729 for voice. As far as I can tell, this >>>>>>> >>>>>>> >>>>>> construct >>>>>> >>>>>> >>>>>>>> is allowed, since both m lines using the same port number use a >>>>>>> >>>>>>> >>>>>> media >>>>>> >>>>>> >>>>>>>> type of audio. >>>>>>>> >>>>>>>> Is my understanding correct? >>>>>>>> >>>>>>> >>>>>>> Not quite. Each "m=" line corresponds to a separate media stream. >>>>>> >>>>>> >>>>>> Also, >>>>>> >>>>>> >>>>>>> the consensus of this discussion has been that you are >>>>>> >>>>>> >>> *not* allowed >>> >>>>>> to >>>>>> >>>>>> >>>>>>> use the same port for different media lines, regardless >>>>>> >>>>>> >>> of whether >>> >>>>>> they >>>>>> >>>>>> >>>>>>> share the same top-level MIME type or not. >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Kevin >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Stephen Casner [mailto:casner@acm.org] >>>>>>>> Sent: Friday, April 25, 2003 2:57 PM >>>>>>>> To: Rajesh Kumar >>>>>>>> Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>> mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>> paulej@cisco.com >>>>>>>> >>>>>>>> Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>>> >>>>>>> >>> port number >>> >>>>>>>> Rajesh, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Is the use of multiple 'm=' lines with the same port >>>>>>>> >>>>>>>> >>> number within >>> >>>>>>>> an >>>>>>>> >>>>>>>> >>>>>>>>> SDP descriptor permitted? >>>>>>>> >>>>>>>> >>>>>>>> Presuming that the multiple m= lines are all RTP/AVP, >>>>>>> >>>>>>> >>> then doing so >>> >>>>>>>> causes all of the payload formats listed on the m= >>>>>>> >>>>>>> >>> lines to become >>> >>>>>>>> part of a single RTP session (unless they are >>>>>>> >>>>>>> >>> distinguished by some >>> >>>>>>>> other aspect of addressing). Section 5.2 of the RTP >>>>>>> >>>>>>> >>> spec addresses >>> >>>>>>>> NOT multiplexing different media in the same RTP session. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>> >>>>>>>> >>>>>> are >>>>>> >>>>>> >>>>>>>> of >>>>>>>> >>>>>>>> >>>>>>>>> the same media type (e.g. audio, image, text etc.). >>>>>>>>> >>>>>>>>> Now consider the case in which two RTP media formats can use a >>>>>>>>> destination port but are registered under different MIME types. >>>>>>>> >>>>>>>> >>>>>> For >>>>>> >>>>>> >>>>>>>>> example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>> >>>>>>>> >>>>>>>> recourse >>>>>>>> >>>>>>>> >>>>>>>>> except to use multiple media lines with the same port >>>>>>>> >>>>>>>> >>> number. For >>> >>>>>>>> example: >>>>>>>> >>>>>>>> The "can use a destination port" is the tricky part. We may not >>>>>>>> agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> m=audio 49232 RTP/AVP 0 >>>>>>>>> m=text 49232 RTP/AVP 100 >>>>>>>>> a=rtpmap:100 t140 >>>>>>>>> >>>>>>>>> My thought is that although this is unsual, it is not >>>>>>>> >>>>>>>> >>> proscribed >>> >>>>>> by >>>>>> >>>>>> >>>>>>>>> SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>> >>>>>>>> >>>>>>>> I believe this is proscribed by section 5.2 of the RTP >>>>>>> >>>>>>> >>> spec because >>> >>>>>>>> these two media should not be multiplexed in one RTP session. >>>>>>>> >>>>>>>> My bet is that the real example you are thinking about is fax or >>>>>>> >>>>>>> >>>>>> modem >>>>>> >>>>>> >>>>>>>> over IP. We've been there before. >>>>>>>> >>>>>>>> -- Steve >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 19 13:59:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02248 for ; Mon, 19 Jan 2004 13:59:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiebm-0004c8-ON for mmusic-archive@odin.ietf.org; Mon, 19 Jan 2004 13:58:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JIwkBj017734 for mmusic-archive@odin.ietf.org; Mon, 19 Jan 2004 13:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiebm-0004bx-Kh for mmusic-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 13:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02237 for ; Mon, 19 Jan 2004 13:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiebg-0003zU-00 for mmusic-web-archive@ietf.org; Mon, 19 Jan 2004 13:58:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aieal-0003x3-00 for mmusic-web-archive@ietf.org; Mon, 19 Jan 2004 13:57:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiea4-0003vT-00 for mmusic-web-archive@ietf.org; Mon, 19 Jan 2004 13:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiea4-0004NY-N7; Mon, 19 Jan 2004 13:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieZm-0004N5-95 for mmusic@optimus.ietf.org; Mon, 19 Jan 2004 13:56:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02082 for ; Mon, 19 Jan 2004 13:56:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieZj-0003u3-00 for mmusic@ietf.org; Mon, 19 Jan 2004 13:56:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieYl-0003pm-00 for mmusic@ietf.org; Mon, 19 Jan 2004 13:55:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AieXp-0003ia-00; Mon, 19 Jan 2004 13:54:41 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0JIs5K8009376; Mon, 19 Jan 2004 13:54:07 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ03756; Mon, 19 Jan 2004 13:54:05 -0500 (EST) Message-ID: <400C27CC.3030307@cisco.com> Date: Mon, 19 Jan 2004 13:54:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> <3FFD668E.4030709@cisco.com> <40081F49.9080204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben, I am inclined to agree that this is the most expedient way forward and not worth doing anything more. It offends my sense of elegance to require a value that is intended to be ignored, and offends it futher to insist that multiple instances must be distinct to be valid even though ignored. But still it is the lesser evil. Paul Ben Campbell wrote: > Sorry for the late reply--for some reason this just showed up in my > inbox. (Or I just noticed it, anyway.) > > I don't see it as a problem to have MSRP mention that the ports must be > distinct. We currently have a standard dummy value, rather than a random > value. With this restriction, I think the answer is to say the sender > can choose any legal non-zero value, and if multiple MSRP m-lines exist, > they must have different port values. Is this sufficient? I don't see > any reason to care about how a particular implementation goes about > generating them. > > Paul Kyzivat wrote: > >> Hisham, >> >> I have an open mind about this right now. It seems to be a matter of >> picking your favorite poison, since neither alternative is ideal: >> - ensure that the ports used are unique even though they are ignored >> - change SDP - something that is not very popular. >> >> So far, aside from me there are two votes, one on each side. From the >> point of view of SIMPLE it is of course logistically simpler to leave >> SDP alone. >> >> Paul >> >> P.S. It seems that simple wasn't on the mailing list, so I have added it. >> >> hisham.khartabil@nokia.com wrote: >> >>> I would hate to see exceptions like these when building a generic SDP >>> parser with built it checks for compliancy. >>> Why can't MSRP just follow that rule? >>> >>> Regards, >>> Hisham >>> >>> >>>> -----Original Message----- >>>> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>>> ext Paul E. Jones >>>> Sent: 07.January.2004 23:15 >>>> To: Paul Kyzivat; Flemming Andreasen >>>> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>>> mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>>> mgarakan@cisco.com >>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>> >>>> Paul, >>>> >>>> While that sounds most unfortunate (I'd love to see an example if >>>> you have >>>> one), I think it would be exempt from this rule, because the port is >>>> just a >>>> dummy value. >>>> >>>> Paul >>>> >>>> ----- Original Message ----- From: "Paul Kyzivat" >>>> To: "Flemming Andreasen" >>>> Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>>> ; "Stephen Casner" ; "Colin >>>> Perkins" ; ; "Mostafa, Mohamed" >>>> ; "Abdelhamid, Hisham" ; >>>> ; >>>> Sent: Wednesday, January 07, 2004 4:12 PM >>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>> >>>> >>>>> I recently encountered an interesting case relevant to this >>>> >>>> >>>> >>>> while making >>>> >>>>> up an example for MSRP. >>>>> >>>>> In MSRP the port number is not used, except for the >>>> >>>> >>>> >>>> distinction between >>>> >>>>> a zero and non-zero value. There is a requirement that some random >>>>> non-zero value be inserted and then ignored. If there are >>>> >>>> >>>> >>>> multiple MSRP >>>> >>>>> media sessions in the same SDP body, must they have differing port >>>> >>>> >>>> >>>> numbers? >>>> >>>>> Paul >>>>> >>>>> Flemming Andreasen wrote: >>>>> >>>>>> "Kumar, Rajesh" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> AVT members, >>>>>>> >>>>>>> There was some confusion on this issue in the recent TIA >>>>>> >>>>>> >>>>>> >>>> TR.30.1 meeting >>>> >>>>>>> in Orlando, Florida. >>>>>>> >>>>>>> Could someone officially confirm or deny whether multiple >>>>>> >>>>>> >>>>>> >>>> "m=" lines >>>> >>>>>>> with the SAME media type (e.g. "audio") and protocol >>>>>> >>>>>> >>>>>> >>>> (e.g. RTP/AVP) >>>> >>>>>>> cannot be assigned the same port number? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The consensus of this discussion is that is that they >>>>> >>>>> >>>>> >>>> cannot (assuming >>>> they >>>> >>>>>> use the same IP address). >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> If they can be assigned the >>>>>>> same port number, then it is possible to selectively >>>>>> >>>>>> >>>>>> >>>> associate RFC 2733 >>>> >>>>>>> FEC with some payload types such as those that carry >>>>>> >>>>>> >>>>>> >>>> voice band data. >>>> >>>>>>> Otherwise, there is a hole in SDP that does not permit selective, >>>>>>> payload-specific declaration of FEC. I am aware of the >>>>>> >>>>>> >>>>>> >>>> fact that in RFC >>>> >>>>>>> 2733 the use of and level of FEC is a transmitter >>>>>> >>>>>> >>>>>> >>>> prerogative and that a >>>> >>>>>>> transmitter may choose to selectively utilize FEC based >>>>>> >>>>>> >>>>>> >>>> on payload type >>>> >>>>>>> transmitted. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Rajesh >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>>> Sent: Friday, December 12, 2003 4:21 AM >>>>>>>> To: Kevin Boyle >>>>>>>> Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>>>> >>>>>>> >>>>>>> >>>> mmusic@ietf.org; >>>> >>>>>>> Mostafa, Mohamed; >>>>>>> >>>>>>> >>>>>>>> Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>>>> >>>>>>> >>>>>>> >>>> same port number >>>> >>>>>>>> >>>>>>>> >>>>>>>> Kevin Boyle wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Looking back at this email stream, one question remains >>>>>>>> >>>>>>>> >>>>>>>> >>>> outstanding >>>> >>>>>>> in >>>>>>> >>>>>>> >>>>>>>>> my mind: >>>>>>>>> >>>>>>>>> What if the two m= lines have the SAME media type? For >>>>>>>> >>>>>>>> >>>>>>>> >>>> instance: >>>> >>>>>>>>> m=audio 49232 RTP/AVP 18 >>>>>>>>> m=image 49233 UDPTL t38 >>>>>>>>> m=audio 49232 RTP/AVP 100 >>>>>>>>> a=rtpmap:100 PCMU/8000 >>>>>>>>> a=gpmd:100 vbd=yes >>>>>>>>> >>>>>>>>> For some of the SDP-based protocols, the order of appearance is >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> vital >>>>>>> >>>>>>> >>>>>>>>> because it announces preference. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Only for the media formats within a given "m=" line. >>>>>>> >>>>>>> >>>>>>> >>>> Multiple "m=" >>>> >>>>>>> lines >>>>>>> >>>>>>> >>>>>>>> indicates a set of simultaneous media streams; not alternatives. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> So, this shows preference for T.38 fax relay over PCMU >>>>>>>> >>>>>>>> >>>>>>>> >>>> VBD for fax, >>>> >>>>>>>>> while utilizing G.729 for voice. As far as I can tell, this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> construct >>>>>>> >>>>>>> >>>>>>>>> is allowed, since both m lines using the same port number use a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> media >>>>>>> >>>>>>> >>>>>>>>> type of audio. >>>>>>>>> >>>>>>>>> Is my understanding correct? >>>>>>>>> >>>>>>>> >>>>>>>> Not quite. Each "m=" line corresponds to a separate media stream. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, >>>>>>> >>>>>>> >>>>>>>> the consensus of this discussion has been that you are >>>>>>> >>>>>>> >>>>>>> >>>> *not* allowed >>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>>> use the same port for different media lines, regardless >>>>>>> >>>>>>> >>>>>>> >>>> of whether >>>> >>>>>>> they >>>>>>> >>>>>>> >>>>>>>> share the same top-level MIME type or not. >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Kevin >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Stephen Casner [mailto:casner@acm.org] >>>>>>>>> Sent: Friday, April 25, 2003 2:57 PM >>>>>>>>> To: Rajesh Kumar >>>>>>>>> Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>>> mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>>> paulej@cisco.com >>>>>>>>> >>>>>>>>> Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>>>> >>>>>>>> >>>>>>>> >>>> port number >>>> >>>>>>>>> Rajesh, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Is the use of multiple 'm=' lines with the same port >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> number within >>>> >>>>>>>>> an >>>>>>>>> >>>>>>>>> >>>>>>>>>> SDP descriptor permitted? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Presuming that the multiple m= lines are all RTP/AVP, >>>>>>>> >>>>>>>> >>>>>>>> >>>> then doing so >>>> >>>>>>>>> causes all of the payload formats listed on the m= >>>>>>>> >>>>>>>> >>>>>>>> >>>> lines to become >>>> >>>>>>>>> part of a single RTP session (unless they are >>>>>>>> >>>>>>>> >>>>>>>> >>>> distinguished by some >>>> >>>>>>>>> other aspect of addressing). Section 5.2 of the RTP >>>>>>>> >>>>>>>> >>>>>>>> >>>> spec addresses >>>> >>>>>>>>> NOT multiplexing different media in the same RTP session. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> are >>>>>>> >>>>>>> >>>>>>>>> of >>>>>>>>> >>>>>>>>> >>>>>>>>>> the same media type (e.g. audio, image, text etc.). >>>>>>>>>> >>>>>>>>>> Now consider the case in which two RTP media formats can use a >>>>>>>>>> destination port but are registered under different MIME types. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> For >>>>>>> >>>>>>> >>>>>>>>>> example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> recourse >>>>>>>>> >>>>>>>>> >>>>>>>>>> except to use multiple media lines with the same port >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> number. For >>>> >>>>>>>>> example: >>>>>>>>> >>>>>>>>> The "can use a destination port" is the tricky part. We may not >>>>>>>>> agree. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> m=audio 49232 RTP/AVP 0 >>>>>>>>>> m=text 49232 RTP/AVP 100 >>>>>>>>>> a=rtpmap:100 t140 >>>>>>>>>> >>>>>>>>>> My thought is that although this is unsual, it is not >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> proscribed >>>> >>>>>>> by >>>>>>> >>>>>>> >>>>>>>>>> SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I believe this is proscribed by section 5.2 of the RTP >>>>>>>> >>>>>>>> >>>>>>>> >>>> spec because >>>> >>>>>>>>> these two media should not be multiplexed in one RTP session. >>>>>>>>> >>>>>>>>> My bet is that the real example you are thinking about is fax or >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> modem >>>>>>> >>>>>>> >>>>>>>>> over IP. We've been there before. >>>>>>>>> >>>>>>>>> -- Steve >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mmusic mailing list >>>>>>>>> mmusic@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jan 19 14:26:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03456 for ; Mon, 19 Jan 2004 14:26:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif1y-0006F2-Bk for mmusic-archive@odin.ietf.org; Mon, 19 Jan 2004 14:25:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JJPoW5023986 for mmusic-archive@odin.ietf.org; Mon, 19 Jan 2004 14:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif1y-0006En-8A for mmusic-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 14:25:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03427 for ; Mon, 19 Jan 2004 14:25:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aif1q-0005zh-00 for mmusic-web-archive@ietf.org; Mon, 19 Jan 2004 14:25:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiewh-0005al-00 for mmusic-web-archive@ietf.org; Mon, 19 Jan 2004 14:20:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AietZ-0005Hj-00 for mmusic-web-archive@ietf.org; Mon, 19 Jan 2004 14:17:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AietQ-0005ao-D8; Mon, 19 Jan 2004 14:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiesZ-0005Y6-Dr for mmusic@optimus.ietf.org; Mon, 19 Jan 2004 14:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03014 for ; Mon, 19 Jan 2004 14:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiesS-0005CL-00 for mmusic@ietf.org; Mon, 19 Jan 2004 14:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieoN-0004tw-00 for mmusic@ietf.org; Mon, 19 Jan 2004 14:11:48 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AiekM-0004YM-00; Mon, 19 Jan 2004 14:07:38 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2004 11:07:16 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0JJ6QLE024772; Mon, 19 Jan 2004 14:06:27 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ05149; Mon, 19 Jan 2004 14:06:23 -0500 (EST) Message-ID: <400C2AAF.1060703@cisco.com> Date: Mon, 19 Jan 2004 14:06:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> <40083AC6.4000101@dynamicsoft.com> <40083E66.3020903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > However, on reflection, I wonder why we would make this a separate > a-line attribute, rather than a parameter on the direction attribute. > The whole purpose of the direction attribute is to specify how the > connection is set up. Indicating a desire for a new connection seems to > fit well into that purpose. If we use the same semantics as with a=connection:NNN then I am quite fine with it being bundled into the direction attribute. We will have to find some way to fit in the value NNN and disambiguate it from a timeout value. Complicated because I think both are optional. Or we could make NNN be mandatory. That isn't so annoying in this form. Paul > Ben Campbell wrote: > >> I am fond of the choice of "connection:xx" if we are going to include >> it in the initial SDP--simply because it does not offer quite as much >> cognitive dissonance as discovering a "reconnect:xx" when one has not >> yet connected for the first time. >> >> Paul Kyzivat wrote: >> >>> >>> >>> David Yon wrote: >>> >>>> >>>> "reconnect:NNN" would probably be a useful enhancement to >>>> "reconnect", and if connection reestablishment was the goal of >>>> "version", then I would vote for that. >>> >>> >>> >>> >>> That is certainly the driving force behind it at the moment. >>> Unless someone can envision another use then I am happy to go along >>> with this. >>> >>>> The only issue would be that of the original SDP exchange. It >>>> hardly seems appropriate to include a "reconnect" attribute in the >>>> initial exchange, but then when you want to negotiate a new >>>> connection and suddenly this attribute appears, what's the >>>> appropriate value for NNN? A couple of possibilities: >>>> >>>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and >>>> make it mandatory. >>>> >>>> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >>>> Therefore the first reconnection negotiation would have >>>> "a=reconnect:1". >>>> >>>> c) Make the omission imply "a=reconnect:", such that the first >>>> appearance of "reconnect" would be "a=reconnect:0". >>>> >>>> I would guess that (a) makes the most sense. Thoughts? >>> >>> >>> >>> >>> That seems reasonable. >>> >>> In practice the number doesn't mean much except that it change. It >>> would work as well if it were an opaque token. >>> >>> When considered as a version number it makes more sense as an >>> increasing number. >>> >>> How about a=connection:NNN? (With a default of 1.) This numbers the >>> connections used to convey the media stream. This is clearly >>> associated with connections, so it isn't prone to abuse, and it also >>> conveys a clear semantic for the number. >>> >>>> Also, are there any possibilities of race conditions where the NNN >>>> would get out of sync between the two endpoints? If so, how would >>>> that be resolved? >>> >>> >>> >>> >>> I don't believe there are any race conditions, though there is always >>> the possibility of buggy endpoint getting confused. >>> >>> I don't think there are any race conditions because NNN isn't >>> negotiated - it is always managed by one end and conveyed to the >>> other end. In an offer/answer exchange, each side could conceivably >>> provide its own value for a=reconnect:NNN. It is only meaningful when >>> provided by a passive end to an active end, because it determines >>> whether the active end should reconnect. >>> >>> In the case of MSRP, there is only one connection, so reconnection >>> only makes sense in the direction of the original connection. >>> >>> In the case of comedia there could conceivably be two connections, >>> one in each direction. If so, it is conceivable that an offer/answer >>> exchange could have a=reconnect=NNN going both ways, and resulting in >>> zero, one, or two reconnections. >>> >>>> What about the additional state that must be tracked (the >>>> reconnection number)? I don't think that comedia-05 represents any >>>> additional state over connectionless media, which wouldn't be true >>>> for "reconnect:NNN". >>> >>> >>> >>> >>> There is extra implicit state in comedia. It must remember active, >>> passive, or both, whether still listening if passive, whether >>> connected if active, and ultimately the connection itself must be >>> remembered as state. This adds a number that must be associated with >>> the connection. Doesn't seem like a big burden. >>> >>>>> Paul >>>>> >>>>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>>>> >>>>>>> My attempts to reach David Yon at the address he has listed in >>>>>>> the comedia draft (yon@dialout.net) have bounced. Does anybody >>>>>>> know whether he is still at Dialout.Net, or even if Dialout.Net >>>>>>> still exists? >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>>> Ben, >>>>>>>> I'm copying David Yon on this since he is author of comedia. >>>>>>>> This probably won't make any sense out of context to him, so I >>>>>>>> will separately send him some of the earlier discussion. >>>>>>>> I don't recall what the current status of comedia is. It is >>>>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>>>> goals listed for it. >>>>>>>> Paul >>>>>>>> Ben Campbell wrote: >>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ben Campbell wrote: >>>>>>>>>> >>>>>>>>>>> (More comments on same email...) >>>>>>>>>>> >>>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>>> >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Using the same media lines for the replacement session >>>>>>>>>>>> solves the association problem for any media type - MSRP, >>>>>>>>>>>> RTP, whatever. But it also does leave the problem of >>>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change >>>>>>>>>>>> anything" offer. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>>>> as I hoped it would. While it does mean you have to do >>>>>>>>>> something special (add the a=reconnect) attribute to cause a >>>>>>>>>> reconnect, having done that once you then have to do something >>>>>>>>>> else (remove the a=reconnect) in a subsequent exchange. >>>>>>>>>> >>>>>>>>>> I think it would be better if there were something like >>>>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>>>> particular media session. Then whenever it changes you >>>>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>>>> from the o-line. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that sounds like a better approach. Do you think there >>>>>>>>> is any chance to convince the COMEDIA folks to follow the same >>>>>>>>> approach? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Simple mailing list >>>>>>>> Simple@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jan 20 11:01:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07700 for ; Tue, 20 Jan 2004 11:01:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyJl-0004it-FL for mmusic-archive@odin.ietf.org; Tue, 20 Jan 2004 11:01:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KG1TDp018154 for mmusic-archive@odin.ietf.org; Tue, 20 Jan 2004 11:01:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyJk-0004ie-G9 for mmusic-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:01:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07694 for ; Tue, 20 Jan 2004 11:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyJf-00014v-00 for mmusic-web-archive@ietf.org; Tue, 20 Jan 2004 11:01:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyIo-00012h-00 for mmusic-web-archive@ietf.org; Tue, 20 Jan 2004 11:00:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiyIO-000108-00 for mmusic-web-archive@ietf.org; Tue, 20 Jan 2004 11:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyIN-0004dc-HX; Tue, 20 Jan 2004 11:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyHn-0004ZV-SJ for mmusic@optimus.ietf.org; Tue, 20 Jan 2004 10:59:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07579 for ; Tue, 20 Jan 2004 10:59:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyHl-0000yU-00 for mmusic@ietf.org; Tue, 20 Jan 2004 10:59:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyGp-0000vB-00 for mmusic@ietf.org; Tue, 20 Jan 2004 10:58:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AiyFx-0000r5-00 for mmusic@ietf.org; Tue, 20 Jan 2004 10:57:33 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0KFvVqY017370; Tue, 20 Jan 2004 16:57:31 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBT7F0N; Tue, 20 Jan 2004 16:59:23 +0100 Message-ID: <400D4F94.6060004@ericsson.com> Date: Tue, 20 Jan 2004 16:56:04 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Reply to IESG comments on draft-ietf-mmusic-sdp-bwparam Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jon, this is a message in regards to the DISCUSS the Transport independent SDP bandwidth parameter draft received in IESG Discussion. Below is the comments from the IESG and inline my reply. >DISCUSSES AND COMMENTS: >====================== >Steve Bellovin: > >Comment: > >There are many other things that can cause erroneous bandwidth estimates, >including various forms of tunneling (GRE, IPsec, 6to4) and link-layer >encapsulation -- should those be discussed here? > > There are many reasons for erroneous bandwidth estimates, and I think the draft presents some of them, but not all. The important thing is to establish that the problem space exist. Therefore I don't see a real need to discuss all of them. However as I have missed some of the stated ones, they should at least be mentioned. This could easily be fixed in an update. >Ted Hardie: > >Comment: >I found section 3.5 on the potential interaction with DCCP somewhat lacking. >It's clear that using >DCCP for real time media will be different in a number of ways from the >current flows over UDP, >and while it is good that the draft notes the likely difference in header >size, it hardly seems >like the most important thing to note. The use of different congestion >control algorithms >seems far more salient; see draft-phelan-dccp-media-00.txt for a description >of how >TFRC's "contentment penalty" might apply when wrong guesses about available >bandwidth >come into play. > >That section of the draft may well date back some time, of course, so it may >be unfair to >ask for changes, and I certainly wouldn't block the draft for this. But a >review by the DCCP >folk might imrpove this a good bit; it also might show the need for a >separate draft to discuss >the DCCP-specific interactions here. > > It is true that the section dates back a bit. However I don't think DCCP evolution really effects the draft at all. The reason is that the solution as defined does only require the one actually calculating the true transport dependent bandwidth to know how big the used DCCP headers are. And as this will depend on which options, etc. that are in use for each transaction. So in fact this is only one more reason to why the parameters are needed. As Ted states I it is in my opinion likely that some thought at least will be required by the implementer to estimate the DCCP headers size correctly. If I am anyway request to perform an update I could put some effort into improving the text in this chapter to be clearer what the problem with DCCP is, i.e. other fixed header size than UDP + variable size in option fields. It should also as pointed out mention the limitations that congestion control may apply on a media stream. However I think the important factor here is to understand that the attribute is a maximum that the application will use. >Bert Wijnen: > >Discuss: >From OPS Directorate review (Pekka) > >one potential issue I see is in the introductory section: > >2.2. IPv6 and IPv4 > > Today there are two IP versions 4 [15] and 6 [14] used in parallel on > the Internet. This creates problems and there exist a number of > possible transition mechanisms. > > > ------------------ ---------------------- > | IPv4 domain | | IPv6 Domain | > | | ---------| | | > | ---------- |-| NAT-PT |-| ---------- | > | |Server A| | ---------| | |Client B| | > | ---------- | | ---------- | > ------------------ ---------------------- > > > Figure 1. Translation between IPv6 and IPv4 addresses. > > > - To achieve connectivity between an IPv4 only host and an IPv6 > only host, translation is necessary. This translator can be, for > example, Network Address Translation - Protocol Translation (NAT- > PT) [13], see Figure 1. However, to get connectivity for large > number of protocols, Application Level Gateway (ALG) functionality > is also required at the node. To be able to locate hosts through > the translation node DNS ALG must be supported. >[...] > >==> I do not feel particularly strongly about this, but I'm not sure >if we want to be referring to translation and NAT-PT in a standards >track document like this, at least at this phase .. when it doesn't >seem to be necessary. Maybe the same result could be obtained by >removing the figure and rewording the bullet point e.g. to: > > - The nodes which wish to communicate must share the IP version; > typically this is done by deploying dual-stack nodes. For > example, an IPv4 only host cannot communicate with an IPv6 only > host. > > - If communication between nodes which do not share a protocol > version is required, using a translation mechanism would be > required. Work is underway to specify one for this purpose. > > > I don't see a problem with rewording this to be less specific about the translation solution. It is after all only one of many reasons for this mechanism. Jon, should I start working on a updated draft that address the above issues? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jan 23 05:57:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24134 for ; Fri, 23 Jan 2004 05:57:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjyzK-0006tI-RV for mmusic-archive@odin.ietf.org; Fri, 23 Jan 2004 05:56:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NAuYNE026484 for mmusic-archive@odin.ietf.org; Fri, 23 Jan 2004 05:56:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjyzK-0006t5-Ny for mmusic-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 05:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24122 for ; Fri, 23 Jan 2004 05:56:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjyzH-0005br-00 for mmusic-web-archive@ietf.org; Fri, 23 Jan 2004 05:56:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjyyJ-0005ad-00 for mmusic-web-archive@ietf.org; Fri, 23 Jan 2004 05:55:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajyxq-0005Zg-00 for mmusic-web-archive@ietf.org; Fri, 23 Jan 2004 05:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajyxr-0006nj-4c; Fri, 23 Jan 2004 05:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjyxU-0006mP-Tq for mmusic@optimus.ietf.org; Fri, 23 Jan 2004 05:54:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24084 for ; Fri, 23 Jan 2004 05:54:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjyxR-0005ZQ-00 for mmusic@ietf.org; Fri, 23 Jan 2004 05:54:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjywT-0005Xr-00 for mmusic@ietf.org; Fri, 23 Jan 2004 05:53:38 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AjywI-0005Vq-00 for mmusic@ietf.org; Fri, 23 Jan 2004 05:53:26 -0500 Received: from gnvasmile.ebu.ch (unverified [10.73.222.210]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 23 Jan 2004 11:52:51 +0100 Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Jan 2004 11:52:46 +0100 Message-ID: From: Evain Jean-Pierre To: mmusic@ietf.org Date: Fri, 23 Jan 2004 11:52:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E19F.08D5B9E0" Subject: [MMUSIC] TVA comments on IMG framework and requirements Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E19F.08D5B9E0 Content-Type: text/plain A quick message to indicate that TVA comments will arrive on this reflector on Tuesday next week. Our review of the work is very positive and we look forward to contributing on the specification work... Regards, Jean-Pierre Evain EVAIN Jean-Pierre EBU - Technical Department Ancienne Route 17A CH-1218 Grand Saconnex (GE) Tel: +41 22 717 27 34 Fax: +41 22 747 47 34 evain@ebu.ch ********************************************************************** 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 system manager. ********************************************************************** ------_=_NextPart_001_01C3E19F.08D5B9E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable TVA comments on IMG framework and requirements

A quick message to indicate that TVA comme= nts will arrive on this reflector on Tuesday next week.

Our review of the work is very positive an= d we look forward to contributing on the specification work...

Regards,

Jean-Pierre Evain

EVAIN Jean-Pierre
EBU - Technical Department
Ancienne Route 17A
CH-1218 Grand Saconnex (GE)
Tel: +41 22 717 27 34
Fax: +41 22 747 47 34
evain@ebu.ch




**********************************************************************
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 system manager.

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

 ------_=_NextPart_001_01C3E19F.08D5B9E0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jan 25 07:32:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00387 for ; Sun, 25 Jan 2004 07:32:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkjQs-00075Y-Pt for mmusic-archive@odin.ietf.org; Sun, 25 Jan 2004 07:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PCW6Cc027244 for mmusic-archive@odin.ietf.org; Sun, 25 Jan 2004 07:32:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkjQs-00075L-Jp for mmusic-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 07:32:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00344 for ; Sun, 25 Jan 2004 07:32:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkjQr-0001c4-00 for mmusic-web-archive@ietf.org; Sun, 25 Jan 2004 07:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkjPu-0001Yd-00 for mmusic-web-archive@ietf.org; Sun, 25 Jan 2004 07:31:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkjOz-0001WI-00 for mmusic-web-archive@ietf.org; Sun, 25 Jan 2004 07:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkjOt-0006yU-FW; Sun, 25 Jan 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkjO1-0006xh-Rz for mmusic@optimus.ietf.org; Sun, 25 Jan 2004 07:29:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00261 for ; Sun, 25 Jan 2004 07:29:08 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkjO1-0001T3-00 for mmusic@ietf.org; Sun, 25 Jan 2004 07:29:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkjN9-0001Q2-00 for mmusic@ietf.org; Sun, 25 Jan 2004 07:28:16 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AkjMN-0001NZ-00 for mmusic@ietf.org; Sun, 25 Jan 2004 07:27:27 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0PCRPY01930 for ; Sun, 25 Jan 2004 14:27:25 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 25 Jan 2004 14:27:25 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 25 Jan 2004 14:27:25 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 25 Jan 2004 14:27:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jan 2004 14:27:23 +0200 Message-ID: Thread-Topic: Comments on IMG framework -02 Thread-Index: AcPUd1rb2VK72JCiQTarH6NP5IMKIANDHxcAAAHhcFA= To: , , , Cc: , , X-OriginalArrivalTime: 25 Jan 2004 12:27:24.0806 (UTC) FILETIME=[96725A60:01C3E33E] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: Comments on IMG framework -02 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All Thanks Pekka for the proposal. Since the discussion on whether a new = UNSUBSCRIBE _operation_ is needed seems to remain open, I'll add my two = cents... (I'm CC'ing MMUSIC as there may be wider opinion worth taking in before = the 03 ID submission) This is basically echoing Yuji's remarks that the SUBSCRIBE operation = inherently includes subscribe and unsubscribe features (regardless of = the number of and types of messages). We discussed this in San Francisco = and did consider that the "subscribe" operation it does not "only and = forever subscribe", but also resleases/unsubscribes. I've been working = on the notion that IMG SUBSCRIBE is pretty much analogous to IGMP = REPORT, so that the protocol messages allow differential subscribes and = unsubscribes (i.e. not just "subscribe to all notifications", but = differentiating between them. Also, that the messages would provide the = unsubscribe functionality from the same basic operation). In this sense = the name "IMG SUBSCRIBE" eclipses this issue, maybe "IMG SUBSCRIPTION" = or "IMG SUBSCRIPTION REPORT" would be more appropriate. Thus, (IMHO) the subscribe operation is sufficient to include subscribe = and unsubscribe functionality / message types when it is "applied to = reality" in a protocol specification. However, this is rather academic since whether or not we add = "unsubscribe" as a separate operation or keep the functionality within = the subscribe operation: we have exactly the same result in protocol = design based on the IMG framework - so whatever is easiest to accept is = OK for me. To help balance the two options, here's "competing text" against Pekka's = giving a clarification of "unsubscribe" being a part of subscribe so we = can basically implant this text or Pekka's depending on consensus = (Pekka's text is below). (Note, although this does not require any other = changes elsewhere in the document, Pekka's requires bare minimal changes = too so neither are much different in terms of minimising effort). > 3.2.4 IMG SUBSCRIBE >=20 > If an IMG receiver wants to be notified when the IMG metadata it > holds is stale, the IMG receiver can use the IMG SUBSCRIBE = operation > in advance in order to solicit notify messages from an IMG sender. >=20 This operation may provide the IMG sender with specific details of = which metadata or notification services it is interested in (in the case = where the IMG sender offers more than the simplest "all data" service. The = operation=20 implicitly provides the functionality of unsubscribing to inform an = IMG sender that an IMG receiver wishes to stop getting certain (or all) =20 notifications. It should be noted that the unsubscription may be = provided =20 implicitly by the expiry (timeout) of a subscription before it is = renewed. =20 However, these details belong to the messaging protocol and are = beyond the=20 scope of this document. > Since the IMG receiver doesn't know when metadata will be updated = and > the notify message will arrive, this operation does not synchronize > with the notify messages. The IMG receiver may wait for notify > messages for a long time. The IMG sender may authenticate the IMG > receiver to investigate whether an IMG SUBSCRIBE operation is from = an > authorized IMG receiver. >=20 Thoughts? For completeness, it seems that this is the list of actions needed for = the framework: * solve "unsubscribe is/is not a different operation" issue an implant = text (Yuji) from either Rod or Pekka (if Pekka's also modify operation = set figure) * delete mention of CDI (as it does not add value) - Yuji * add text on RTSP applicability - Yuji * add IANA considerations and IPR boilerplates -Yuji (which ones do we = select?) * a handful of typo/minor text Tuesday this week?)... * Submit 03 (WGLC-ready version?) - note although IETF-59 deadline is in = Feb, I expect the end of this week would be feasible? Cheers, Rod. -----Original Message----- From: Luoma Juha-Pekka (Nokia-NRC/Tampere)=20 Sent: Friday, January 23, 2004 10:16 AM To: nom@flab.fujitsu.co.jp; Hitoshi.Asaeda@sophia.inria.fr; schulzrinne@cs.columbia.edu; Walsh Rod (Nokia-NRC/Tampere) Cc: 'ext Colin Perkins'; jo@tzi.uni-bremen.de Subject: RE: Comments on IMG framework -02 Hi all, There's a few minor issues that we should resolve in both Framework and = Requirements. In theory this process could be optimized by different = people tackling different issues, so I tried picking one item from the = list and doing some editing. This item was adding an IMG UNSUBSCRIBE = operation to IMG Framework. It would have been a good idea to indicate = that I'm going to work in this area, so hopefully I did not repeat = anybody else's work - would be a good idea to announce that you are = going take on a work item. The resulting draft-ietf-mmusic-img-framework-03a is attached as two = HTML documents, one with changes tracked and another without tracking. = Figures might still need updating as a result of adding an unsubsribe = message, I can finish those. Please share your comments. 3.2.1 IMG ANNOUNCE When an IMG receiver participates in unidirectional communications (e.g. over satellite, terrestrial radio and wired multicast networks) an IMG receiver may not need to send any message to an IMG sender prior to IMG metadata delivery. In this case, an IMG sender can initiate unsolicited distribution for IMG metadata and an IMG sender is the only entity which can maintain the distribution (this includes scenarios with multiple and co-operative IMG senders). This operation is useful when there are considerably large number IMG receivers or IMG receiver(s) do not have a guaranteed uplink connection to the IMG sender(s). The IMG sender may also include authentication data in the announce operation so that IMG receivers may check the authenticity of the metadata. This operation is able to carry any of the IMG data types. Note, there is no restriction to prevent IMG ANNOUNCE from being used in an asynchronous solicited manner, where a separate operation (possibly out of band) is able to subscribe/register IMG receivers to the IMG ANNOUNCE operation. Similarly, a separate operation may be provided to unsubscribe/deregister from the IMG ANNOUNCE operation. ... =20 3.2.4 IMG SUBSCRIBE =20 If an IMG receiver wants to be notified when the IMG metadata it holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation in advance in order to solicit notify messages from an IMG sender. = The IMG SUBSCRIBE operation triggers the transmission of a subscribe message from the IMG receiver to the IMG sender.=20 =20 A subscription created as a result of IMG SUBSCRIBE is active for a=20 period of time that is well-known or indicated in the subscribe=20 message, or possibly signaled out of band. The subscription expires = at the end of this period, causing the IMG sender to stop sending notify = messages pertaining to this subscription. The active time of a subscription can be extended/changed by re-using IMG SUBSCRIBE or terminated prematurely by using IMG UNSUBSCRIBE. Since the IMG receiver doesn't know when metadata will be updated and the notify message will arrive, this operation does not synchronize with the notify messages. The IMG receiver may wait for notify messages for a long time. The IMG sender may authenticate the IMG receiver to investigate whether an IMG SUBSCRIBE operation is from an authorized IMG receiver. 3.2.5 IMG UNSUBSCRIBE An IMG receiver can use the IMG UNSUBSCRIBE operation to cancel an active subscription initiated by IMG SUBSCRIBE. The use of IMG = UNSUBSCRIBE triggers the transmission of an unsubscribe message from the IMG = receiver=20 to the IMG sender. Receiving this message instructs the IMG sender to ignore any remaining active time of the subscription and treat the=20 subscription as expired. -Pekka > -----Original Message----- > From: ext Colin Perkins [mailto:csp@csperkins.org] > Sent: 06 January, 2004 19:06 > To: nom@flab.fujitsu.co.jp > Cc: Luoma Juha-Pekka (Nokia-NRC/Tampere); > Hitoshi.Asaeda@sophia.inria.fr; schulzrinne@cs.columbia.edu; Walsh Rod > (Nokia-NRC/Tampere) > Subject: Re: Comments on IMG framework -02 >=20 >=20 > Hi, >=20 > --> Yuji Nomura writes: > > On Wed, 31 Dec 2003 17:50:18 +0000=20 > > Colin Perkins wrote: > >=20 > > > Is an IMG UNSUBSCRIBE message needed? Or is this=20 > considered merely an > > > implementation detail? > >=20 > > I think UNSUBSCRIBE is an implementation option, although=20 > it is useful > > in some cases. Since Section 3.2 introduces abstract functions,=20 > > SUBSCRIBE message may have the function as UNSUBSCRIBE. > >=20 > > It may be better to mention that in section 3.2.4. >=20 > I'd suggest that UNSUBSCRIBE is logically separate, so would=20 > need a new > message type.=20 >=20 > ... > > > In Sections 5.1 and 5.2, I see no mention of RTSP. I=20 > don't think RTSP > > > is an appropriate protocol for the IMG, but it does=20 > support some IMG > > > functions in a limited way. May be appropriate to include=20 > it in the > > > draft, to explain why it's not suitable. > >=20 > > Yes, it is right. > >=20 > > As far as I know, RTSP has some methods, such as ANNOUNCE and > > DESCRIBE, which supports some IMG functions. However, these methods > > can carry information for just one session, therefore RTSP supports > > the function in very limited situation. > >=20 > > Is it correct? Any other thing to be mentioned? >=20 > I believe that's correct. RTSP is a very limited IMG=20 > protocol, but should > be mentioned for completeness. >=20 > Cheers, > Colin > << File: draft-ietf-mmusic-img-framework-03a.htm >> << File: = draft-ietf-mmusic-img-framework-03a_changes_tracked.htm >>=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jan 27 09:11:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05610 for ; Tue, 27 Jan 2004 09:11:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTvS-0001TS-JB for mmusic-archive@odin.ietf.org; Tue, 27 Jan 2004 09:10:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0REAkj1005660 for mmusic-archive@odin.ietf.org; Tue, 27 Jan 2004 09:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTvS-0001TD-Ez for mmusic-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:10:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05577 for ; Tue, 27 Jan 2004 09:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTvQ-0003n0-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 09:10:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTuV-0003kW-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 09:09:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTtl-0003hz-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 09:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTtk-0001Kl-Br; Tue, 27 Jan 2004 09:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTtU-0001KH-GY for mmusic@optimus.ietf.org; Tue, 27 Jan 2004 09:08:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05514 for ; Tue, 27 Jan 2004 09:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTtS-0003h5-00 for mmusic@ietf.org; Tue, 27 Jan 2004 09:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTsW-0003eX-00 for mmusic@ietf.org; Tue, 27 Jan 2004 09:07:46 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AlTrb-0003ZU-00 for mmusic@ietf.org; Tue, 27 Jan 2004 09:06:47 -0500 Received: from gnvasmile.ebu.ch (unverified [10.73.222.210]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Tue, 27 Jan 2004 15:06:15 +0100 Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jan 2004 15:06:02 +0100 Message-ID: From: Evain Jean-Pierre To: mmusic@ietf.org Date: Tue, 27 Jan 2004 15:06:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E4DE.B2109650" Subject: [MMUSIC] TVA comments on the framework and requirements Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E4DE.B2109650 Content-Type: text/plain 0/ Summary TV-Anytime has reviewed draft-ietf-mmusic-img-framework-02.txt and draft-ietf-mmusic-img-req-02.txt and would like to suggest the following... The IMG framework and requirements are fully in line with TVA objectives and we have only a very limited number of suggestions for amendment of the texts. TVA looks forward ensuring compatibility of the IMG mechanisms with our applications. Furthermore, TVA would like to share experience with IMG and contribute to the IMG data model, service discover and service exploitation mechanisms. 1/ Clarification of the role of TV-Anytime We would like to start by clarifying the relationship between TV-Anytime and MPEG-7. The description made in Section 5.1 does not seem to be accurate and the assumption made that TV-Anytime is as a whole based on MPEG7 is not correct. Most of the TV-Anytime schemas are based on a data model specific to TV-Anytime. TV-Anytime schemas have been optimised to describe broadcast schedules, on-demand programme guides and programme events. TV-Anytime only uses the MPEG-7's User description profile for user preferences and usage history. 2/ References to TVA specifications Furthermore, the references to TV-Anytime specifications should be completed as follows using the ETSI references: Generic specification name: ETSI-TS 102 822; Broadcast and On-line services: Search, select, and rightful use of content on personal storage systems Identification of specification parts and sub-parts: ETSI-TS 102 822-1: Phase 1 Benchmark Features ETSI-TS 102 822-2: System Description ETSI-TS 102 822-3/1: Metadata Schemas ETSI-TS 102 822-3/2: Metadata System Aspects (Fragmentation, indexing, encoding) ETSI-TS 102 822-4: Content Referencing ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - Service and transport ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - Service Discovery ETSI TS 102 822-7: Bidirectional Metadata Delivery Protection 3/ TV-Anytime is totally in line with the IMG framework in terms of services, applications and entities. Furthermore, TV-Anytime has already explored some of the delivery and transport issues addressed by IMG. 4/ The domain of application of TVA Phase 1 is unidirectional broadcast assisted by bi-directional access to ancillary metadata services. The TVA specification covers the description of broadcast and on-demand schedules or events. Furthermore, TVA has developed a "content referencing" scheme and "resolving" mechanisms that provide enhanced flexibility in the management of schedules and associated content. The type of Phase 1 content is primarily video, audio and ancillary services (Teletext, subtitles, design-for-all features...). TVA Phase 2 is currently addressing media packages that will encompass all sorts of data for different media delivery. It is therefore expected that TVA will cover a very wide range of applications and content and we would like to ensure that IMG allows to TVA data being accessed, transported and delivered using multicast or unicast delivery. 5/ As suggested in the IMG framework, the data model defined by TV-Anytime has been designed to allow an efficient delivery, versioning and updating of our data. This structure (fragmentation, indexing, encoding, etc) is defined in our metadata specification ETSI TS102822-3/2. The TVA data model is fully compatible with the notions of IMG descriptions, Delta IMG descriptions and IMG pointer identified in the IMG framework. The use of the TVA model is not restricted and IMG is welcome to adopting it depending on the level of granularity targeted for the IMG data types and data models (see IMG needs in Sections 3.1 and 5.3.4). The experience of TV-Anytime is that the data model must be sufficiently explicit to further specify the metadata service mechanisms (see ETSI TS102822-6/1/2). 6/ Service discovery over bi-directional networks, commands and protocols can be found in ETSI TS102822-6. The TVA specification make use of existing IETF mechanisms. TVA would certainly welcome feedback from IMG experts on the solutions proposed in these documents. We look forward to collaborating with IMG to maintain / enhance compatibility. Furthermore, TVA defines service discovery mechanisms initiated by a client request for metadata services but there is no reason why TVA could not take benefit from permanent connection or access e.g. multicast to "pushed" data. In TVA, service discovery is made using UDDI or WSDL and WS-Inspection. Once a metadata service has been "discovered", the domain of operation is the metadata service domain. 7/ Security is addressed in ETSI TS102822-7. TV-Anytime has specified basic security mechanisms for the exchange of metadata over bi-driectional networks based on IETF TLS (Transport Layer Security). 8/ TVA supports the IMG requirements with the exception of one or two minor request for clarification to be reported hereafter. More importantly, the concurrence of the IMG framework and requirements with what TVA has done (Phase 1 plus Phase 2 covering a wide range of application and content types) encourages us in more collaboration with IMG in particular contributing to draft-luoma-mmusic-img-metadata-03 with our data model. 9/ Suggestions on the content orientated use cases in IMG requirements TVA Phase 1 definitely covers 4.2.2 TV and radio programme delivery, 4.2.3 media coverage of a live event and 4.2.4 distance learning. One could certainly add more use cases such as "Trailer booking and recording", "Use of segmented content for content updates, content replacement for e.g. targeted advertising, and virtual programmes", "Discovery and access to related programmes", etc. TVA Phase 2 will enrich these cases by the use of media packages encompassing more content formats than audio, video and related ancillary data. 10/ Review of the IMG requirements and comments REQ GEN-1: The TVA data model is compliant with the IMG framework and associated requirements. SP003 defines self-contained common document structure being considered as a candidate for IMG metadata format. It has a single top-level element that encloses all other TV-Anytime metadata. TVA can be transported efficiently by fragmenting descriptions and sequential delivery of description tables clearly identified by their version for updating, replacement or deletion. REQ GEN-2: TVA anytime Phase 1 covers a wide range of applications as mentioned above. Phase 2 will further enlarge the scope of application of TVA data. IMG SHOULD support these. REQ GEN-3: SP003 defines the identifier that specifies the name of the publisher of the description. This offers the base for some mechanisms to solve issues related to simultaneous access to multiple IMG senders. REQ GEN-4: SP006 ensures the modularity of query/response operations relevant to IMG Operations. REQ DEL-1: The TVA metadata model allows flexible update. REQ DEL-2: SP003 defines identification scheme to identify particular version of a metadata fragment. TVA anytime data fragmentation takes into account the need for efficient delivery and management of update in combination with BiM encoding. REQ DEL-3: The TVA data model has been designed to deliver data to large audiences REQ DEL-4: SP006 has allows to expand metadata descriptions based on the TVA versioning and notification schemes. The TVA approach described in TS102822-6 is based on service discovery initiated by a client but could also take benefit of permanent, although possibly intermittent, connections. The fragmentation and indexing of TVA data allows small quantities of reliably connected carouselled data being transmitted including over intermittent connections. Descriptions are reconstructed after reception once the system has been signalled that all description elements have been received. REQ DEL-5: See REQ DEL-4 REQ DEL-6: TV-Anytime queries are currently client initiated. The problem of time limited validity of pushed data remains to be addressed (TVA Phase 2). REQ DEL-7: Sender driven aspects will be addressed in TVA Phase 2 for compliance with IMG requirements. REQ CUS-1: SP006 defines schemes for submission of user-centric metadata to metadata service providers and retrieval of customised data. Sender-driven uni/multicast delivery of customized metadata descriptions will be addressed in TVA Phase 2 for compliance with IMG requirements. REQ REL-1: SP003 defines an identification scheme to identify and manage a particular version of a metadata fragment, which can be a complete description or a description subset. REQ REL-2: SP006 can manage versions and updates in client initiated transactions. Sender-driven uni/multicast delivery will be addressed in TVA Phase 2 for compliance with IMG requirements. REQ REL-3: SP006 uses http as a base for bi-directional metadata retrieval. REQ DES-1: This issue is particularly sensitive in the case of simultaneous access to multiple IMG senders. This is being addressed in TVA Phase 2. However, TVA believes that the metadata provided by different sources is under the responsability of one authority that manages versions of this data. REQ DES-2: Absolutely necessary and TVA is ready to help in order to ensure that this apply to all TVA's domains of application. REQ DES-3: TVA would like to suggest a clarification of this requirements with the need expressed in the IMG framework document for an IMG minimum data model. REQ DES-4: SP003 defines self-contained common document structure that has a single top-level element that encloses all or part of TV-Anytime metadata. The different metadata tables can be transmitted in separate fragments. REQ DES-5: Agreed. In the case of TV-Anytime, the envelope must contain all the parameters essential to the management of TVA Main and associated fragments. REQ DES-6: TV-Anytime should be one of the identifiable metadata formats. REQ DES-7: no comment REQ DES-8: TVA fully supports versioning and updates. As concerns the requirements security mentioned in Section 6, TVA only defines very generic scheme for establishing secure authentication channel between metadata sender and receiver (TS 102822-7). ********************************************************************** 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 system manager. ********************************************************************** ------_=_NextPart_001_01C3E4DE.B2109650 Content-Type: text/html Content-Transfer-Encoding: quoted-printable TVA comments on the framework and requirements

0/ Summary
TV-Anytime has reviewed draft-ietf-= mmusic-img-framework-02.txt
and draft-ietf-mmusic-img-req-02.tx= t and would like to suggest the following...

The IMG framework and requirements a= re fully in line with TVA objectives and we have only a very limited number= of suggestions for amendment of the texts.

TVA looks forward ensuring compatibi= lity of the IMG mechanisms with our applications.
Furthermore, TVA would like to shar= e experience with IMG and contribute to the IMG data model, service discove= r and service exploitation mechanisms.


1/ Clarification of the role of TV-A= nytime
We would like to start by clarifyin= g the relationship between TV-Anytime and MPEG-7.  The description mad= e in Section 5.1 does not seem to be accurate and the assumption made that = TV-Anytime is as a whole based on MPEG7 is not correct.  Most of the T= V-Anytime schemas are based on a data model specific to TV-Anytime.  T= V-Anytime schemas have been optimised to describe broadcast schedules, on-d= emand programme guides and programme events.  TV-Anytime only uses the= MPEG-7's User description profile for user preferences and usage history. =


2/ References to TVA specifications<= /FONT>
Furthermore, the references to TV-A= nytime specifications should be completed as follows using the ETSI referen= ces:

Generic specification name:
ETSI-TS 102 822; Broadcast and On-l= ine services: Search, select, and
rightful use of content on personal= storage systems
Identification of specification par= ts and sub-parts:
ETSI-TS 102 822-1: Phase 1 Benchmar= k Features
ETSI-TS 102 822-2: System Descripti= on
ETSI-TS 102 822-3/1: Metadata Schem= as
ETSI-TS 102 822-3/2: Metadata Syste= m Aspects (Fragmentation, indexing, encoding)
ETSI-TS 102 822-4: Content Referenc= ing
ETSI-TS 102 822-6/1: Metadata Servi= ces over a Bidirectional Network - Service and transport
ETSI-TS 102 822-6/1: Metadata Servi= ces over a Bidirectional Network - Service Discovery
ETSI TS 102 822-7: Bidirectional Me= tadata Delivery Protection


3/ TV-Anytime is totally in line wit= h the IMG framework in terms of services, applications and entities.  = Furthermore, TV-Anytime has already explored some of the delivery and trans= port issues addressed by IMG.


4/ The domain of application of TVA = Phase 1 is unidirectional broadcast assisted by bi-directional access to an= cillary metadata services.  The TVA specification covers the descripti= on of broadcast and on-demand schedules or events.  Furthermore, TVA h= as developed a "content referencing" scheme and "resolving&q= uot; mechanisms that provide enhanced flexibility in the management of sche= dules and associated content.  The type of Phase 1 content is primaril= y video, audio and ancillary services (Teletext, subtitles, design-for-all = features...).  TVA Phase 2 is currently addressing media packages that= will encompass all sorts of data for different media delivery.  It is= therefore expected that TVA will cover a very wide range of applications a= nd content and we would like to ensure that IMG allows to TVA data being ac= cessed, transported and delivered using multicast or unicast delivery.


5/ As suggested in the IMG framework= , the data model defined by TV-Anytime has been designed to allow an effici= ent delivery, versioning and updating of our data.  This structure (fr= agmentation, indexing, encoding, etc) is defined in our metadata specificat= ion ETSI TS102822-3/2.   The TVA data model is fully compatible w= ith the notions of IMG descriptions, Delta IMG descriptions and IMG pointer= identified in the IMG framework. The use of the TVA model is not restricte= d and IMG is welcome to adopting it depending on the level of granularity t= argeted for the IMG data types and data models (see IMG needs in Sections 3= .1 and 5.3.4).  The experience of TV-Anytime is that the data model mu= st be sufficiently explicit to further specify the metadata service mechani= sms (see ETSI TS102822-6/1/2).


6/ Service discovery over bi-directi= onal networks, commands and protocols can be found in ETSI TS102822-6. = ; The TVA specification make use of existing IETF mechanisms.  TVA wou= ld certainly welcome feedback from IMG experts on the solutions proposed in= these documents. We look forward to collaborating with IMG to maintain / e= nhance compatibility. Furthermore, TVA defines service discovery mechanisms= initiated by a client request for metadata services but there is no reason= why TVA could not take benefit from permanent connection or access e.g. mu= lticast to "pushed" data. In TVA, service discovery is made using= UDDI or WSDL and WS-Inspection.  Once a metadata service has been &qu= ot;discovered", the domain of operation is the metadata service domain= .


7/ Security is addressed in ETSI TS1= 02822-7. TV-Anytime has specified basic security mechanisms for the exchang= e of metadata over bi-driectional networks based on IETF TLS (Transport Lay= er Security).


8/ TVA supports the IMG requirements= with the exception of one or two minor request for clarification to be rep= orted hereafter.  More importantly,  the concurrence of the IMG f= ramework and requirements with what TVA has done (Phase 1 plus Phase 2 cove= ring a wide range of application and content types) encourages us in more c= ollaboration with IMG in particular contributing to draft-luoma-mmusic-img-= metadata-03 with our data model.


9/ Suggestions on the content orient= ated use cases in IMG requirements
TVA Phase 1 definitely covers 4.2.2= TV and radio programme delivery, 4.2.3 media coverage of a live event and&= nbsp; 4.2.4 distance learning. One could certainly add more use cases such = as "Trailer booking and recording", "Use of segmented conten= t for content updates, content replacement for e.g. targeted advertising, a= nd virtual programmes", "Discovery and access to related programm= es", etc.

TVA Phase 2 will enrich these cases = by the use of media packages encompassing more content formats than audio, = video and related ancillary data.


10/ Review of the IMG requirements a= nd comments
REQ GEN-1: The TVA data model is co= mpliant with the IMG framework and associated requirements.  SP003 def= ines self-contained common document structure being considered as a candida= te for IMG metadata format. It has a single top-level element that encloses= all other TV-Anytime metadata.  TVA can be transported efficiently by= fragmenting descriptions and sequential delivery of description tables cle= arly identified by their version for updating, replacement or deletion.

REQ GEN-2: TVA anytime Phase 1 cover= s a wide range of applications as mentioned above.  Phase 2 will furth= er enlarge the scope of application of TVA data.  IMG SHOULD support t= hese.

REQ GEN-3: SP003 defines the identif= ier that specifies the name of the publisher of the description. This offer= s the base for some mechanisms to solve issues related to simultaneous acce= ss to multiple IMG senders. 

REQ GEN-4: SP006 ensures the modular= ity of query/response operations relevant to IMG Operations.

REQ DEL-1: The TVA metadata model al= lows flexible update.

REQ DEL-2: SP003 defines identificat= ion scheme to identify particular version of a metadata fragment.  TVA= anytime data fragmentation takes into account the need for efficient deliv= ery and management of update in combination with BiM encoding.

REQ DEL-3: The TVA data model has be= en designed to deliver data to large audiences
REQ DEL-4: SP006 has allows to expa= nd metadata descriptions based on the TVA versioning and notification schem= es.  The TVA approach described in TS102822-6 is based on service disc= overy initiated by a client but could also take benefit of permanent, altho= ugh possibly intermittent, connections.  The fragmentation and indexin= g of TVA data allows small quantities of reliably connected carouselled dat= a being transmitted including over intermittent connections.  Descript= ions are reconstructed after reception once the system has been signalled t= hat all description elements have been received.

REQ DEL-5: See REQ DEL-4

REQ DEL-6: TV-Anytime queries are cu= rrently client initiated.  The problem of time limited validity of pus= hed data remains to be addressed (TVA Phase 2).

REQ DEL-7: Sender driven aspects wil= l be addressed in TVA Phase 2 for compliance with IMG requirements.

REQ CUS-1: SP006 defines schemes for= submission of user-centric metadata to metadata service providers and retr= ieval of customised data. Sender-driven uni/multicast delivery of customize= d metadata descriptions will be addressed in TVA Phase 2 for compliance wit= h IMG requirements.

REQ REL-1: SP003 defines an identifi= cation scheme to identify and manage a particular version of a metadata fra= gment, which can be a complete description or a description subset.<= /P>

REQ REL-2: SP006 can manage versions= and updates in client initiated transactions. Sender-driven uni/multicast = delivery will be addressed in TVA Phase 2 for compliance with IMG requireme= nts.

REQ REL-3: SP006 uses http as a base= for bi-directional metadata retrieval.

REQ DES-1: This issue is particularl= y sensitive in the case of simultaneous access to multiple IMG senders.&nbs= p; This is being addressed in TVA Phase 2.  However, TVA believes that= the metadata provided by different sources is under the responsability of = one authority that manages versions of this data.

REQ DES-2: Absolutely necessary and = TVA is ready to help in order to ensure that this apply to all TVA's domain= s of application.

REQ DES-3: TVA would like to suggest= a clarification of this requirements with the need expressed in the IMG fr= amework document for an IMG minimum data model.

REQ DES-4: SP003 defines self-contai= ned common document structure that  has a single top-level element tha= t encloses all or part of TV-Anytime metadata.  The different metadata= tables can be transmitted in separate fragments.

REQ DES-5: Agreed.  In the case= of TV-Anytime, the envelope must contain all the parameters essential to t= he management of TVA Main and associated fragments.

REQ DES-6: TV-Anytime should be one = of the identifiable metadata formats.

REQ DES-7: no comment

REQ DES-8: TVA fully supports versio= ning and updates.

As concerns the requirements securit= y mentioned in Section 6, TVA only defines very generic scheme for establis= hing secure authentication channel between metadata sender and receiver (TS= 102822-7).



**********************************************************************
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 system manager.

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

 ------_=_NextPart_001_01C3E4DE.B2109650-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jan 27 16:07:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24371 for ; Tue, 27 Jan 2004 16:07:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlaQE-0004VL-0O for mmusic-archive@odin.ietf.org; Tue, 27 Jan 2004 16:06:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RL6vfa017311 for mmusic-archive@odin.ietf.org; Tue, 27 Jan 2004 16:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlaQD-0004V8-RY for mmusic-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 16:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24364 for ; Tue, 27 Jan 2004 16:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlaQC-0000XH-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 16:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlaPN-0000UR-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 16:06:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlaON-0000RU-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 16:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlaOK-0004Mp-G2; Tue, 27 Jan 2004 16:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlaNN-0004JQ-Os for mmusic@optimus.ietf.org; Tue, 27 Jan 2004 16:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24335 for ; Tue, 27 Jan 2004 16:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlaNM-0000OB-00 for mmusic@ietf.org; Tue, 27 Jan 2004 16:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlaMR-0000LX-00 for mmusic@ietf.org; Tue, 27 Jan 2004 16:03:04 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AlaM0-0000IG-00 for mmusic@ietf.org; Tue, 27 Jan 2004 16:02:36 -0500 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id i0RL2CRO019236; Tue, 27 Jan 2004 22:02:13 +0100 (MET) Message-ID: <4016D2C1.5080502@tzi.uni-bremen.de> Date: Tue, 27 Jan 2004 22:06:09 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: csp@csperkins.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC WG in Seoul Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we have requested a single 2.5h slot for the upcoming 59th IETF in Seoul. We expect the following subjects to be dealt with - Various SDP stuff - Internet Media Guides - ICE - RTSP We may also need to deal with a charter update. Please address agenda slot requests belonging to these subjects to csp@csperkins.org and jo@tzi.org. The sooner the better. In your agenda slot request, please refer to the Internet Draft you intend to be addressing and point out the issues to be discussed. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 28 07:59:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28984 for ; Wed, 28 Jan 2004 07:58:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpH5-0003bA-7A for mmusic-archive@odin.ietf.org; Wed, 28 Jan 2004 07:58:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SCwVPk013831 for mmusic-archive@odin.ietf.org; Wed, 28 Jan 2004 07:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpH5-0003b0-1V for mmusic-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 07:58:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28981 for ; Wed, 28 Jan 2004 07:58:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlpH4-00062P-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 07:58:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpGB-0005yP-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 07:57:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlpFe-0005tj-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 07:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpFd-0003Qc-87; Wed, 28 Jan 2004 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpFA-0003QM-Rc for mmusic@optimus.ietf.org; Wed, 28 Jan 2004 07:56:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28934 for ; Wed, 28 Jan 2004 07:56:31 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlpF9-0005sO-00 for mmusic@ietf.org; Wed, 28 Jan 2004 07:56:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpEC-0005no-00 for mmusic@ietf.org; Wed, 28 Jan 2004 07:55:34 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AlpDR-0005ja-00 for mmusic@ietf.org; Wed, 28 Jan 2004 07:54:45 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SCshV02617 for ; Wed, 28 Jan 2004 14:54:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 14:54:42 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 14:54:22 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 14:54:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E59D.D922CD0C" Subject: RE: [MMUSIC] TVA comments on the framework and requirements Date: Wed, 28 Jan 2004 14:54:21 +0200 Message-ID: Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAq51Dw To: Cc: X-OriginalArrivalTime: 28 Jan 2004 12:54:21.0322 (UTC) FILETIME=[D9345EA0:01C3E59D] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E59D.D922CD0C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre =20 Thank you for your extensive input. We are very pleased that TV-Anytime = finds the IMG work to be in great shape for TVA use, and also to have = such a good breadth of comments on the applicability of IMGs and TVA to = one another. =20 To make my life easier in responding and discussing this information I = will make more than one email reply covering different aspects. Here's = an idea of the kind of aspects I'm thinking about: * TVA review of IMG requirements and framework IDs and changes to these = documents * Separating TVA-IMG objectives to those which fit MMUSIC scope, and = those which belong to other standards WGs * The delivery protocol needs of TVA with IMG: existing solutions and = new work needed (and where to do it) * The metadata needs of TVA with IMG: existing solutions and new work = needed (and where to do it) * The conformance of TVA Phase 1 (and the up-and-coming Phase 2) to the = IMG requirements & framework * The applicability of TVA technology for reuse in IMG solutions =20 In the meantime, anyone else's ideas are more than welcome. =20 Cheers, Rod Walsh =20 =20 -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of = ext Evain Jean-Pierre Sent: Tuesday, January 27, 2004 4:06 PM To: mmusic@ietf.org Subject: [MMUSIC] TVA comments on the framework and requirements 0/ Summary=20 TV-Anytime has reviewed draft-ietf-mmusic-img-framework-02.txt=20 and draft-ietf-mmusic-img-req-02.txt and would like to suggest the = following...=20 The IMG framework and requirements are fully in line with TVA objectives = and we have only a very limited number of suggestions for amendment of = the texts. TVA looks forward ensuring compatibility of the IMG mechanisms with our = applications.=20 Furthermore, TVA would like to share experience with IMG and contribute = to the IMG data model, service discover and service exploitation = mechanisms. 1/ Clarification of the role of TV-Anytime=20 We would like to start by clarifying the relationship between TV-Anytime = and MPEG-7. The description made in Section 5.1 does not seem to be = accurate and the assumption made that TV-Anytime is as a whole based on = MPEG7 is not correct. Most of the TV-Anytime schemas are based on a = data model specific to TV-Anytime. TV-Anytime schemas have been = optimised to describe broadcast schedules, on-demand programme guides = and programme events. TV-Anytime only uses the MPEG-7's User = description profile for user preferences and usage history.=20 2/ References to TVA specifications=20 Furthermore, the references to TV-Anytime specifications should be = completed as follows using the ETSI references:=20 Generic specification name:=20 ETSI-TS 102 822; Broadcast and On-line services: Search, select, and=20 rightful use of content on personal storage systems=20 Identification of specification parts and sub-parts:=20 ETSI-TS 102 822-1: Phase 1 Benchmark Features=20 ETSI-TS 102 822-2: System Description=20 ETSI-TS 102 822-3/1: Metadata Schemas=20 ETSI-TS 102 822-3/2: Metadata System Aspects (Fragmentation, indexing, = encoding)=20 ETSI-TS 102 822-4: Content Referencing=20 ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - = Service and transport=20 ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - = Service Discovery=20 ETSI TS 102 822-7: Bidirectional Metadata Delivery Protection=20 3/ TV-Anytime is totally in line with the IMG framework in terms of = services, applications and entities. Furthermore, TV-Anytime has = already explored some of the delivery and transport issues addressed by = IMG. 4/ The domain of application of TVA Phase 1 is unidirectional broadcast = assisted by bi-directional access to ancillary metadata services. The = TVA specification covers the description of broadcast and on-demand = schedules or events. Furthermore, TVA has developed a "content = referencing" scheme and "resolving" mechanisms that provide enhanced = flexibility in the management of schedules and associated content. The = type of Phase 1 content is primarily video, audio and ancillary services = (Teletext, subtitles, design-for-all features...). TVA Phase 2 is = currently addressing media packages that will encompass all sorts of = data for different media delivery. It is therefore expected that TVA = will cover a very wide range of applications and content and we would = like to ensure that IMG allows to TVA data being accessed, transported = and delivered using multicast or unicast delivery. 5/ As suggested in the IMG framework, the data model defined by = TV-Anytime has been designed to allow an efficient delivery, versioning = and updating of our data. This structure (fragmentation, indexing, = encoding, etc) is defined in our metadata specification ETSI = TS102822-3/2. The TVA data model is fully compatible with the notions = of IMG descriptions, Delta IMG descriptions and IMG pointer identified = in the IMG framework. The use of the TVA model is not restricted and IMG = is welcome to adopting it depending on the level of granularity targeted = for the IMG data types and data models (see IMG needs in Sections 3.1 = and 5.3.4). The experience of TV-Anytime is that the data model must be = sufficiently explicit to further specify the metadata service mechanisms = (see ETSI TS102822-6/1/2). 6/ Service discovery over bi-directional networks, commands and = protocols can be found in ETSI TS102822-6. The TVA specification make = use of existing IETF mechanisms. TVA would certainly welcome feedback = from IMG experts on the solutions proposed in these documents. We look = forward to collaborating with IMG to maintain / enhance compatibility. = Furthermore, TVA defines service discovery mechanisms initiated by a = client request for metadata services but there is no reason why TVA = could not take benefit from permanent connection or access e.g. = multicast to "pushed" data. In TVA, service discovery is made using UDDI = or WSDL and WS-Inspection. Once a metadata service has been = "discovered", the domain of operation is the metadata service domain. 7/ Security is addressed in ETSI TS102822-7. TV-Anytime has specified = basic security mechanisms for the exchange of metadata over = bi-driectional networks based on IETF TLS (Transport Layer Security). 8/ TVA supports the IMG requirements with the exception of one or two = minor request for clarification to be reported hereafter. More = importantly, the concurrence of the IMG framework and requirements with = what TVA has done (Phase 1 plus Phase 2 covering a wide range of = application and content types) encourages us in more collaboration with = IMG in particular contributing to draft-luoma-mmusic-img-metadata-03 = with our data model. 9/ Suggestions on the content orientated use cases in IMG requirements=20 TVA Phase 1 definitely covers 4.2.2 TV and radio programme delivery, = 4.2.3 media coverage of a live event and 4.2.4 distance learning. One = could certainly add more use cases such as "Trailer booking and = recording", "Use of segmented content for content updates, content = replacement for e.g. targeted advertising, and virtual programmes", = "Discovery and access to related programmes", etc. TVA Phase 2 will enrich these cases by the use of media packages = encompassing more content formats than audio, video and related = ancillary data. 10/ Review of the IMG requirements and comments=20 REQ GEN-1: The TVA data model is compliant with the IMG framework and = associated requirements. SP003 defines self-contained common document = structure being considered as a candidate for IMG metadata format. It = has a single top-level element that encloses all other TV-Anytime = metadata. TVA can be transported efficiently by fragmenting = descriptions and sequential delivery of description tables clearly = identified by their version for updating, replacement or deletion. REQ GEN-2: TVA anytime Phase 1 covers a wide range of applications as = mentioned above. Phase 2 will further enlarge the scope of application = of TVA data. IMG SHOULD support these. REQ GEN-3: SP003 defines the identifier that specifies the name of the = publisher of the description. This offers the base for some mechanisms = to solve issues related to simultaneous access to multiple IMG senders. = REQ GEN-4: SP006 ensures the modularity of query/response operations = relevant to IMG Operations.=20 REQ DEL-1: The TVA metadata model allows flexible update.=20 REQ DEL-2: SP003 defines identification scheme to identify particular = version of a metadata fragment. TVA anytime data fragmentation takes = into account the need for efficient delivery and management of update in = combination with BiM encoding. REQ DEL-3: The TVA data model has been designed to deliver data to large = audiences=20 REQ DEL-4: SP006 has allows to expand metadata descriptions based on the = TVA versioning and notification schemes. The TVA approach described in = TS102822-6 is based on service discovery initiated by a client but could = also take benefit of permanent, although possibly intermittent, = connections. The fragmentation and indexing of TVA data allows small = quantities of reliably connected carouselled data being transmitted = including over intermittent connections. Descriptions are reconstructed = after reception once the system has been signalled that all description = elements have been received. REQ DEL-5: See REQ DEL-4=20 REQ DEL-6: TV-Anytime queries are currently client initiated. The = problem of time limited validity of pushed data remains to be addressed = (TVA Phase 2). REQ DEL-7: Sender driven aspects will be addressed in TVA Phase 2 for = compliance with IMG requirements.=20 REQ CUS-1: SP006 defines schemes for submission of user-centric metadata = to metadata service providers and retrieval of customised data. = Sender-driven uni/multicast delivery of customized metadata descriptions = will be addressed in TVA Phase 2 for compliance with IMG requirements. REQ REL-1: SP003 defines an identification scheme to identify and manage = a particular version of a metadata fragment, which can be a complete = description or a description subset. REQ REL-2: SP006 can manage versions and updates in client initiated = transactions. Sender-driven uni/multicast delivery will be addressed in = TVA Phase 2 for compliance with IMG requirements. REQ REL-3: SP006 uses http as a base for bi-directional metadata = retrieval.=20 REQ DES-1: This issue is particularly sensitive in the case of = simultaneous access to multiple IMG senders. This is being addressed in = TVA Phase 2. However, TVA believes that the metadata provided by = different sources is under the responsability of one authority that = manages versions of this data. REQ DES-2: Absolutely necessary and TVA is ready to help in order to = ensure that this apply to all TVA's domains of application. REQ DES-3: TVA would like to suggest a clarification of this = requirements with the need expressed in the IMG framework document for = an IMG minimum data model. REQ DES-4: SP003 defines self-contained common document structure that = has a single top-level element that encloses all or part of TV-Anytime = metadata. The different metadata tables can be transmitted in separate = fragments. REQ DES-5: Agreed. In the case of TV-Anytime, the envelope must contain = all the parameters essential to the management of TVA Main and = associated fragments. REQ DES-6: TV-Anytime should be one of the identifiable metadata = formats.=20 REQ DES-7: no comment=20 REQ DES-8: TVA fully supports versioning and updates.=20 As concerns the requirements security mentioned in Section 6, TVA only = defines very generic scheme for establishing secure authentication = channel between metadata sender and receiver (TS 102822-7).=20 ********************************************************************** 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 system manager. ********************************************************************** ------_=_NextPart_001_01C3E59D.D922CD0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TVA comments on the framework and requirements
Hi=20 Jean-Pierre
 
Thank=20 you for your extensive input. We are very pleased that TV-Anytime finds = the IMG=20 work to be in great shape for TVA use, and also to have such a good = breadth=20 of comments on the applicability of IMGs and TVA to one=20 another.
 
To=20 make my life easier in responding and discussing this information I will = make more than one email reply covering different aspects. = Here's an=20 idea of the kind of aspects I'm thinking about:
* TVA=20 review of IMG requirements and framework IDs and changes to these=20 documents
* Separating TVA-IMG objectives to = those=20 which fit MMUSIC scope, and those which belong to other standards=20 WGs
* The=20 delivery protocol needs of TVA with IMG: existing solutions and new work = needed=20 (and where to do it)
* The=20 metadata needs of TVA with IMG: existing solutions and new work = needed (and=20 where to do it)
*=20 The conformance of TVA Phase 1 (and the up-and-coming Phase 2) to = the IMG=20 requirements & framework
* The applicability of TVA technology for = reuse in IMG=20 solutions
 
In the meantime, anyone else's ideas are more = than=20 welcome.
 
Cheers,
Rod=20 Walsh
 
 
-----Original Message-----
From: = mmusic-admin@ietf.org=20 [mailto:mmusic-admin@ietf.org]On Behalf Of ext Evain=20 Jean-Pierre
Sent: Tuesday, January 27, 2004 4:06 = PM
To:=20 mmusic@ietf.org
Subject: [MMUSIC] TVA comments on the = framework and=20 requirements

0/ Summary
TV-Anytime has reviewed=20 draft-ietf-mmusic-img-framework-02.txt
and draft-ietf-mmusic-img-req-02.txt and would like to suggest = the=20 following...

The IMG framework and = requirements are fully=20 in line with TVA objectives and we have only a very limited number of=20 suggestions for amendment of the texts.

TVA looks forward ensuring = compatibility of=20 the IMG mechanisms with our applications.
Furthermore, TVA would like to share experience with IMG and = contribute=20 to the IMG data model, service discover and service exploitation=20 mechanisms.


1/ Clarification of the role of=20 TV-Anytime
We would like = to start by=20 clarifying the relationship between TV-Anytime and MPEG-7.  The = description=20 made in Section 5.1 does not seem to be accurate and the assumption made = that=20 TV-Anytime is as a whole based on MPEG7 is not correct.  Most of = the=20 TV-Anytime schemas are based on a data model specific to = TV-Anytime. =20 TV-Anytime schemas have been optimised to describe broadcast schedules,=20 on-demand programme guides and programme events.  TV-Anytime only = uses the=20 MPEG-7's User description profile for user preferences and usage = history.=20


2/ References to TVA = specifications=20
Furthermore, the references to = TV-Anytime=20 specifications should be completed as follows using the ETSI = references:=20

Generic specification = name:
ETSI-TS 102 822; Broadcast and On-line = services:=20 Search, select, and
rightful use of=20 content on personal storage systems
Identification of specification parts and sub-parts: =
ETSI-TS 102 822-1: Phase 1 Benchmark = Features=20
ETSI-TS 102 822-2: System = Description=20
ETSI-TS 102 822-3/1: Metadata = Schemas=20
ETSI-TS 102 822-3/2: Metadata = System Aspects=20 (Fragmentation, indexing, encoding)
ETSI-TS 102 822-4: Content Referencing
ETSI-TS 102 822-6/1: Metadata Services = over a=20 Bidirectional Network - Service and transport
ETSI-TS 102 822-6/1: Metadata Services = over a=20 Bidirectional Network - Service Discovery
ETSI TS 102 822-7: Bidirectional Metadata Delivery = Protection=20


3/ TV-Anytime is totally in line = with the IMG=20 framework in terms of services, applications and entities.  = Furthermore,=20 TV-Anytime has already explored some of the delivery and transport = issues=20 addressed by IMG.


4/ The domain of application of = TVA Phase 1=20 is unidirectional broadcast assisted by bi-directional access to = ancillary=20 metadata services.  The TVA specification covers the description of = broadcast and on-demand schedules or events.  Furthermore, TVA has=20 developed a "content referencing" scheme and "resolving" mechanisms that = provide=20 enhanced flexibility in the management of schedules and associated=20 content.  The type of Phase 1 content is primarily video, audio and = ancillary services (Teletext, subtitles, design-for-all = features...).  TVA=20 Phase 2 is currently addressing media packages that will encompass all = sorts of=20 data for different media delivery.  It is therefore expected that = TVA will=20 cover a very wide range of applications and content and we would like to = ensure=20 that IMG allows to TVA data being accessed, transported and delivered = using=20 multicast or unicast delivery.


5/ As suggested in the IMG = framework, the=20 data model defined by TV-Anytime has been designed to allow an efficient = delivery, versioning and updating of our data.  This structure=20 (fragmentation, indexing, encoding, etc) is defined in our metadata=20 specification ETSI TS102822-3/2.   The TVA data model is fully = compatible with the notions of IMG descriptions, Delta IMG descriptions = and IMG=20 pointer identified in the IMG framework. The use of the TVA model is not = restricted and IMG is welcome to adopting it depending on the level of=20 granularity targeted for the IMG data types and data models (see IMG = needs in=20 Sections 3.1 and 5.3.4).  The experience of TV-Anytime is that the = data=20 model must be sufficiently explicit to further specify the metadata = service=20 mechanisms (see ETSI TS102822-6/1/2).


6/ Service discovery over = bi-directional=20 networks, commands and protocols can be found in ETSI TS102822-6.  = The TVA=20 specification make use of existing IETF mechanisms.  TVA would = certainly=20 welcome feedback from IMG experts on the solutions proposed in these = documents.=20 We look forward to collaborating with IMG to maintain / enhance = compatibility.=20 Furthermore, TVA defines service discovery mechanisms initiated by a = client=20 request for metadata services but there is no reason why TVA could not = take=20 benefit from permanent connection or access e.g. multicast to "pushed" = data. In=20 TVA, service discovery is made using UDDI or WSDL and = WS-Inspection.  Once=20 a metadata service has been "discovered", the domain of operation is the = metadata service domain.


7/ Security is addressed in ETSI = TS102822-7.=20 TV-Anytime has specified basic security mechanisms for the exchange of = metadata=20 over bi-driectional networks based on IETF TLS (Transport Layer=20 Security).


8/ TVA supports the IMG = requirements with the=20 exception of one or two minor request for clarification to be reported=20 hereafter.  More importantly,  the concurrence of the IMG = framework=20 and requirements with what TVA has done (Phase 1 plus Phase 2 covering a = wide=20 range of application and content types) encourages us in more = collaboration with=20 IMG in particular contributing to draft-luoma-mmusic-img-metadata-03 = with our=20 data model.


9/ Suggestions on the content = orientated use=20 cases in IMG requirements
TVA Phase 1=20 definitely covers 4.2.2 TV and radio programme delivery, 4.2.3 media = coverage of=20 a live event and  4.2.4 distance learning. One could certainly add = more use=20 cases such as "Trailer booking and recording", "Use of segmented content = for=20 content updates, content replacement for e.g. targeted advertising, and = virtual=20 programmes", "Discovery and access to related programmes", = etc.

TVA Phase 2 will enrich these = cases by the=20 use of media packages encompassing more content formats than audio, = video and=20 related ancillary data.


10/ Review of the IMG = requirements and=20 comments
REQ GEN-1: The = TVA data=20 model is compliant with the IMG framework and associated = requirements. =20 SP003 defines self-contained common document structure being considered = as a=20 candidate for IMG metadata format. It has a single top-level element = that=20 encloses all other TV-Anytime metadata.  TVA can be transported = efficiently=20 by fragmenting descriptions and sequential delivery of description = tables=20 clearly identified by their version for updating, replacement or=20 deletion.

REQ GEN-2: TVA anytime Phase 1 = covers a wide=20 range of applications as mentioned above.  Phase 2 will further = enlarge the=20 scope of application of TVA data.  IMG SHOULD support = these.

REQ GEN-3: SP003 defines the = identifier that=20 specifies the name of the publisher of the description. This offers the = base for=20 some mechanisms to solve issues related to simultaneous access to = multiple IMG=20 senders. 

REQ GEN-4: SP006 ensures the = modularity of=20 query/response operations relevant to IMG Operations.

REQ DEL-1: The TVA metadata model = allows=20 flexible update.

REQ DEL-2: SP003 defines = identification=20 scheme to identify particular version of a metadata fragment.  TVA = anytime=20 data fragmentation takes into account the need for efficient delivery = and=20 management of update in combination with BiM encoding.

REQ DEL-3: The TVA data model has = been=20 designed to deliver data to large audiences
REQ DEL-4: SP006 has allows to expand metadata descriptions = based on the=20 TVA versioning and notification schemes.  The TVA approach = described in=20 TS102822-6 is based on service discovery initiated by a client but could = also=20 take benefit of permanent, although possibly intermittent, = connections. =20 The fragmentation and indexing of TVA data allows small quantities of = reliably=20 connected carouselled data being transmitted including over intermittent = connections.  Descriptions are reconstructed after reception once = the=20 system has been signalled that all description elements have been=20 received.

REQ DEL-5: See REQ DEL-4 =

REQ DEL-6: TV-Anytime queries are = currently=20 client initiated.  The problem of time limited validity of pushed = data=20 remains to be addressed (TVA Phase 2).

REQ DEL-7: Sender driven aspects = will be=20 addressed in TVA Phase 2 for compliance with IMG requirements. =

REQ CUS-1: SP006 defines schemes = for=20 submission of user-centric metadata to metadata service providers and = retrieval=20 of customised data. Sender-driven uni/multicast delivery of customized = metadata=20 descriptions will be addressed in TVA Phase 2 for compliance with IMG=20 requirements.

REQ REL-1: SP003 defines an = identification=20 scheme to identify and manage a particular version of a metadata = fragment, which=20 can be a complete description or a description subset.

REQ REL-2: SP006 can manage = versions and=20 updates in client initiated transactions. Sender-driven uni/multicast = delivery=20 will be addressed in TVA Phase 2 for compliance with IMG=20 requirements.

REQ REL-3: SP006 uses http as a = base for=20 bi-directional metadata retrieval.

REQ DES-1: This issue is = particularly=20 sensitive in the case of simultaneous access to multiple IMG = senders.  This=20 is being addressed in TVA Phase 2.  However, TVA believes that the = metadata=20 provided by different sources is under the responsability of one = authority that=20 manages versions of this data.

REQ DES-2: Absolutely necessary = and TVA is=20 ready to help in order to ensure that this apply to all TVA's domains of = application.

REQ DES-3: TVA would like to = suggest a=20 clarification of this requirements with the need expressed in the IMG = framework=20 document for an IMG minimum data model.

REQ DES-4: SP003 defines = self-contained=20 common document structure that  has a single top-level element that = encloses all or part of TV-Anytime metadata.  The different = metadata tables=20 can be transmitted in separate fragments.

REQ DES-5: Agreed.  In the = case of=20 TV-Anytime, the envelope must contain all the parameters essential to = the=20 management of TVA Main and associated fragments.

REQ DES-6: TV-Anytime should be = one of the=20 identifiable metadata formats.

REQ DES-7: no comment

REQ DES-8: TVA fully supports = versioning and=20 updates.

As concerns the requirements = security=20 mentioned in Section 6, TVA only defines very generic scheme for = establishing=20 secure authentication channel between metadata sender and receiver (TS=20 102822-7).



********************************************************= **************
This=20 email and any files transmitted with it are confidential and
intended = solely=20 for the use of the individual or entity to whom they
are addressed. = If you=20 have received this email in error please notify
the system=20 manager.

*********************************************************= *************

------_=_NextPart_001_01C3E59D.D922CD0C-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jan 28 09:23:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01745 for ; Wed, 28 Jan 2004 09:23:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqaP-0001I3-Ay for mmusic-archive@odin.ietf.org; Wed, 28 Jan 2004 09:22:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SEMXt5004953 for mmusic-archive@odin.ietf.org; Wed, 28 Jan 2004 09:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqaP-0001Ho-6a for mmusic-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 09:22:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01688 for ; Wed, 28 Jan 2004 09:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlqaN-00059s-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 09:22:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlqZS-000567-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 09:21:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlqYy-00052O-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 09:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqYw-00014s-IP; Wed, 28 Jan 2004 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqYW-00012e-6v for mmusic@optimus.ietf.org; Wed, 28 Jan 2004 09:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01657 for ; Wed, 28 Jan 2004 09:20:33 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlqYU-00051t-00 for mmusic@ietf.org; Wed, 28 Jan 2004 09:20:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlqXZ-0004xh-00 for mmusic@ietf.org; Wed, 28 Jan 2004 09:19:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AlqXH-0004tG-00 for mmusic@ietf.org; Wed, 28 Jan 2004 09:19:19 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SEJGY16705 for ; Wed, 28 Jan 2004 16:19:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 16:18:23 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 16:18:23 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 16:18:23 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 16:18:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E5A9.963E76A6" Subject: RE: [MMUSIC] TVA comments on the framework and requirements Date: Wed, 28 Jan 2004 16:18:22 +0200 Message-ID: Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQA To: , X-OriginalArrivalTime: 28 Jan 2004 14:18:22.0769 (UTC) FILETIME=[96242210:01C3E5A9] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E5A9.963E76A6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All =20 Here is my summary (paraphrasing) of the TVA input which relates (only) = to document review and request for changes (with suggested text). =20 Jean-Pierre, can you validate this and check that the proposed changes = are suitable? =20 General: =20 G1. Both documents are in great shape and cover TVA ideas, use cases & = objectives very well =20 G2. TVA would like to ensure that their system fits into the IMG = framework. TVA wish to work with us to develop and exchange ideas to do = this - i.e. specify the protocols for delivery (service = discovery/announcement) possibly in MMUSIC, as well as data models = (which would be outside of MMUSIC charter) =20 =20 Requirements: =20 R1. Several TVA solutions meet several of the requirements =20 No changes needed =20 R2. on the content orientated use cases in IMG requirements: =20 TVA Phase 1 definitely covers 4.2.2 TV and radio programme delivery, = 4.2.3 media coverage of a live event and 4.2.4 distance learning. One = could certainly add more use cases such as "Trailer booking and = recording", "Use of segmented content for content updates, content = replacement for e.g. targeted advertising, and virtual programmes", = "Discovery and access to related programmes", etc. TVA Phase 2 will = enrich these cases by the use of media packages encompassing more = content formats than audio, video and related ancillary data. =20 Indeed there are many use cases beyond those given in this document. I = propose that no changes are made, however if your experience is that = certain TVA use cases have a strong impact (which is different from the = existing IMG use cases) on metadata delivery (rather than the metadata = itself), I would be keen to add just these. Are there such use cases? = Does this sound OK? =20 R3. REQ DEL-3: The TVA data model has been designed to deliver data to = large audiences =20 No changes needed =20 R4. REQ DEL-6: TV-Anytime queries are currently client initiated. The = problem of time limited validity of pushed data remains to be addressed = (TVA Phase 2) =20 No changes needed =20 R5. REQ DES-3: TVA would like to suggest a clarification of this = requirements with the need expressed in the IMG framework document for = an IMG minimum data model. =20 REQ DES-3: Whereas specific applications relying on IMGs will need = to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all). Thus, a transfer envelope format, that is uniform across all different application-specific IMG metadata formats, is needed. The payload of this transfer envelope would be some application-specific metadata. -- change to -> =20 REQ DES-3: Whereas specific applications relying on IMGs will need = to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all). Thus, a transfer envelope format, that is uniform across all different application-specific IMG metadata formats, is needed. The payload of this transfer envelope would be some application-specific metadata, and the envelope would support the maintenance of the=20 application-specific metadata including the metadata relationships=20 determined by the data model(s) used. The transfer envelope would=20 not need to be aware of the data model(s) in use. R6. REQ DES-6: TV-Anytime should be one of the identifiable metadata = formats. REQ DES-6: It SHALL be possible to deduce the metadata format from the transfer envelope. In a sense, all metadata formats will be identifiable. The solution = would need to allow "a metadata application" to recognise a data field = as "recognised from this list or not recognised". The delivery itself = must be independent of metadata format. =20 No changes needed. =20 R7. As concerns the requirements security mentioned in Section 6, TVA = only defines very generic scheme for establishing secure authentication = channel between metadata sender and receiver (TS 102822-7).=20 =20 No changes needed. =20 =20 Framework: =20 F1. The role of TVA needs clarification =A75.1, which maybe achieved by: =20 MPEG-7 [6] is a collection of XML-based description tools for general multimedia content including structured multimedia sessions. TV- Anytime Forum [7] provides descriptions based on MPEG-7 for TV specific program guides. These are likely to be limited to describe pictures, music and movies, thus it may be necessary to extend these descriptions in order to define a variety of documents, game programs, binary files, live events and so on. -- change to -> =20 MPEG-7 [6] is a collection of XML-based description tools for general multimedia content including structured multimedia sessions.=20 =20 The TV-Anytime Forum [7] provides descriptions based on XML schema=20 for TV-specific program guides. TV-Anytime uses the MPEG-7 User=20 description profile to a limited extent (for user preferences and=20 usage history) and also a TV-Anytime-specific data model for other=20 schema - which are optimised to describe broadcast schedules,=20 on-demand programme guides and programme events. =20 Also, it the following is noted although not necessary to paste into the = framework: =20 The domain of application of TVA Phase 1 is unidirectional broadcast = assisted by bi-directional access to ancillary metadata services. The = TVA specification covers the description of broadcast and on-demand = schedules or events. Furthermore, TVA has developed a "content = referencing" scheme and "resolving" mechanisms that provide enhanced = flexibility in the management of schedules and associated content. The = type of Phase 1 content is primarily video, audio and ancillary services = (Teletext, subtitles, design-for-all features...). TVA Phase 2 is = currently addressing media packages that will encompass all sorts of = data for different media delivery. It is therefore expected that TVA = will cover a very wide range of applications and content and we would = like to ensure that IMG allows to TVA data being accessed, transported = and delivered using multicast or unicast delivery. =20 =20 F2. A more specific referencing of TVA [7] is desirable, which may be = achieved by: =20 [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002. =20 -- change to -> =20 [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,=20 select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102=20 822-2: System Description, V1.1.1, October 2003. F3. The complete, delta and pointer data types are supported by TVA = metadata =20 (Note, since the framework does not recommend that MMUSIC works on the = data model, I will leave related responses to a later email - it seems = that the information data model submission from Luoma and the TVA data = models should work well together and transport of TVA metadata over IMG = delivery protocols is a natural fit) =20 No changes needed =20 F4. TVA has not specified a unidirectional transport mechanism for TVA = metadata so agrees with the proposal that an IP-based solution is = developed (not SAP) =20 No changes needed =20 F5. TVA has developed some solutions for point-to-point unicast metadata = delivery with HTTP, TLS, .... These will be interesting to scoping the = needed work for point-to-point IMG delivery (what can be reused) and = also subsequent point-to-point protocol work. =20 Open issue: we could describe and determine limitations and reuse of = these in =A75. (Proposed text is welcome!) =20 =20 Next instalment in a few days! =20 Cheers, Rod. =20 ------_=_NextPart_001_01C3E5A9.963E76A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TVA comments on the framework and requirements
Hi=20 All
 
Here=20 is my summary (paraphrasing) of the TVA input which relates (only) to = document=20 review and request for changes (with suggested = text).
 
Jean-Pierre, can you validate this and check that the proposed = changes=20 are suitable?
 
General:
 
G1. Both documents are in great shape and cover TVA ideas, = use cases=20 & objectives very well
 
G2. TVA would like to ensure that their system fits into = the IMG=20 framework. TVA wish to work with us to develop and exchange ideas to do = this -=20 i.e. specify the protocols for delivery (service discovery/announcement) = possibly in MMUSIC, as well as data models (which would be outside of = MMUSIC=20 charter)
 
 
Requirements:
 
R1.=20 Several TVA solutions meet several of the = requirements
 
No changes = needed
 
R2. on the content orientated use cases in IMG=20 requirements:
 
TVA Phase 1 definitely = covers 4.2.2=20 TV and radio programme delivery, 4.2.3 media coverage of a live event = and =20 4.2.4 distance learning. One could certainly add more use cases such as = "Trailer=20 booking and recording", "Use of segmented content for content updates, = content=20 replacement for e.g. targeted advertising, and virtual programmes", = "Discovery=20 and access to related programmes", etc.   TVA Phase 2 will enrich these cases by the use of = media=20 packages encompassing more content formats than audio, video and related = ancillary data.
 
Indeed=20 there are many use cases beyond those given in this document. I propose = that no=20 changes are made, however if your experience is that certain TVA use = cases have=20 a strong impact (which is different from the existing IMG use = cases) on=20 metadata delivery (rather than the metadata itself), I would be keen to = add just=20 these. Are there such use cases? Does this sound OK?
 
R3. REQ DEL-3: The TVA data model = has been=20 designed to deliver data to large audiences <However, TVA does = not currently=20 specify IP delivery with massive scalability (such as one-to-very-many=20 multicast) and so this is an open requirement for TVA=20 too>
 
No changes=20 needed
 
R4. REQ DEL-6: TV-Anytime = queries are=20 currently client initiated.  The problem of time limited validity = of pushed=20 data remains to be addressed (TVA Phase 2) <and so = this is=20 an open requirement for TVA = too>
 
No changes = needed
 
R5. REQ DES-3:=20 TVA would like to suggest a clarification of this requirements with the = need=20 expressed in the IMG framework document for an IMG minimum data=20 model.
 
    REQ DES-3: Whereas = specific=20 applications relying on IMGs will need to
   select one or more = specific=20 application-specific metadata formats
   (standard, syntax, = etc.), the IMG=20 system MUST be independent of this
   (it may be aware, but it = will=20 operate in the same way for all).

   Thus, a transfer = envelope format,=20 that is uniform across all
  =20 different application-specific IMG metadata formats, is needed.=20 The
   payload of = this=20 transfer envelope would be some application-specific
  =20 metadata.
-- change=20 to ->
 
    = REQ DES-3:=20 Whereas specific applications relying on IMGs will need to
   select one or more = specific=20 application-specific metadata formats
   (standard, syntax, = etc.), the IMG=20 system MUST be independent of this
   (it may be aware, but it = will=20 operate in the same way for all).

   Thus, a transfer = envelope format,=20 that is uniform across all
  =20 different application-specific IMG metadata formats, is needed.=20 The
   payload of = this=20 transfer envelope would be some application-specific
   metadata, and the = envelope would=20 support the maintenance of the=20
   application-specific metadata including the = metadata=20 relationships=20
   determined by the data model(s) used. = The=20 transfer envelope would=20
   not need to be aware of the data model(s) = in=20 use.
R6. REQ DES-6:=20 TV-Anytime should be one of the identifiable metadata=20 formats.
   REQ DES-6: It SHALL be = possible to=20 deduce the metadata format from
  =20 the transfer envelope.
In a sense, all = metadata=20 formats will be identifiable. The solution would need to allow "a=20 metadata application" to recognise a data field as "recognised from = this=20 list or not recognised". The delivery itself must be independent of = metadata=20 format.
&= nbsp;
No changes=20 needed.
 
R7. As concerns the requirements security mentioned in = Section 6, TVA=20 only defines very generic scheme for establishing secure authentication = channel=20 between metadata sender and receiver (TS 102822-7).=20
 
No changes=20 needed.
 
 
Framework:
 
F1.=20 The role of TVA needs clarification =A75.1, which maybe achieved=20 by:
 
   MPEG-7 [6] is a = collection of=20 XML-based description tools for general
   multimedia content = including=20 structured multimedia sessions. TV-
   Anytime Forum [7] = provides=20 descriptions based on MPEG-7 for TV
   specific program guides. = These are=20 likely to be limited to describe
  =20 pictures, music and movies, thus it may be necessary to extend=20 these
   = descriptions in=20 order to define a variety of documents, game
   programs, binary files, = live=20 events and so on.
-- change to = ->
 
   MPEG-7 [6] is a = collection of=20 XML-based description tools for general
   multimedia content = including=20 structured multimedia sessions. =
   =
   The TV-Anytime Forum [7] provides = descriptions=20 based on XML=20 schema 
  =20 for TV-specific program guides. TV-Anytime uses=20 the MPEG-7=20 User
   description profile to a limited = extent (for=20 user preferences and
   usage=20 history) and=20 also a TV-Anytime-specific data model for other=20
   schema - which are optimised to = describe=20 broadcast schedules,
   on-demand programme guides and = programme=20 events.
 
Also, it the following is = noted=20 although not necessary to paste into the=20 framework:
 
The domain = of=20 application of TVA Phase 1 is unidirectional broadcast assisted by=20 bi-directional access to ancillary metadata services.  The TVA=20 specification covers the description of broadcast and on-demand = schedules or=20 events.  Furthermore, TVA has developed a "content referencing" = scheme and=20 "resolving" mechanisms that provide enhanced flexibility in the = management of=20 schedules and associated content.  The type of Phase 1 content is = primarily=20 video, audio and ancillary services (Teletext, subtitles, design-for-all = features...).  TVA Phase 2 is currently addressing media packages = that will=20 encompass all sorts of data for different media delivery.  It is = therefore=20 expected that TVA will cover a very wide range of applications and = content and=20 we would like to ensure that IMG allows to TVA data being accessed, = transported=20 and delivered using multicast or unicast=20 delivery.
 
 
F2. A = more specific=20 referencing of TVA [7] is desirable, which may be achieved=20 by:
 
   [7] T.-A. Forum, "Metadata = specification=20 S-3," TV-Anytime Forum
   = Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June=20 2002.
<= /SPAN> 
-- = change to=20 ->
&= nbsp;
   [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,=20
   select, and rightful use of content on personal = storage=20 systems
   ("TV-Anytime Phase 1"); Part 2: System = description,"=20 ETSI-TS 102=20
   822-2: System=20 Description, V1.1.1, October=20 2003.

= F3. The complete,=20 delta and pointer data types are supported by TVA = metadata
 
(Note,=20 since the framework does not recommend that MMUSIC works on the data = model, I=20 will leave related responses to a later email - it seems that the = information=20 data model submission from Luoma and the TVA data models should work = well=20 together and transport of TVA metadata over IMG delivery protocols is a = natural=20 fit)
 
No changes=20 needed
 
F4.=20 TVA has not specified a unidirectional transport mechanism for TVA = metadata so=20 agrees with the proposal that an IP-based solution is developed (not=20 SAP)
 
No=20 changes needed
 
F5.=20 TVA has developed some solutions for point-to-point unicast metadata = delivery=20 with HTTP, TLS, .... These will be interesting to scoping the needed = work for=20 point-to-point IMG delivery (what can be reused) and also subsequent=20 point-to-point protocol work.
 
Open issue: we could describe and determine = limitations and=20 reuse of these in =A75. (Proposed text is=20 welcome!)
 
 
Next instalment in a few=20 days!
 
Cheers, = Rod.
 
------_=_NextPart_001_01C3E5A9.963E76A6-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jan 29 06:11:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12758 for ; Thu, 29 Jan 2004 06:11:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmA4q-0006ln-9k for mmusic-archive@odin.ietf.org; Thu, 29 Jan 2004 06:11:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TBBGoW026016 for mmusic-archive@odin.ietf.org; Thu, 29 Jan 2004 06:11:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmA4q-0006lM-1z for mmusic-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 06:11:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12753 for ; Thu, 29 Jan 2004 06:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmA4m-00053T-00 for mmusic-web-archive@ietf.org; Thu, 29 Jan 2004 06:11:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmA3p-0004yJ-00 for mmusic-web-archive@ietf.org; Thu, 29 Jan 2004 06:10:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmA3g-0004tF-00 for mmusic-web-archive@ietf.org; Thu, 29 Jan 2004 06:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmA3d-0006Zq-VL; Thu, 29 Jan 2004 06:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmA2t-0004OB-QQ for mmusic@optimus.ietf.org; Thu, 29 Jan 2004 06:09:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12735 for ; Thu, 29 Jan 2004 06:09:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmA2q-0004so-00 for mmusic@ietf.org; Thu, 29 Jan 2004 06:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmA1t-0004nq-00 for mmusic@ietf.org; Thu, 29 Jan 2004 06:08:14 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AmA1O-0004i0-00 for mmusic@ietf.org; Thu, 29 Jan 2004 06:07:42 -0500 Received: from mangole ([130.209.247.112]:1035 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AmA0v-0005NU-00; Thu, 29 Jan 2004 11:07:13 +0000 Date: Thu, 29 Jan 2004 11:07:31 +0000 From: Colin Perkins To: mmusic@ietf.org Cc: Joerg Ott Message-Id: <20040129110731.67218e25.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG last call: draft-ietf-mmusic-anat-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, We have received a request to consider draft-ietf-mmusic-anat-00.txt "The Alternative Network Address Types Semantics for the SDP Grouping Framework" for publication as a proposed standard RFC. Accordingly, this message is to announce the start of a working group last call for comments on this draft. Please send any comments to the mailing list by 13th February 2004. Colin and Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jan 30 12:17:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29408 for ; Fri, 30 Jan 2004 12:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcGO-0003xc-EG for mmusic-archive@odin.ietf.org; Fri, 30 Jan 2004 12:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UHH4QK015220 for mmusic-archive@odin.ietf.org; Fri, 30 Jan 2004 12:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcGO-0003xP-A0 for mmusic-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 12:17:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29370 for ; Fri, 30 Jan 2004 12:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcGM-0002Sf-00 for mmusic-web-archive@ietf.org; Fri, 30 Jan 2004 12:17:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcEx-0002AW-00 for mmusic-web-archive@ietf.org; Fri, 30 Jan 2004 12:15:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmcDR-0001na-00 for mmusic-web-archive@ietf.org; Fri, 30 Jan 2004 12:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcDQ-0003n1-Sb; Fri, 30 Jan 2004 12:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcCp-0003lK-2E for mmusic@optimus.ietf.org; Fri, 30 Jan 2004 12:13:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29079 for ; Fri, 30 Jan 2004 12:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcCn-0001h6-00 for mmusic@ietf.org; Fri, 30 Jan 2004 12:13:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcBn-0001Vl-00 for mmusic@ietf.org; Fri, 30 Jan 2004 12:12:22 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AmcAu-0001H4-00 for mmusic@ietf.org; Fri, 30 Jan 2004 12:11:24 -0500 Received: from gnvasrelay1a.gva.ebu.ch (unverified [10.73.222.207]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 30 Jan 2004 18:10:52 +0100 Received: from gnvasmail1a.gva.ebu.ch ([10.73.222.209]) by gnvasrelay1a.gva.ebu.ch with Microsoft SMTPSVC (5.0.2195.6713); Fri, 30 Jan 2004 18:10:52 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E754.03F9C2F8" Subject: RE: [MMUSIC] TVA comments on the framework and requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 30 Jan 2004 18:10:52 +0100 Message-ID: <9BB211A65FCBFD43B95F67BA2485759D1F8F61@gnvasmail1a.gva.ebu.ch> Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAq51DwAHJBLlA= From: "Evain Jean-Pierre" To: Cc: X-OriginalArrivalTime: 30 Jan 2004 17:10:52.0790 (UTC) FILETIME=[040F8160:01C3E754] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,EXCUSE_16, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E754.03F9C2F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rod, =20 looks great to me. =20 I'll tell you more by responding to your other message that I can already see in the queue. =20 Regards, =20 Jean-Pierre -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: mercredi, 28. janvier 2004 13:54 To: Evain Jean-Pierre Cc: mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 Hi Jean-Pierre =20 Thank you for your extensive input. We are very pleased that TV-Anytime finds the IMG work to be in great shape for TVA use, and also to have such a good breadth of comments on the applicability of IMGs and TVA to one another. =20 To make my life easier in responding and discussing this information I will make more than one email reply covering different aspects. Here's an idea of the kind of aspects I'm thinking about: * TVA review of IMG requirements and framework IDs and changes to these documents * Separating TVA-IMG objectives to those which fit MMUSIC scope, and those which belong to other standards WGs * The delivery protocol needs of TVA with IMG: existing solutions and new work needed (and where to do it) * The metadata needs of TVA with IMG: existing solutions and new work needed (and where to do it) =09 * The conformance of TVA Phase 1 (and the up-and-coming Phase 2) to the IMG requirements & framework * The applicability of TVA technology for reuse in IMG solutions =20 In the meantime, anyone else's ideas are more than welcome. =20 Cheers, Rod Walsh =20 =20 -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of ext Evain Jean-Pierre Sent: Tuesday, January 27, 2004 4:06 PM To: mmusic@ietf.org Subject: [MMUSIC] TVA comments on the framework and requirements =09 =09 0/ Summary=20 TV-Anytime has reviewed draft-ietf-mmusic-img-framework-02.txt=20 and draft-ietf-mmusic-img-req-02.txt and would like to suggest the following...=20 The IMG framework and requirements are fully in line with TVA objectives and we have only a very limited number of suggestions for amendment of the texts. TVA looks forward ensuring compatibility of the IMG mechanisms with our applications.=20 Furthermore, TVA would like to share experience with IMG and contribute to the IMG data model, service discover and service exploitation mechanisms. 1/ Clarification of the role of TV-Anytime=20 We would like to start by clarifying the relationship between TV-Anytime and MPEG-7. The description made in Section 5.1 does not seem to be accurate and the assumption made that TV-Anytime is as a whole based on MPEG7 is not correct. Most of the TV-Anytime schemas are based on a data model specific to TV-Anytime. TV-Anytime schemas have been optimised to describe broadcast schedules, on-demand programme guides and programme events. TV-Anytime only uses the MPEG-7's User description profile for user preferences and usage history.=20 2/ References to TVA specifications=20 Furthermore, the references to TV-Anytime specifications should be completed as follows using the ETSI references:=20 Generic specification name:=20 ETSI-TS 102 822; Broadcast and On-line services: Search, select, and rightful use of content on personal storage systems=20 Identification of specification parts and sub-parts:=20 ETSI-TS 102 822-1: Phase 1 Benchmark Features=20 ETSI-TS 102 822-2: System Description=20 ETSI-TS 102 822-3/1: Metadata Schemas=20 ETSI-TS 102 822-3/2: Metadata System Aspects (Fragmentation, indexing, encoding)=20 ETSI-TS 102 822-4: Content Referencing=20 ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - Service and transport=20 ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - Service Discovery=20 ETSI TS 102 822-7: Bidirectional Metadata Delivery Protection=20 3/ TV-Anytime is totally in line with the IMG framework in terms of services, applications and entities. Furthermore, TV-Anytime has already explored some of the delivery and transport issues addressed by IMG. 4/ The domain of application of TVA Phase 1 is unidirectional broadcast assisted by bi-directional access to ancillary metadata services. The TVA specification covers the description of broadcast and on-demand schedules or events. Furthermore, TVA has developed a "content referencing" scheme and "resolving" mechanisms that provide enhanced flexibility in the management of schedules and associated content. The type of Phase 1 content is primarily video, audio and ancillary services (Teletext, subtitles, design-for-all features...). TVA Phase 2 is currently addressing media packages that will encompass all sorts of data for different media delivery. It is therefore expected that TVA will cover a very wide range of applications and content and we would like to ensure that IMG allows to TVA data being accessed, transported and delivered using multicast or unicast delivery. 5/ As suggested in the IMG framework, the data model defined by TV-Anytime has been designed to allow an efficient delivery, versioning and updating of our data. This structure (fragmentation, indexing, encoding, etc) is defined in our metadata specification ETSI TS102822-3/2. The TVA data model is fully compatible with the notions of IMG descriptions, Delta IMG descriptions and IMG pointer identified in the IMG framework. The use of the TVA model is not restricted and IMG is welcome to adopting it depending on the level of granularity targeted for the IMG data types and data models (see IMG needs in Sections 3.1 and 5.3.4). The experience of TV-Anytime is that the data model must be sufficiently explicit to further specify the metadata service mechanisms (see ETSI TS102822-6/1/2). 6/ Service discovery over bi-directional networks, commands and protocols can be found in ETSI TS102822-6. The TVA specification make use of existing IETF mechanisms. TVA would certainly welcome feedback from IMG experts on the solutions proposed in these documents. We look forward to collaborating with IMG to maintain / enhance compatibility. Furthermore, TVA defines service discovery mechanisms initiated by a client request for metadata services but there is no reason why TVA could not take benefit from permanent connection or access e.g. multicast to "pushed" data. In TVA, service discovery is made using UDDI or WSDL and WS-Inspection. Once a metadata service has been "discovered", the domain of operation is the metadata service domain. 7/ Security is addressed in ETSI TS102822-7. TV-Anytime has specified basic security mechanisms for the exchange of metadata over bi-driectional networks based on IETF TLS (Transport Layer Security). 8/ TVA supports the IMG requirements with the exception of one or two minor request for clarification to be reported hereafter. More importantly, the concurrence of the IMG framework and requirements with what TVA has done (Phase 1 plus Phase 2 covering a wide range of application and content types) encourages us in more collaboration with IMG in particular contributing to draft-luoma-mmusic-img-metadata-03 with our data model. 9/ Suggestions on the content orientated use cases in IMG requirements=20 TVA Phase 1 definitely covers 4.2.2 TV and radio programme delivery, 4.2.3 media coverage of a live event and 4.2.4 distance learning. One could certainly add more use cases such as "Trailer booking and recording", "Use of segmented content for content updates, content replacement for e.g. targeted advertising, and virtual programmes", "Discovery and access to related programmes", etc. TVA Phase 2 will enrich these cases by the use of media packages encompassing more content formats than audio, video and related ancillary data. 10/ Review of the IMG requirements and comments=20 REQ GEN-1: The TVA data model is compliant with the IMG framework and associated requirements. SP003 defines self-contained common document structure being considered as a candidate for IMG metadata format. It has a single top-level element that encloses all other TV-Anytime metadata. TVA can be transported efficiently by fragmenting descriptions and sequential delivery of description tables clearly identified by their version for updating, replacement or deletion. REQ GEN-2: TVA anytime Phase 1 covers a wide range of applications as mentioned above. Phase 2 will further enlarge the scope of application of TVA data. IMG SHOULD support these. REQ GEN-3: SP003 defines the identifier that specifies the name of the publisher of the description. This offers the base for some mechanisms to solve issues related to simultaneous access to multiple IMG senders. =20 REQ GEN-4: SP006 ensures the modularity of query/response operations relevant to IMG Operations.=20 REQ DEL-1: The TVA metadata model allows flexible update.=20 REQ DEL-2: SP003 defines identification scheme to identify particular version of a metadata fragment. TVA anytime data fragmentation takes into account the need for efficient delivery and management of update in combination with BiM encoding. REQ DEL-3: The TVA data model has been designed to deliver data to large audiences=20 REQ DEL-4: SP006 has allows to expand metadata descriptions based on the TVA versioning and notification schemes. The TVA approach described in TS102822-6 is based on service discovery initiated by a client but could also take benefit of permanent, although possibly intermittent, connections. The fragmentation and indexing of TVA data allows small quantities of reliably connected carouselled data being transmitted including over intermittent connections. Descriptions are reconstructed after reception once the system has been signalled that all description elements have been received. REQ DEL-5: See REQ DEL-4=20 REQ DEL-6: TV-Anytime queries are currently client initiated. The problem of time limited validity of pushed data remains to be addressed (TVA Phase 2). REQ DEL-7: Sender driven aspects will be addressed in TVA Phase 2 for compliance with IMG requirements.=20 REQ CUS-1: SP006 defines schemes for submission of user-centric metadata to metadata service providers and retrieval of customised data. Sender-driven uni/multicast delivery of customized metadata descriptions will be addressed in TVA Phase 2 for compliance with IMG requirements. REQ REL-1: SP003 defines an identification scheme to identify and manage a particular version of a metadata fragment, which can be a complete description or a description subset. REQ REL-2: SP006 can manage versions and updates in client initiated transactions. Sender-driven uni/multicast delivery will be addressed in TVA Phase 2 for compliance with IMG requirements. REQ REL-3: SP006 uses http as a base for bi-directional metadata retrieval.=20 REQ DES-1: This issue is particularly sensitive in the case of simultaneous access to multiple IMG senders. This is being addressed in TVA Phase 2. However, TVA believes that the metadata provided by different sources is under the responsability of one authority that manages versions of this data. REQ DES-2: Absolutely necessary and TVA is ready to help in order to ensure that this apply to all TVA's domains of application. REQ DES-3: TVA would like to suggest a clarification of this requirements with the need expressed in the IMG framework document for an IMG minimum data model. REQ DES-4: SP003 defines self-contained common document structure that has a single top-level element that encloses all or part of TV-Anytime metadata. The different metadata tables can be transmitted in separate fragments. REQ DES-5: Agreed. In the case of TV-Anytime, the envelope must contain all the parameters essential to the management of TVA Main and associated fragments. REQ DES-6: TV-Anytime should be one of the identifiable metadata formats.=20 REQ DES-7: no comment=20 REQ DES-8: TVA fully supports versioning and updates.=20 As concerns the requirements security mentioned in Section 6, TVA only defines very generic scheme for establishing secure authentication channel between metadata sender and receiver (TS 102822-7).=20 =09 =09 =09 ********************************************************************** 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 system manager. =09 =09 ********************************************************************** =09 =09 ********************************************************************** 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 system manager. ********************************************************************** =20 ------_=_NextPart_001_01C3E754.03F9C2F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello=20 Rod,
 
looks=20 great to me.
 
I'll=20 tell you more by responding to your other message that I can already s= ee in=20 the queue.
 
Regards,
 
Jean-Pierre
-----Original Message-----
From:=20 Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]
Sent: mercred= i,=20 28. janvier 2004 13:54
To: Evain Jean-Pierre
Cc:=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the frame= work=20 and requirements

Hi=20 Jean-Pierre
 
Thank you for your extensive input. We are ver= y=20 pleased that TV-Anytime finds the IMG work to be in great shape for = TVA=20 use, and also to have such a good breadth of comments on the applicabilit= y of=20 IMGs and TVA to one another.
 
To=20 make my life easier in responding and discussing this information I will= make more than one email reply covering different aspects. Her= e's an=20 idea of the kind of aspects I'm thinking about:
*=20 TVA review of IMG requirements and framework IDs and changes to these=20 documents
* Separating TVA-IMG objectives to t= hose=20 which fit MMUSIC scope, and those which belong to other standards=20 WGs
*=20 The delivery protocol needs of TVA with IMG: existing solutions and new w= ork=20 needed (and where to do it)
*=20 The metadata needs of TVA with IMG: existing solutions and new work= needed (and where to do it)
*=20 The conformance of TVA Phase 1 (and the up-and-coming Phase 2) to th= e IMG=20 requirements & framework
* The applica= bility of=20 TVA technology for reuse in IMG solutions
 
In the meanti= me,=20 anyone else's ideas are more than welcome.
 
Cheers,
Rod=20 Walsh
 
 
-----Original Message-----
From: mmusic-admin@ietf.org= [mailto:mmusic-admin@ietf.org]On Behalf Of ext Evain=20 Jean-Pierre
Sent: Tuesday, January 27, 2004 4:06 PM
To:=20 mmusic@ietf.org
Subject: [MMUSIC] TVA comments on the framework= and=20 requirements

0/ Summary
TV-Anytime has reviewed=20 draft-ietf-mmusic-img-framework-02.txt
and draft-ietf-mmusic-img-req-02.txt and would like to suggest t= he=20 following...

The IMG framework and requirements= are=20 fully in line with TVA objectives and we have only a very limited number = of=20 suggestions for amendment of the texts.

TVA looks forward ensuring compati= bility of=20 the IMG mechanisms with our applications.
Furthermore, TVA would like to share experience with IMG and con= tribute=20 to the IMG data model, service discover and service exploitation=20 mechanisms.


1/ Clarification of the role of=20 TV-Anytime
We would like t= o start=20 by clarifying the relationship between TV-Anytime and MPEG-7.  The= description made in Section 5.1 does not seem to be accurate and the=20 assumption made that TV-Anytime is as a whole based on MPEG7 is not=20 correct.  Most of the TV-Anytime schemas are based on a data model= specific to TV-Anytime.  TV-Anytime schemas have been optimised to= describe broadcast schedules, on-demand programme guides and programme= events.  TV-Anytime only uses the MPEG-7's User description profile= for=20 user preferences and usage history.


2/ References to TVA specification= s=20
Furthermore, the references to TV= -Anytime=20 specifications should be completed as follows using the ETSI=20 references:

Generic specification name:=
ETSI-TS 102 822; Broadcast and O= n-line=20 services: Search, select, and
rightful use of content on personal storage systems
<= FONT=20 face=3D"Courier New" size=3D2>Identification of specification parts and= sub-parts:
ETSI-TS 102 82= 2-1: Phase=20 1 Benchmark Features
ETSI-= TS 102=20 822-2: System Description
= ETSI-TS=20 102 822-3/1: Metadata Schemas
ETSI-TS 102 822-3/2: Metadata System Aspects (Fragmentation, ind= exing,=20 encoding)
ETSI-TS 102 822-= 4:=20 Content Referencing
ETSI-T= S 102=20 822-6/1: Metadata Services over a Bidirectional Network - Service and=20 transport
ETSI-TS 102 822-= 6/1:=20 Metadata Services over a Bidirectional Network - Service Discovery=
ETSI TS 102 822-7: Bidirectional= Metadata=20 Delivery Protection


3/ TV-Anytime is totally in line w= ith the=20 IMG framework in terms of services, applications and entities. =20 Furthermore, TV-Anytime has already explored some of the delivery and=20 transport issues addressed by IMG.


4/ The domain of application of TV= A Phase 1=20 is unidirectional broadcast assisted by bi-directional access to ancillar= y=20 metadata services.  The TVA specification covers the description of= broadcast and on-demand schedules or events.  Furthermore, TVA has= developed a "content referencing" scheme and "resolving" mechanisms that= provide enhanced flexibility in the management of schedules and associat= ed=20 content.  The type of Phase 1 content is primarily video, audio and= ancillary services (Teletext, subtitles, design-for-all features...).&nb= sp;=20 TVA Phase 2 is currently addressing media packages that will encompass al= l=20 sorts of data for different media delivery.  It is therefore expecte= d=20 that TVA will cover a very wide range of applications and content and we = would=20 like to ensure that IMG allows to TVA data being accessed, transported an= d=20 delivered using multicast or unicast delivery.


5/ As suggested in the IMG framewo= rk, the=20 data model defined by TV-Anytime has been designed to allow an efficient= delivery, versioning and updating of our data.  This structure=20 (fragmentation, indexing, encoding, etc) is defined in our metadata=20 specification ETSI TS102822-3/2.   The TVA data model is fully= compatible with the notions of IMG descriptions, Delta IMG descriptions = and=20 IMG pointer identified in the IMG framework. The use of the TVA model is = not=20 restricted and IMG is welcome to adopting it depending on the level of=20 granularity targeted for the IMG data types and data models (see IMG need= s in=20 Sections 3.1 and 5.3.4).  The experience of TV-Anytime is that the d= ata=20 model must be sufficiently explicit to further specify the metadata servi= ce=20 mechanisms (see ETSI TS102822-6/1/2).


6/ Service discovery over bi-direc= tional=20 networks, commands and protocols can be found in ETSI TS102822-6.  T= he=20 TVA specification make use of existing IETF mechanisms.  TVA would= certainly welcome feedback from IMG experts on the solutions proposed in= these=20 documents. We look forward to collaborating with IMG to maintain / enhanc= e=20 compatibility. Furthermore, TVA defines service discovery mechanisms init= iated=20 by a client request for metadata services but there is no reason why TVA = could=20 not take benefit from permanent connection or access e.g. multicast to=20 "pushed" data. In TVA, service discovery is made using UDDI or WSDL and= WS-Inspection.  Once a metadata service has been "discovered", the = domain=20 of operation is the metadata service domain.


7/ Security is addressed in ETSI= TS102822-7. TV-Anytime has specified basic security mechanisms for the= exchange of metadata over bi-driectional networks based on IETF TLS (Tra= nsport=20 Layer Security).


8/ TVA supports the IMG requiremen= ts with=20 the exception of one or two minor request for clarification to be reporte= d=20 hereafter.  More importantly,  the concurrence of the IMG frame= work=20 and requirements with what TVA has done (Phase 1 plus Phase 2 covering a = wide=20 range of application and content types) encourages us in more collaborati= on=20 with IMG in particular contributing to draft-luoma-mmusic-img-metadata-03= with=20 our data model.


9/ Suggestions on the content orie= ntated=20 use cases in IMG requirements
TVA=20 Phase 1 definitely covers 4.2.2 TV and radio programme delivery, 4.2.3 me= dia=20 coverage of a live event and  4.2.4 distance learning. One could=20 certainly add more use cases such as "Trailer booking and recording", "Us= e of=20 segmented content for content updates, content replacement for e.g. targe= ted=20 advertising, and virtual programmes", "Discovery and access to related=20 programmes", etc.

TVA Phase 2 will enrich these case= s by the=20 use of media packages encompassing more content formats than audio, video= and=20 related ancillary data.


10/ Review of the IMG requirements= and=20 comments
REQ GEN-1: The TV= A data=20 model is compliant with the IMG framework and associated requirements.&nb= sp;=20 SP003 defines self-contained common document structure being considered a= s a=20 candidate for IMG metadata format. It has a single top-level element that= encloses all other TV-Anytime metadata.  TVA can be transported=20 efficiently by fragmenting descriptions and sequential delivery of descri= ption=20 tables clearly identified by their version for updating, replacement or= deletion.

REQ GEN-2: TVA anytime Phase 1 cov= ers a=20 wide range of applications as mentioned above.  Phase 2 will further= enlarge the scope of application of TVA data.  IMG SHOULD support= these.

REQ GEN-3: SP003 defines the ident= ifier=20 that specifies the name of the publisher of the description. This offers = the=20 base for some mechanisms to solve issues related to simultaneous access t= o=20 multiple IMG senders. 

REQ GEN-4: SP006 ensures the modul= arity of=20 query/response operations relevant to IMG Operations.

REQ DEL-1: The TVA metadata model = allows=20 flexible update.

REQ DEL-2: SP003 defines identific= ation=20 scheme to identify particular version of a metadata fragment.  TVA= anytime data fragmentation takes into account the need for efficient del= ivery=20 and management of update in combination with BiM encoding.

REQ DEL-3: The TVA data model has = been=20 designed to deliver data to large audiences
REQ DEL-4: SP006 has allows to expand metad= ata=20 descriptions based on the TVA versioning and notification schemes.  = The=20 TVA approach described in TS102822-6 is based on service discovery initia= ted=20 by a client but could also take benefit of permanent, although possibly= intermittent, connections.  The fragmentation and indexing of TVA d= ata=20 allows small quantities of reliably connected carouselled data being=20 transmitted including over intermittent connections.  Descriptions a= re=20 reconstructed after reception once the system has been signalled that all= description elements have been received.

REQ DEL-5: See REQ DEL-4

REQ DEL-6: TV-Anytime queries are = currently=20 client initiated.  The problem of time limited validity of pushed da= ta=20 remains to be addressed (TVA Phase 2).

REQ DEL-7: Sender driven aspects w= ill be=20 addressed in TVA Phase 2 for compliance with IMG requirements.

REQ CUS-1: SP006 defines schemes f= or=20 submission of user-centric metadata to metadata service providers and=20 retrieval of customised data. Sender-driven uni/multicast delivery of=20 customized metadata descriptions will be addressed in TVA Phase 2 for=20 compliance with IMG requirements.

REQ REL-1: SP003 defines an identi= fication=20 scheme to identify and manage a particular version of a metadata fragment= ,=20 which can be a complete description or a description subset.

REQ REL-2: SP006 can manage versio= ns and=20 updates in client initiated transactions. Sender-driven uni/multicast del= ivery=20 will be addressed in TVA Phase 2 for compliance with IMG=20 requirements.

REQ REL-3: SP006 uses http as a ba= se for=20 bi-directional metadata retrieval.

REQ DES-1: This issue is particula= rly=20 sensitive in the case of simultaneous access to multiple IMG senders.&nbs= p;=20 This is being addressed in TVA Phase 2.  However, TVA believes that = the=20 metadata provided by different sources is under the responsability of one= authority that manages versions of this data.

REQ DES-2: Absolutely necessary an= d TVA is=20 ready to help in order to ensure that this apply to all TVA's domains of= application.

REQ DES-3: TVA would like to sugge= st a=20 clarification of this requirements with the need expressed in the IMG=20 framework document for an IMG minimum data model.

REQ DES-4: SP003 defines self-cont= ained=20 common document structure that  has a single top-level element that= encloses all or part of TV-Anytime metadata.  The different metadat= a=20 tables can be transmitted in separate fragments.

REQ DES-5: Agreed.  In the ca= se of=20 TV-Anytime, the envelope must contain all the parameters essential to the= management of TVA Main and associated fragments.

REQ DES-6: TV-Anytime should be on= e of the=20 identifiable metadata formats.

REQ DES-7: no comment

REQ DES-8: TVA fully supports vers= ioning=20 and updates.

As concerns the requirements secur= ity=20 mentioned in Section 6, TVA only defines very generic scheme for establis= hing=20 secure authentication channel between metadata sender and receiver (TS=20 102822-7).



********************************************************= **************
This=20 email and any files transmitted with it are confidential and
intended= solely for the use of the individual or entity to whom they
are addre= ssed.=20 If you have received this email in error please notify
the system=20 manager.

*********************************************************= *************



**********************************************************************
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 system manager.

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

 =00 ------_=_NextPart_001_01C3E754.03F9C2F8-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jan 30 17:13:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25153 for ; Fri, 30 Jan 2004 17:13:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgtI-0006xl-1C for mmusic-archive@odin.ietf.org; Fri, 30 Jan 2004 17:13:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UMDVeB026761 for mmusic-archive@odin.ietf.org; Fri, 30 Jan 2004 17:13:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgtH-0006xX-NV for mmusic-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 17:13:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24511 for ; Fri, 30 Jan 2004 17:13:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgtE-0001FQ-00 for mmusic-web-archive@ietf.org; Fri, 30 Jan 2004 17:13:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgsS-00017C-00 for mmusic-web-archive@ietf.org; Fri, 30 Jan 2004 17:12:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amgrp-0000zg-00 for mmusic-web-archive@ietf.org; Fri, 30 Jan 2004 17:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amgrp-0006pU-Nc; Fri, 30 Jan 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcY0-0004iD-Gf for mmusic@optimus.ietf.org; Fri, 30 Jan 2004 12:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02076 for ; Fri, 30 Jan 2004 12:35:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcXy-0006jn-00 for mmusic@ietf.org; Fri, 30 Jan 2004 12:35:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcWS-0006Om-00 for mmusic@ietf.org; Fri, 30 Jan 2004 12:33:50 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AmcUz-0005tL-00 for mmusic@ietf.org; Fri, 30 Jan 2004 12:32:09 -0500 Received: from gnvasrelay1a.gva.ebu.ch (unverified [10.73.222.207]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 30 Jan 2004 18:31:34 +0100 Received: from gnvasmail1a.gva.ebu.ch ([10.73.222.209]) by gnvasrelay1a.gva.ebu.ch with Microsoft SMTPSVC (5.0.2195.6713); Fri, 30 Jan 2004 18:31:33 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E756.E7CA540A" Subject: RE: [MMUSIC] TVA comments on the framework and requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 30 Jan 2004 18:31:33 +0100 Message-ID: <9BB211A65FCBFD43B95F67BA2485759D1F8F62@gnvasmail1a.gva.ebu.ch> Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjA= From: "Evain Jean-Pierre" To: , X-OriginalArrivalTime: 30 Jan 2004 17:31:33.0977 (UTC) FILETIME=[E7DD9C90:01C3E756] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E756.E7CA540A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Rod, =20 as announced earlier... =20 General: Only one question on the metadata model. I have seen a first draft from Oomu. Isn't it within MMUSIC? If not, can you tell me more? =20 Requirements: =20 R2: Trailer booking for instance is not based on the use of a schedule. It should be possible e.g. to book the recording of a piece of content from a trailer proposed on the website. Full content would be recorded when ready for streaming (e.g. Unicast following this client request). The same schemes as for broadactsing should apply to multicast. I'll try to provide you with some text next week. =20 R5: seems to respond to the point at this stage =20 Framework: =20 F1: okay =20 F2:=20 I don't see why you shouldn't list them all. Each of them is relevant ot my comments and to the IMG requirements and frameowkr at one moment or another. What woul be the problem with a more comprehensive list of references? Generic specification name:=20 ETSI-TS 102 822; Broadcast and On-line services: Search, select, and=20 rightful use of content on personal storage systems=20 Identification of specification parts and sub-parts:=20 ETSI-TS 102 822-1: Phase 1 Benchmark Features=20 ETSI-TS 102 822-2: System Description=20 ETSI-TS 102 822-3/1: Metadata Schemas=20 ETSI-TS 102 822-3/2: Metadata System Aspects (Fragmentation, indexing, encoding)=20 ETSI-TS 102 822-4: Content Referencing=20 ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - Service and transport=20 ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network - Service Discovery=20 ETSI TS 102 822-7: Bidirectional Metadata Delivery Protection=20 F3: Thanks, it is not Oomu but Luoma (sorry). Where will the work on the metadata model continue? =20 F5 I'll seek advice within TVA from the colleague who proposed this particular comment. =20 Regards, =20 Jean-Pierre =20 -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: mercredi, 28. janvier 2004 15:18 To: Evain Jean-Pierre; mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 Hi All =20 Here is my summary (paraphrasing) of the TVA input which relates (only) to document review and request for changes (with suggested text). =20 Jean-Pierre, can you validate this and check that the proposed changes are suitable? =20 General: =20 G1. Both documents are in great shape and cover TVA ideas, use cases & objectives very well =20 G2. TVA would like to ensure that their system fits into the IMG framework. TVA wish to work with us to develop and exchange ideas to do this - i.e. specify the protocols for delivery (service discovery/announcement) possibly in MMUSIC, as well as data models (which would be outside of MMUSIC charter) =20 =20 Requirements: =20 R1. Several TVA solutions meet several of the requirements =20 No changes needed =20 R2. on the content orientated use cases in IMG requirements: =20 =09 TVA Phase 1 definitely covers 4.2.2 TV and radio programme delivery, 4.2.3 media coverage of a live event and 4.2.4 distance learning. One could certainly add more use cases such as "Trailer booking and recording", "Use of segmented content for content updates, content replacement for e.g. targeted advertising, and virtual programmes", "Discovery and access to related programmes", etc. TVA Phase 2 will enrich these cases by the use of media packages encompassing more content formats than audio, video and related ancillary data. =20 Indeed there are many use cases beyond those given in this document. I propose that no changes are made, however if your experience is that certain TVA use cases have a strong impact (which is different from the existing IMG use cases) on metadata delivery (rather than the metadata itself), I would be keen to add just these. Are there such use cases? Does this sound OK? =20 R3. REQ DEL-3: The TVA data model has been designed to deliver data to large audiences =20 No changes needed =20 R4. REQ DEL-6: TV-Anytime queries are currently client initiated. The problem of time limited validity of pushed data remains to be addressed (TVA Phase 2) =20 No changes needed =20 R5. REQ DES-3: TVA would like to suggest a clarification of this requirements with the need expressed in the IMG framework document for an IMG minimum data model. =20 REQ DES-3: Whereas specific applications relying on IMGs will need to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all). =09 Thus, a transfer envelope format, that is uniform across all different application-specific IMG metadata formats, is needed. The payload of this transfer envelope would be some application-specific metadata. =09 -- change to -> =20 REQ DES-3: Whereas specific applications relying on IMGs will need to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all). =09 Thus, a transfer envelope format, that is uniform across all different application-specific IMG metadata formats, is needed. The payload of this transfer envelope would be some application-specific metadata, and the envelope would support the maintenance of the=20 application-specific metadata including the metadata relationships=20 determined by the data model(s) used. The transfer envelope would not need to be aware of the data model(s) in use. =09 R6. REQ DES-6: TV-Anytime should be one of the identifiable metadata formats. REQ DES-6: It SHALL be possible to deduce the metadata format from the transfer envelope. In a sense, all metadata formats will be identifiable. The solution would need to allow "a metadata application" to recognise a data field as "recognised from this list or not recognised". The delivery itself must be independent of metadata format. =20 No changes needed. =20 R7. As concerns the requirements security mentioned in Section 6, TVA only defines very generic scheme for establishing secure authentication channel between metadata sender and receiver (TS 102822-7).=20 =20 No changes needed. =20 =20 =09 Framework: =20 F1. The role of TVA needs clarification =A75.1, which maybe achieved by: =20 MPEG-7 [6] is a collection of XML-based description tools for general multimedia content including structured multimedia sessions. TV- Anytime Forum [7] provides descriptions based on MPEG-7 for TV specific program guides. These are likely to be limited to describe pictures, music and movies, thus it may be necessary to extend these descriptions in order to define a variety of documents, game programs, binary files, live events and so on. =09 -- change to -> =20 MPEG-7 [6] is a collection of XML-based description tools for general multimedia content including structured multimedia sessions.=20 =20 The TV-Anytime Forum [7] provides descriptions based on XML schema=20 for TV-specific program guides. TV-Anytime uses the MPEG-7 User=20 description profile to a limited extent (for user preferences and usage history) and also a TV-Anytime-specific data model for other=20 schema - which are optimised to describe broadcast schedules,=20 on-demand programme guides and programme events. =20 Also, it the following is noted although not necessary to paste into the framework: =20 The domain of application of TVA Phase 1 is unidirectional broadcast assisted by bi-directional access to ancillary metadata services. The TVA specification covers the description of broadcast and on-demand schedules or events. Furthermore, TVA has developed a "content referencing" scheme and "resolving" mechanisms that provide enhanced flexibility in the management of schedules and associated content. The type of Phase 1 content is primarily video, audio and ancillary services (Teletext, subtitles, design-for-all features...). TVA Phase 2 is currently addressing media packages that will encompass all sorts of data for different media delivery. It is therefore expected that TVA will cover a very wide range of applications and content and we would like to ensure that IMG allows to TVA data being accessed, transported and delivered using multicast or unicast delivery. =20 =09 =20 F2. A more specific referencing of TVA [7] is desirable, which may be achieved by: =20 [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002. =09 =20 =09 -- change to -> =20 [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,=20 select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102=20 822-2: System Description, V1.1.1, October 2003. =09 F3. The complete, delta and pointer data types are supported by TVA metadata =20 (Note, since the framework does not recommend that MMUSIC works on the data model, I will leave related responses to a later email - it seems that the information data model submission from Luoma and the TVA data models should work well together and transport of TVA metadata over IMG delivery protocols is a natural fit) =20 No changes needed =20 F4. TVA has not specified a unidirectional transport mechanism for TVA metadata so agrees with the proposal that an IP-based solution is developed (not SAP) =20 No changes needed =20 F5. TVA has developed some solutions for point-to-point unicast metadata delivery with HTTP, TLS, .... These will be interesting to scoping the needed work for point-to-point IMG delivery (what can be reused) and also subsequent point-to-point protocol work. =20 Open issue: we could describe and determine limitations and reuse of these in =A75. (Proposed text is welcome!) =20 =20 Next instalment in a few days! =20 Cheers, Rod. =20 ********************************************************************** 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 system manager. ********************************************************************** =20 ------_=_NextPart_001_01C3E756.E7CA540A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hello=20 Rod,
 
as=20 announced earlier...
 
General:  Only one question on the metadata model.  I ha= ve seen=20 a first draft from Oomu.  Isn't it within MMUSIC? If not, can you tell= me=20 more?
 
Requirements:
 
R2:=20 Trailer booking for instance is not based on the use of a schedule.  I= t=20 should be possible e.g. to book the recording of a piece of content from a= trailer proposed on the website.  Full content would be recorded= when=20 ready for streaming (e.g. Unicast following this client request).  The= same=20 schemes as for broadactsing should apply to multicast.  I'll try = to=20 provide you with some text next week.
 
R5:=20 seems to respond to the point at this stage
 
Framework:
 
F1:=20 okay
 
F2:=20
I=20 don't see why you shouldn't list them all.  Each of them is relevant o= t my=20 comments and to the IMG requirements and frameowkr at one moment or=20 another.  What woul be the problem with a more comprehensive list of= references?

Generic specification name: <= BR>ETSI-TS 102 822; Broadcast and On-line servic= es:=20 Search, select, and
rightful= use of=20 content on personal storage systems
Identification of specification parts and sub-parts:
<= FONT=20 face=3D"Courier New" size=3D2>ETSI-TS 102 822-1: Phase 1 Benchmark Features= =20
ETSI-TS 102 822-2: System Descripti= on=20
ETSI-TS 102 822-3/1: Metadata Schem= as=20
ETSI-TS 102 822-3/2: Metadata Syste= m Aspects=20 (Fragmentation, indexing, encoding)
ETSI-TS 102 822-4: Content Referencing
ETSI-TS 102 822-6/1: Metadata Services over a= Bidirectional Network - Service and transport
ETSI-TS 102 822-6/1: Metadata Services over a= Bidirectional Network - Service Discovery
ETSI TS 102 822-7: Bidirectional Metadata Delivery Protection=20

F3:
Thanks, it is not Oomu but Luoma (sorry).  = Where=20 will the work on the metadata model continue?
 
F5
I'll seek advice within TVA from the colleague w= ho=20 proposed this particular comment.
 
Regards,
 
Jean-Pierre
 
-----Original Message-----
From:=20 Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]
Sent: mercred= i,=20 28. janvier 2004 15:18
To: Evain Jean-Pierre;=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the frame= work=20 and requirements

Hi=20 All
 
Here=20 is my summary (paraphrasing) of the TVA input which relates (only) to doc= ument=20 review and request for changes (with suggested text).
 
Jean-Pierre, can you validate this and check that the proposed = changes=20 are suitable?
 
General:
 
G1. Both documents are in great shape and cover TVA ideas,= use=20 cases & objectives very well
 
G2. TVA would like to ensure that their system fits into t= he IMG=20 framework. TVA wish to work with us to develop and exchange ideas to do t= his -=20 i.e. specify the protocols for delivery (service discovery/announcement)= possibly in MMUSIC, as well as data models (which would be outside of MM= USIC=20 charter)
 
 
Requirements:
 
R1.=20 Several TVA solutions meet several of the=20 requirements
 
No changes needed
 
R2. on the content orientated use cases in IMG=20 requirements:
 
TVA Phase 1 definitely cov= ers 4.2.2=20 TV and radio programme delivery, 4.2.3 media coverage of a live event=20 and  4.2.4 distance learning. One could certainly add more use cases= such=20 as "Trailer booking and recording", "Use of segmented content for content= updates, content replacement for e.g. targeted advertising, and virtual= programmes", "Discovery and access to related programmes", etc. =20  TVA Phase 2 will en= rich=20 these cases by the use of media packages encompassing more content format= s=20 than audio, video and related ancillary=20 data.
 
Indeed there are many use cases beyond those given in this docu= ment. I=20 propose that no changes are made, however if your experience is that cert= ain=20 TVA use cases have a strong impact (which is different from the exis= ting=20 IMG use cases) on metadata delivery (rather than the metadata itself), I = would=20 be keen to add just these. Are there such use cases? Does this sound=20 OK?
 
R3. REQ DEL-3: The TVA data model has= been=20 designed to deliver data to large audiences <However, TVA does = not=20 currently specify IP delivery with massive scalability (such as=20 one-to-very-many multicast) and so this is an open requirement for TVA=20 too>
 
No=20 changes needed
 
R4. REQ DEL-6: TV-Anytime que= ries are=20 currently client initiated.  The problem of time limited validity of= pushed data remains to be addressed (TVA Phase 2) <and so=20 this is an open requirement for TVA=20 too>
 
No changes needed
 
R5.    REQ DES-3: Whereas specif= ic=20 applications relying on IMGs will need to
   select one or more specif= ic=20 application-specific metadata formats
   (standard, syntax, etc.),= the=20 IMG system MUST be independent of this
   (it may be aware, but it = will=20 operate in the same way for all).

   Thus, a transfer envelope= format, that is uniform across all
   different application-spe= cific=20 IMG metadata formats, is needed. The
   payload of this transfer= envelope would be some application-specific
  =20 metadata.
--=20 change to ->
 
    REQ= DES-3:=20 Whereas specific applications relying on IMGs will need to
   select one or more specif= ic=20 application-specific metadata formats
   (standard, syntax, etc.),= the=20 IMG system MUST be independent of this
   (it may be aware, but it = will=20 operate in the same way for all).

   Thus, a transfer envelope= format, that is uniform across all
   different application-spe= cific=20 IMG metadata formats, is needed. The
   payload of this transfer= envelope would be some application-specific
   metadata, and the envelop= e would=20 support the maintenance of the=20
   application-specific metadata including the= metadata relationships=20
   determined by the data model(s) used. T= he=20 transfer envelope would=20
   not need to be aware of the data model(s) in= use.
<= /SPAN>
R6.    REQ DES-6: It SHALL be po= ssible=20 to deduce the metadata format from
   the transfer=20 envelope.
In a sense, all metadata formats will be identifiab= le. The=20 solution would need to allow "a metadata application" to recognise a= data=20 field as "recognised from this list or not recognised". The delivery itse= lf=20 must be independent of metadata=20 format.
&= nbsp;
No changes=20 needed.
 
R7. As concerns the requirements securi= ty=20 mentioned in Section 6, TVA only defines very generic scheme for establis= hing=20 secure authentication channel between metadata sender and receiver (TS=20 102822-7).
 
No= changes=20 needed.
 
 
Framework:
 
F1.=20 The role of TVA needs clarification =A75.1, which maybe achieved=20 by:
   MPEG-7 [6] is a collectio= n of=20 XML-based description tools for general
   multimedia content includ= ing=20 structured multimedia sessions.=20
  =20
   The TV-Anytime Forum [7] provides descr= iptions=20 based   =20 for TV-specific program guides. TV-Anytime uses=20 the    description profile to a limited extent= (for=20 user preferences and
   usage=20 history) aTV-Anytime-specific data model for other=20
   schema - which are optimised to describ= e=20 broadcast schedules,
   on-demand programme guides and programm= e=20 events.
<= SPAN=20 lang=3DEN-GB=20 style=3D"mso-fareast-font-family: 'MS Mincho'"> 
<= SPAN=20 lang=3DEN-GB style=3D"mso-fareast-font-family: 'MS Mincho'">Also, it the = following=20 is noted although not necessary to paste into the=20 framework:
<= SPAN=20 lang=3DEN-GB=20 style=3D"mso-fareast-font-family: 'MS Mincho'"> 
The domain of= application of TVA Phase 1 is unidirectional broadcast assisted by=20 bi-directional access to ancillary metadata services.  The TVA=20 specification covers the description of broadcast and on-demand schedules= or=20 events.  Furthermore, TVA has developed a "content referencing" sche= me=20 and "resolving" mechanisms that provide enhanced flexibility in the manag= ement=20 of schedules and associated content.  The type of Phase 1 content is= primarily video, audio and ancillary services (Teletext, subtitles,=20 design-for-all features...).  TVA Phase 2 is currently addressing me= dia=20 packages that will encompass all sorts of data for different media=20 delivery.  It is therefore expected that TVA will cover a very wide = range=20 of applications and content and we would like to ensure that IMG allows t= o TVA=20 data being accessed, transported and delivered using multicast or unicast= delivery.
<= SPAN=20 lang=3DEN-GB=20 style=3D"mso-fareast-font-family: 'MS Mincho'"> 
=
 = ;
F2. A more specific= referencing of TVA [7] is desirable, which may be achieved=20 by:
 = ;
   [7] T.-A. Forum, "Metadata=20 specification S-3," TV-Anytime Forum
   Specification SP003v1.2 P= art A,=20 TV, TV-Anytime Forum, June 2002.
<= FONT=20 face=3DArial><= /SPAN> 
-- c= hange to=20 ->
=  
   [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,=20
   select, and rightful use of content on personal sto= rage=20 systems
   ("TV-Anytime Phase 1"); Part 2: System=20 description," ETSI-TS 102=20
   822-2: System=20 Description, V1.1.1, October=20 2003.

F3= . The=20 complete, delta and pointer data types are supported by TVA=20 metadata
 
(Note, since the framework does not recommend that MMUSIC works= on the=20 data model, I will leave related responses to a later email - it seems th= at=20 the information data model submission from Luoma and the TVA data models= should work well together and transport of TVA metadata over IMG deliver= y=20 protocols is a natural fit)
 
No=20 changes needed
 
F4.=20 TVA has not specified a unidirectional transport mechanism for TVA metada= ta so=20 agrees with the proposal that an IP-based solution is developed (not=20 SAP)
 
No=20 changes needed
 
F5.=20 TVA has developed some solutions for point-to-point unicast metadata deli= very=20 with HTTP, TLS, .... These will be interesting to scoping the needed work= for=20 point-to-point IMG delivery (what can be reused) and also subsequent=20 point-to-point protocol work.
 
Open issue: we could describe and = determine=20 limitations and reuse of these in =A75. (Proposed text is=20 welcome!)
 
 
Next instalment in a few=20 days!
 
Cheers, Rod.
 


**********************************************************************
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 system manager.

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

 ------_=_NextPart_001_01C3E756.E7CA540A-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic