From exim@www1.ietf.org Mon Feb 2 03:01:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23968 for ; Mon, 2 Feb 2004 03:01:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnZ1I-0008SB-Rx for mmusic-archive@odin.ietf.org; Mon, 02 Feb 2004 03:01:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1281ObC032495 for mmusic-archive@odin.ietf.org; Mon, 2 Feb 2004 03:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnZ1I-0008S2-LN for mmusic-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 03:01:24 -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 DAA23959 for ; Mon, 2 Feb 2004 03:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnZ1E-0000Qh-00 for mmusic-web-archive@ietf.org; Mon, 02 Feb 2004 03:01:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnZ0I-0000MW-00 for mmusic-web-archive@ietf.org; Mon, 02 Feb 2004 03:00:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnYzy-0000I7-00 for mmusic-web-archive@ietf.org; Mon, 02 Feb 2004 03:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYzx-0008Ht-JO; Mon, 02 Feb 2004 03:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYzJ-0008DT-0a for mmusic@optimus.ietf.org; Mon, 02 Feb 2004 02:59: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 CAA23915 for ; Mon, 2 Feb 2004 02:59:17 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYzF-0000H6-00 for mmusic@ietf.org; Mon, 02 Feb 2004 02:59:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYyJ-0000Ch-00 for mmusic@ietf.org; Mon, 02 Feb 2004 02:58:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AnYxO-00007Y-00 for mmusic@ietf.org; Mon, 02 Feb 2004 02:57:23 -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 i127vN207172 for ; Mon, 2 Feb 2004 09:57:23 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 2 Feb 2004 09:57:22 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 09:57:19 +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: Mon, 2 Feb 2004 09:57:20 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797699@esebe019.ntc.nokia.com> Thread-Topic: direction attribute in comedia Thread-Index: AcPpYi50u8aFN/WSSn6TH5xoZyOGrg== To: X-OriginalArrivalTime: 02 Feb 2004 07:57:20.0003 (UTC) FILETIME=[2EEFA530:01C3E962] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] direction attribute in comedia 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 The BNF is a=3D"direction" ":" direction-spec=20 direction-spec =3D "both" / "active" / "passive"=20 Yet, some of the examples show: a=3Ddirection:active IN IP4 Is something wrong with the example of with the BNF? Regards, Hisham _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 3 15:53:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00787 for ; Tue, 3 Feb 2004 15:53:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7XF-0000th-KB for mmusic-archive@odin.ietf.org; Tue, 03 Feb 2004 15:52:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Kqff8003443 for mmusic-archive@odin.ietf.org; Tue, 3 Feb 2004 15:52:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7XF-0000tS-Fo for mmusic-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:52:41 -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 PAA00740 for ; Tue, 3 Feb 2004 15:52:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7XE-00026y-00 for mmusic-web-archive@ietf.org; Tue, 03 Feb 2004 15:52:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7WK-00020G-00 for mmusic-web-archive@ietf.org; Tue, 03 Feb 2004 15:51:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Vf-0001uL-00 for mmusic-web-archive@ietf.org; Tue, 03 Feb 2004 15:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Vf-0000V3-8L; Tue, 03 Feb 2004 15:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Vc-0000TB-QR for mmusic@optimus.ietf.org; Tue, 03 Feb 2004 15:51:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00517; Tue, 3 Feb 2004 15:50:58 -0500 (EST) Message-Id: <200402032050.PAA00517@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Feb 2004 15:50:58 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-10.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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) Author(s) : J. Arkko Filename : draft-ietf-mmusic-kmgmt-ext-10.txt Pages : 25 Date : 2004-2-3 This document defines general extensions for SDP and RTSP to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the MIKEY key management protocol is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-3150144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3150144.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 3 16:33:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05475 for ; Tue, 3 Feb 2004 16:33: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 1Ao8Ah-0003Bq-9R for mmusic-archive@odin.ietf.org; Tue, 03 Feb 2004 16:33:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13LXRGv012256 for mmusic-archive@odin.ietf.org; Tue, 3 Feb 2004 16:33:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8Ah-0003Bb-3x for mmusic-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 16:33: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 QAA05419 for ; Tue, 3 Feb 2004 16:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8Af-0001Bm-00 for mmusic-web-archive@ietf.org; Tue, 03 Feb 2004 16:33:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao89a-0000x6-00 for mmusic-web-archive@ietf.org; Tue, 03 Feb 2004 16:32:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao88N-0000hN-00 for mmusic-web-archive@ietf.org; Tue, 03 Feb 2004 16: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 1Ao88M-0002zH-Fk; Tue, 03 Feb 2004 16: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 1Ao88G-0002yY-9B for mmusic@optimus.ietf.org; Tue, 03 Feb 2004 16:30:56 -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 QAA04952 for ; Tue, 3 Feb 2004 16:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao88E-0000fk-00 for mmusic@ietf.org; Tue, 03 Feb 2004 16:30:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao86p-0000K6-00 for mmusic@ietf.org; Tue, 03 Feb 2004 16:29:29 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1Ao85Y-00003s-00 for mmusic@ietf.org; Tue, 03 Feb 2004 16:28:08 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 03 Feb 2004 13:27:58 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Tue, 03 Feb 2004 13:26:24 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=projects.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Ao0Gj-0000Wj-Kf for robla@real.com; Tue, 03 Feb 2004 05:07:09 -0800 Date: Tue, 03 Feb 2004 05:06:05 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #113 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-795314 ] Caching of OPTIONS request (SourceForge.net) 2. [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. (SourceForge.net) 3. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net) 4. [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method (SourceForge.net) 5. [ rtspspec-Bugs-500906 ] Client liveness criteria vague (SourceForge.net) 6. [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234 (SourceForge.net) 7. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net) 8. [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 (SourceForge.net) 9. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net) 10. [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 03:50:51 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-795314 ] Caching of OPTIONS request Bugs item #795314, was opened at 2003-08-26 14:27 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795314&group_id=23194 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Caching of OPTIONS request Initial Comment: Geetha Srikantan thought of the question if OPTIONS request are cachable, and if, how to determine the expiration of such cached command. My answer Maybe, it is actually a problem of what OPTIONS is used for. As long it is only used for determing server capability it is not a problem. However if it is used to maintain session liveness, i.e. session ID present, no. Also depending on the URI and the possibilities to cache ma y vary. Needs further consideration. This is a tough problem. I don't think there are. The Expires header is an entity header, but the text in RFC 2616 seems to mean the whole request. So this is also something that needs consideration. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 12:50 Message: Logged In: YES user_id=302620 If one looks at the caching chapter of the RTSP specification, it is rather clear that only DESCRIBE responses can be cached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795314&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 03:54:09 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. Bugs item #840304, was opened at 2003-11-11 22:54 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=840304&group_id=23194 Category: Editorial >Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: CSEQ is direction dependent in numberspaces. Initial Comment: IETF 58 off-line discussion resulted in one point to ensure is edited in:It needs to be clarified that CSeq sequence number spaces are direction dependent. The C->S Requests uses a different space then S->C Requests. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 12:54 Message: Logged In: YES user_id=302620 A clarification has been made and is checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=840304&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 04:11:42 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter Bugs item #850267, was opened at 2003-11-27 15:38 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 Category: Editorial >Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Gather all ABNF in syntax chapter Initial Comment: - All ABNF needs to be gathered in the syntax chapter. - Ensure that it is in 2234 form - When necessary put references into text when the ABNF gets moved. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:11 Message: Logged In: YES user_id=302620 The changes are performed and checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 04:13:52 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method Bugs item #492546, was opened at 2001-12-13 18:44 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=492546&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Magnus Westerlund (magwes) Summary: Shouldn't close on unsupported method Initial Comment: When a server (or client) receives an unsupported method, and the request is well-formed (complies with BNF for Request, and contains CSeq), we should mandate that a server MUST not close down an existing playback session. This is an extensibility issue. If, during playback, the client requests a certain method that the server doesn't support, and we allow session shutdown, then we've painted ourselves in a corner where we can't comfortably extend the protocol. The client may determine that support for a method is required, at which point, the client may disconnect the session. However, the client should be given the option to account for the error and continue playback. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:13 Message: Logged In: YES user_id=302620 No comments received on text. Closing issue. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 21:05 Message: Logged In: YES user_id=302620 Some text on this has been edited in to the specification in the chapter regarding TCP connections. There is also a clarification regarding the use of the "Connetion" header and the option "close". Please review these changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=492546&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 04:20:41 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-500906 ] Client liveness criteria vague Bugs item #500906, was opened at 2002-01-08 18:14 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Sean Sheedy (seansh) Assigned to: Magnus Westerlund (magwes) Summary: Client liveness criteria vague Initial Comment: The current standard is vague about what constitutes a client "liveness" indication sufficient to prevent the media server from freeing a client's session. It also does not address under what circumstances a media server may close an inactive persistent control connection from a client. These areas should be more explicitly specified so that clients can reliably maintain their sessions with minimum liveness detection overhead. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:37 Message: Logged In: YES user_id=302620 As no comments on this bug has been raised in a year it will be closed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 14:39 Message: Logged In: YES user_id=302620 The criteria for closing connections has been clarified in the chapter connections. The liveness signaling has also been clarified in the session header chapter. Changes are checked in. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-01-14 11:13 Message: Logged In: YES user_id=302620 Primary source of livness information is RTCP, which should be clarified. Secondly the new method PING could be used, see bug report #477400. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 04:22:35 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234 Bugs item #501599, was opened at 2002-01-10 03:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=501599&group_id=23194 Category: General Group: Fix for DS - Large task >Status: Closed Resolution: None Priority: 5 Submitted By: Henning Schulzrinne (hgschulz) Assigned to: Magnus Westerlund (magwes) Summary: Collect BNF at end, convert to 2234 Initial Comment: For the SIP spec revision, we collected all BNF in one place. This makes the spec somewhat shorter and easier to read. Also, we need to convert BNF to 2234 format to pass IESG. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:22 Message: Logged In: YES user_id=302620 This bug has been taken care of and the editorial changes are tracked by bug 850267. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-25 13:38 Message: Logged In: YES user_id=302620 A question is if the syntax chapter is the only place where there should be syntax. This mean deleting it everywhere else. Is this a good thing? ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 11:22 Message: Logged In: YES user_id=302620 This is being done, closing bug 477429 and use this instead until work is completed. The BNF is mostly converted. Comments please if non changed syntax is found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=501599&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 04:23:07 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter Bugs item #850267, was opened at 2003-11-27 15:38 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 Category: Editorial Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Gather all ABNF in syntax chapter Initial Comment: - All ABNF needs to be gathered in the syntax chapter. - Ensure that it is in 2234 form - When necessary put references into text when the ABNF gets moved. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:23 Message: Logged In: YES user_id=302620 However the ABNF verifier needs to be run over the syntax. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:11 Message: Logged In: YES user_id=302620 The changes are performed and checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 04:58:20 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 Bugs item #831553, was opened at 2003-10-28 06:20 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 Category: Editorial >Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Nobody/Anonymous (nobody) Summary: Error in rfc2326bis-04 example 15.4 Initial Comment: The last two messages in this example is: C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596 M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596 Range:npt=now- But I wonder how the receiver could perform the sync between RTP timestamp and NPT, without a RTP-Info header in the PLAY response? I wouldn't like to see such RTSP conversation in our applicatoin. A real implementation would likely to conduct the PLAY request/response including RTP-Info, for example: C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596 Range: now- M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596 Range:npt=1000- RTP-Info: url=rtsp://live.example.com/concert/audio; seq=1473; rtptime=80000 ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:58 Message: Logged In: YES user_id=302620 I agree, however as there are only a single media, there is nothing except NPT to synchronize against. As it is a live session no time scale is given, by the now- answer. Thus I think it in this example could actually be okay to exclude the RTP-Info. However I have added the proposed text to the example. If anyone has comments on this resolution please respond. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:00:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included? Bugs item #850256, was opened at 2003-11-27 15:06 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: When must RTP-Info be included? Initial Comment: At the RTSP discussion at IETF 58 there where some discussion in regards if RTP-Info really can be presented in all Play Responses when the media streams are RTP. The argument was Live media. The current specification (05) requires this. Are there really a reason for changing this? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:00 Message: Logged In: YES user_id=302620 The text has been changed to have RTP-Info as SHOULD be included for RTP transported streams. Further motivation why it is important has been given. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-11-28 08:59 Message: Logged In: YES user_id=302620 The argument why a server could not present a RTP-Info header in a PLAY response was due to that the distribution server might not be aware of inter media synchronization of the media streams it forwards. If that is the case there exist the possibility to perform intermedia synchronization with RTCP. In regards to Jae-Whan's comments: Regarding "1) The beginning of the live service" the first comment is that there is no way of knowing that a session is live. This we have addressed through the definition that any open range in the SDP a=range attribute shall be considered Live. "When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains." I don't see how this relates to the intermedia synchronization problem. A client can't rely on that all media streams first packet will represent the same point in time and would therefore result in bad synchronization between the media. In regards to 2: In a live session if you are continuing after a couple of minutes there is no reason for removing the timestamp gap. In a live media session the media will have advanced during the paused time, therefore there does not seem to be any reason to synchronize the media prior to the pause to the one after the pause. Therefore the player should in a live case flush the buffers when it resumes play after a pause. Thus the lack of RTP-Info in this case would have no effect. As the RTP timestamp continues correctly during the paused time the intermedia synchronization established prior to pausing will still be valid I think the main problem of not always requiring RTP-Info is the intermedia synchronization. RTCP can be used, however the time until RTCP has been received for all media may be on order of seconds, thus possibly resulting in that playback has to be commeneced without synchronization. ---------------------------------------------------------------------- Comment By: Jaehwan, Kim (kjh1905m) Date: 2003-11-28 07:18 Message: Logged In: YES user_id=365760 IMHO, it is enough that we focus on 2 cases: 1) the beginning of the live service 2) live PAUSE/Resume because we don't believe live streaming session supports random access. 1) The beginning of the live service At this moment, there is no way for a player to see if the session is live or not. But if there is no RTP-Info, the player can start its session by the following way: When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains. 2) Live PAUSE/Resume Currently, we use monotonic rtptimestamp increament for random access. However, if a player requests PAUSE and Resume after a couple of minute, then rtptimestamp has to have the time gap. Without RTP-Info, how can the player remove the rtptimestamp gap? How can it continue the live session without any timegap? If RTSP Range header field also doesn't exist, a player can do that. From the begginning, the player should remember the first rtptimestamp and after the resume, we can just subtract the first from the lastest rtptimestamp. And then, we can calculate the real presentation time from it, comparing with the real PAUSE time gap. But this behavior of a player is different from general on- demand service having RTP-Info. Therefore, we need to chek our if the player can do that the both cases, RTP-Info and no for live. It means a general VOD player might not continue to work after live PAUSE. Feel free to give me an advise regarding this matter if I am wrong. Thank you! Jae-Hwan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:05:36 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts Bugs item #506684, was opened at 2002-01-21 23:46 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Magnus Westerlund (magwes) Summary: Allow Rtp-Info header in more contexts Initial Comment: Currently, the RFC states that the Rtp-Info header is required in the PLAY response. But it is not clear whether or not the Rtp-Info is allowed in other contexts. I think of three other cases where it might be useful: 1. In the RECORD request. If a client is sending data to the server, the client SHOULD send the Rtp-Info header to the server, so that the server can know the initial RTP sequence number and RTP timestamp. 2. In the SETUP response. If the server is already playing, and the client sends a SETUP command to select a stream that previously was not selected, I believe the server will start sending data for this stream immediately. (Check the RFC, I am not sure it clearly states whether the newly selected stream will be streamed immediately or not.) In this case, it would be useful for the client to be able to recieve an Rtp-Info header as a part of the SETUP response. But this has to be seen as an optional optimization -- the client can always send a second PLAY command, and the Rtp-Info header will then be available in the PLAY response. 3. In the ANNOUNCE command. If the server is already playing, and something related to the SDP description suddenly changes, the server can send a new SDP to the client using the ANNOUNCE command. It might be necessary to include a new Rtp-Info header in this case. A similar situation happens when the server is reconding something, and the client sends an ANNOUNCE command to the server. Again, this is probably just an optional optimization, because the client can always send a new PLAY command and obtain the Rtp-Info header again. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:05 Message: Logged In: YES user_id=302620 The usage of RTP-Info is now furhter clarified in relation to PLAY and SETUP. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-25 13:44 Message: Logged In: YES user_id=302620 As Record and Announce has been removed from the specification these questions are not longer relevant to the core specification. However any future definition needs to consider them. RTP-Info for SETUP is currently used in two cases: 1. When in play state adding a stream to the session 2. When in play state changing the transport parameters ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:35 Message: Logged In: YES user_id=302620 I agree that RTP-Info i SETUP while be necessary for the optional functionality of SETUP and TEARDOWN while playing. For RECORD this should be part of the work in defining how it should really work. For ANNOUNCE we need to further discuss this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 4 04:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27302 for ; Wed, 4 Feb 2004 04:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJEV-0005sD-6N for mmusic-archive@odin.ietf.org; Wed, 04 Feb 2004 04:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149M6HH022569 for mmusic-archive@odin.ietf.org; Wed, 4 Feb 2004 04:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJET-0005rs-Uc for mmusic-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:22: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 EAA27220 for ; Wed, 4 Feb 2004 04:22:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJEQ-0002Z8-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 04:22:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJDW-0002TW-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 04:21:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJCa-0002Nv-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 04:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJCW-0005WC-TO; Wed, 04 Feb 2004 04:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJBZ-0005U1-CP for mmusic@optimus.ietf.org; Wed, 04 Feb 2004 04:19: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 EAA27161 for ; Wed, 4 Feb 2004 04:19:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJBW-0002Hg-00 for mmusic@ietf.org; Wed, 04 Feb 2004 04:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJAd-0002Cg-00 for mmusic@ietf.org; Wed, 04 Feb 2004 04:18:10 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AoJA3-000271-00 for mmusic@ietf.org; Wed, 04 Feb 2004 04:17:31 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 04 Feb 2004 01:17:22 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Wed, 04 Feb 2004 01:15:07 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=projects.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Ao1ih-0004Pa-KQ for robla@real.com; Tue, 03 Feb 2004 06:40:07 -0800 Date: Tue, 03 Feb 2004 06:39:01 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #114 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-507347 ] Removal of destination redirection (SourceForge.net) 2. [ rtspspec-Bugs-507347 ] Removal of destination redirection (SourceForge.net) 3. [ rtspspec-Bugs-889699 ] Change requirement level on auth for media destination (SourceForge.net) 4. [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive (SourceForge.net) 5. [ rtspspec-Bugs-513737 ] Unclarities when doing resetup (SourceForge.net) 6. [ rtspspec-Bugs-513787 ] Allow capability negotiations (SourceForge.net) 7. [ rtspspec-Bugs-539001 ] Transport header should override m= (SourceForge.net) 8. [ rtspspec-Bugs-556061 ] When can REDIRECT be received? (SourceForge.net) 9. [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready (SourceForge.net) 10. [ rtspspec-Bugs-477403 ] Missing session header in response (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:10:05 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507347 ] Removal of destination redirection Bugs item #507347, was opened at 2002-01-23 05:39 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507347&group_id=23194 Category: General >Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: Removal of destination redirection Initial Comment: Discrepency between RFC 2326 and initial checkin: 12.39 Transport: In CVS, the following phrase has been removed from the specifation: "A server SHOULD not allow a client to direct media streams to an address that differs from the address commands are coming from." I don't necessarily oppose this because there are totally legitimate reasons for sending to a different address, but we should probably come up with alternate wording that makes it clear. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:10 Message: Logged In: YES user_id=302620 The section contains today a more elaborate security clarification. However the language must most likely be befeed up from SHOULD authenticate to SHALL authenticate to be able to pass IESG. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507347&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:11:32 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507347 ] Removal of destination redirection Bugs item #507347, was opened at 2002-01-23 05:39 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507347&group_id=23194 Category: General >Group: Resolved - Added to text >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: Removal of destination redirection Initial Comment: Discrepency between RFC 2326 and initial checkin: 12.39 Transport: In CVS, the following phrase has been removed from the specifation: "A server SHOULD not allow a client to direct media streams to an address that differs from the address commands are coming from." I don't necessarily oppose this because there are totally legitimate reasons for sending to a different address, but we should probably come up with alternate wording that makes it clear. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:11 Message: Logged In: YES user_id=302620 A new bug will be logged regarding the requirments level of the text. Destination redirection will not be removed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:10 Message: Logged In: YES user_id=302620 The section contains today a more elaborate security clarification. However the language must most likely be befeed up from SHOULD authenticate to SHALL authenticate to be able to pass IESG. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507347&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:14:08 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-889699 ] Change requirement level on auth for media destination Bugs item #889699, was opened at 2004-02-03 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=889699&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Change requirement level on auth for media destination Initial Comment: The current text on the transport headers destination and dest_addr header is that they SHOULD use authentication to verify that the receiver is allowed to redirect to this target. I think that to be able to get this past the IESG and for achieving good security the SHOULD needs to be a SHALL. Opinions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=889699&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:15:22 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive Bugs item #507884, was opened at 2002-01-24 09:31 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507884&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Should sequnce numbers be consecutive Initial Comment: To make it possible to detect losses of request when transported over UDP, the sequnce number should be consecutive. In that way the server will know that it should not process a request until the missing ones before is received. Are there any issues with such a solution? Does the first sequence number needs to be specified so losses of the first message(s) is known? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:15 Message: Logged In: YES user_id=302620 Closing this bug as no comment has been given. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 17:04 Message: Logged In: YES user_id=302620 The text has been updated, with explict text about sequence number may start at any value, but is recommended to start at 0. The connection chapter has also be restructered. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:53 Message: Logged In: YES user_id=302620 The specification is updated to require increments with one for each new message. However the initial value is still free to pick. The effect of losing the first packet is that request can be performed in another order than intended. However if you loose a not state changing event (Options, DESCRIBE) it will not really matter. The first setup can't be pipelined unless it is done with another SETUP request for two non-aggregate session. A client is not allowed to issue a PLAY until the SETUP request response is back. So I don't see how it can matter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507884&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:16:18 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513737 ] Unclarities when doing resetup Bugs item #513737, was opened at 2002-02-06 14:26 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Unclarities when doing resetup Initial Comment: Setup is used to change transport parameters of a already setuped stream. What happends if the new SETUP contains errors? Except of responding with an error message, what happends to the session and transport state? It should be clarified in the specification. Which of the following alternatives are correct? 1. Keep the old setting and states as if the second SETUP never happend. 2. Invalidate the media in the session until a correct setup has happend. To me case 1 seems more natural but will require more from the server. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:16 Message: Logged In: YES user_id=302620 This has been fixed a long time ago, closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-15 10:09 Message: Logged In: YES user_id=302620 A clarified third paragraph in the SETUP section (11.3) has been added. If a setup request fails the previous state shall be left as it was, i.e. proposal 1 in the initial declartion of this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:17:12 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513787 ] Allow capability negotiations Bugs item #513787, was opened at 2002-02-06 16:32 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513787&group_id=23194 >Category: Feature Request Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Allow capability negotiations Initial Comment: Today RTSP lacks the possibility to do any kind of capability/parameter negotiation or at least choices regarding media parameters. I would like to see possibilities for this in the future. My initial idea is to make a offer/answer model. This will require expanding the SETUP request to carry a message body. A message exchange could work like this. 1. C->S: Describe 2. S->C: Response with media description, SDP or in the future SDP-NG. This description contains multiple alternatives or in the case SDP-NG a complete description of the choices regarding media that the client can do. 3. Client selects its desired configuration. 4. C->S: Setup with message body with choosen configuration in SDP/SDP-NG. 5. S->C: Server either accepts or refuses the setup with the given configuration. Refusing should happend very rarely as server should not offer anything it can provide. Such solution should try to keep the difference between media parameters and transport parameters. Transport parameters should be keept in the transport header to simplify processing in proxies and firewalls. Conclusion: only media related parameters should be negotiated with the offer/answer mechanism. To my knowledge the changes required for this is to allow a message body in SETUP requests. Also rules how and to what it may be used must be specified. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:17 Message: Logged In: YES user_id=302620 This is in fact a feature request. Changing category for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513787&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:21:43 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-539001 ] Transport header should override m= Bugs item #539001, was opened at 2002-04-04 01:32 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Magnus Westerlund (magwes) Summary: Transport header should override m= Initial Comment: Section C.1.7 ("Connection Information") states the following: "for on-demand unicast streams and some multicast streams, the destination is specified by the client via the SETUP request". The rest of this section mainly refers to the "c=" line in SDP, but it's not clear that the SETUP Transport header also overrides the port given in the m= line. Clarification of this is needed. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:21 Message: Logged In: YES user_id=302620 No comments given, closing this. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 14:20 Message: Logged In: YES user_id=302620 This has been clarified in the SDP appendix. There has been alignment between what is possible between ports and addresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 05:46:03 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-556061 ] When can REDIRECT be received? Bugs item #556061, was opened at 2002-05-14 20:33 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556061&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: When can REDIRECT be received? Initial Comment: From mmusic alias: ---- Date: Tue, 14 May 2002 17:55:20 +0200 From: "olivier.randriamanana.extern46@philips.com" To: "mmusic@ietf.org" Subject: [MMUSIC] RTSP REDIRECT (1) , when can it be received ?? Hi, I have problem understanding *when* a user agent can receive a REDIRECT request. When reading RFC 2326, I understood receipt/transmission of a REDIRECT request could happen at virtually anytime. As such, the following scenario could happen: C -> S: DESCRIBE rtsp://server.com/movies/BeautifulMind.mp4 CSeq: 1400 Accept: application/sdp S -> C: REDIRECT rtsp://server.com/movies/BeautifulMind.mp4 CSeq: 1401 Location: rtsp://server.com/mpaa/pg13/BeautifulMind.mp4 S -> C: RTSP/1.0 404 Not Found CSeq: 1400 Connection: Close However one can also notify redirection in such a context by using a 3xx response, right ? C -> S: DESCRIBE rtsp://server.com/movies/BeautifulMind.mp4 CSeq: 1400 Accept: application/sdp S -> C: RTSP/1.0 301 Moved CSeq: 1400 Location: rtsp://server.com/mpaa/pg13/BeautifulMind.mp4 Connection: Close However when reading the RTSP state machine spec (version 0.5) contributed by Mr Westerlund, it seems like a REDIRECT can only happen (or at least should be used) when a presentation is being played or is paused (at least all streams are SETUP). Therefore using the state machine REDIRECT semantics, scenarii like the first one exposed above are erroneous. So should REDIRECT be sent/received when an RTSP session is being played/paused only, or can it be sent/received any time ?? Thanks for your time and response, Olivier ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:46 Message: Logged In: YES user_id=302620 It has been further clarified when redirect and 3rr codes can be sent and received. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:14 Message: Logged In: YES user_id=302620 The resolution I see is that REDIRECT shall only be sent when a client has an established session. The use of 3xx may happen at any time. Such a solution is written up and available from CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556061&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:36:10 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready Bugs item #556295, was opened at 2002-05-15 14:12 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556295&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Magnus Westerlund (magwes) Summary: Client issues PAUSE while server ready Initial Comment: If a client issues a PAUSE and the server acknowledges and enters ready state, what is proper server response if the player issues another PAUSE? There appear to be two possible correct behaviors: 1. server responds with OK because it does not change state and does no harm. 2. server responds with error 455 because PAUSE does not make sense in this state. Both interpretations have been implemented. The latter appears to be more correct, but a client that assumes the first may misbehave if the server implements the second. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:36 Message: Logged In: YES user_id=302620 No comments closing bug ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 13:51 Message: Logged In: YES user_id=302620 This clarification of behavior has now beend added to the text and will be published in v5. The text is in the state machine and pause method section. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-14 17:17 Message: Logged In: YES user_id=302620 The working assumption is that a 200 OK should be sent even if already in ready state. Also the pause point needs to be included in the response. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:16 Message: Logged In: YES user_id=302620 This should be clarified. Input from implementors wanted. The resolution should be made evident in the state machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556295&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:38:20 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477403 ] Missing session header in response Bugs item #477403, was opened at 2001-11-02 08:20 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Missing session header in response Initial Comment: Page 38 first example: Example missing session header in response. Should not the client respond with what session id the respond relates to, as the request contained one. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:38 Message: Logged In: YES user_id=302620 Issue resolved, no comments given. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-24 10:19 Message: Logged In: YES user_id=302620 The text in draft 05 has been updated in regards to the session ID, see session header and SETUP that has been totally restructed. Is this acceptable in regards to the previous issue questions? ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-04 09:03 Message: Logged In: YES user_id=302620 There has been some text changes on this section in the 04 draft. I don't think the changed text actually covers the case completly in regards to the old text. It is also a tighter definition. The new definition does not allow one to create session without a session id as RFC2326 does. This functionality to use some other method, like dynamic URLs, seems unspecified. Therefore I propsoe that it is dissallowed. Secondly the comments about when one MUST send the session identifier: - Robla is correct that the text does not require a server in the response to include a session header. - In response to kjh1905m's comment, this MUST relates to the client. IF you read carful it says that the client MUST use the session identifier, if defined by the server, in any request that is in relation to the created session. Actions: - Question: Is there any need to not require the server to generate a session ID? The use of any other method to bind sessions is not specified. In my opinion any client being faced with this would not understand it, and if it had the intention of doing aggregate control, it will not know how. - The text in the 04 draft version should propably be improved. I think that mentioning cases where the session header must or must not be included in the response will improve understanding. An example of this is the TEARDOWN, where the presence of a session id header indicates that the session still exist. I would also guess that having at as default behavior to return the session ID in responses is beneficial, but not required or something a client or proxy cna depend on. ---------------------------------------------------------------------- Comment By: Jaehwan, Kim (kjh1905m) Date: 2003-09-04 07:42 Message: Logged In: YES user_id=365760 Then, what is the meaning of 'MUST'? --------------- 12.37 Session This request and response header field identifies an RTSP session started by the media server in a SETUP response and concluded by TEARDOWN on the presentation URL. The session identifier is chosen by the media server (see Section 3.4). Once a client receives a Session identifier, it MUST return it for any request related to that session. A server does not have to set up a session identifier if it has other means of identifying a session, such as dynamically generated URLs. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-29 00:23 Message: Logged In: YES user_id=3796 I don't think this is a mistake. The server isn't required to send back a session identifier if the client sends one. It's only required to generate one if the client *doesn't* specify one....and only then in the SETUP message. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 18:51 Message: Logged In: YES user_id=3796 Whoops...will fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 4 06:23:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00861 for ; Wed, 4 Feb 2004 06:23: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 1AoL7a-0004IM-Og for mmusic-archive@odin.ietf.org; Wed, 04 Feb 2004 06:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14BN6ZR016506 for mmusic-archive@odin.ietf.org; Wed, 4 Feb 2004 06:23:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoL7a-0004I9-K5 for mmusic-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 06:23: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 GAA00827 for ; Wed, 4 Feb 2004 06:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoL7W-0006oa-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 06:23:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoL6Y-0006iE-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 06:22:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoL5a-0006cf-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 06:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoL5b-0004BJ-61; Wed, 04 Feb 2004 06:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoL4k-000496-Nx for mmusic@optimus.ietf.org; Wed, 04 Feb 2004 06:20:11 -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 GAA00765 for ; Wed, 4 Feb 2004 06:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoL4g-0006Ww-00 for mmusic@ietf.org; Wed, 04 Feb 2004 06:20:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoL3s-0006RG-00 for mmusic@ietf.org; Wed, 04 Feb 2004 06:19:16 -0500 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]) by ietf-mx with esmtp (Exim 4.12) id 1AoL2z-0006EO-00 for mmusic@ietf.org; Wed, 04 Feb 2004 06:18:21 -0500 Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail7.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i14BHk1q015255 for ; Wed, 4 Feb 2004 20:17:46 +0900 (envelope-from nom@flab.fujitsu.co.jp) Received: from s4.gw.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i14BHj8p030463 for ; Wed, 4 Feb 2004 20:17:45 +0900 (envelope-from nom@flab.fujitsu.co.jp) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s4.gw.fujitsu.co.jp (8.12.10) id i14BHjd6002090 for ; Wed, 4 Feb 2004 20:17:45 +0900 (envelope-from nom@flab.fujitsu.co.jp) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id UAA03297; Wed, 4 Feb 2004 20:17:45 +0900 (JST) Received: from pelican.png.flab.fujitsu.co.jp ([10.25.165.3]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004020420174418927 ; Wed, 04 Feb 2004 20:17:44 +0900 Received: from localhost by pelican.png.flab.fujitsu.co.jp (8.11.7+Sun/3.7W-20030624) id i14BHim13403; Wed, 4 Feb 2004 20:17:44 +0900 (JST) Date: Wed, 04 Feb 2004 20:17:44 +0900 (JST) Message-Id: <20040204.201744.50043551.nomura@png.flab.fujitsu.co.jp> To: Rod.Walsh@nokia.com Cc: juha-pekka.luoma@nokia.com, Hitoshi.Asaeda@sophia.inria.fr, schulzrinne@cs.columbia.edu, csp@csperkins.org, jo@tzi.uni-bremen.de, mmusic@ietf.org Subject: Re: [MMUSIC] RE: Comments on IMG framework -02 From: Yuji Nomura Reply-To: nom@flab.fujitsu.co.jp In-Reply-To: References: X-Mailer: Mew version 3.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, UNSUBSCRIBE operation is a straightforward mechanism to cancel an subscription and may be useful in some cases. However, as Rod said, when SUBSCRIBE operation has an expiration information about the subscription, it provides complete operation to start and finish the subscription. Since the framework draft should cover general model for IMGs, it is better to keep the operations set minimum and give additional information about implementation options such as unsubscription. In conclusion, I agree on Rod's opinion. Regards, ----- Yuji Nomura _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 4 11:12:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12576 for ; Wed, 4 Feb 2004 11:12:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPdZ-0006LP-I3 for mmusic-archive@odin.ietf.org; Wed, 04 Feb 2004 11:12:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GCPGl024384 for mmusic-archive@odin.ietf.org; Wed, 4 Feb 2004 11:12:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPdZ-0006LD-9p for mmusic-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 11:12: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 LAA12570 for ; Wed, 4 Feb 2004 11:12:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPdY-0004vV-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 11:12:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPcY-0004qg-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 11:11:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoPcH-0004lN-00 for mmusic-web-archive@ietf.org; Wed, 04 Feb 2004 11:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPcF-0005eA-Ia; Wed, 04 Feb 2004 11:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPbU-0005dN-4w for mmusic@optimus.ietf.org; Wed, 04 Feb 2004 11:10: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 LAA12479 for ; Wed, 4 Feb 2004 11:10:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPbR-0004ka-00 for mmusic@ietf.org; Wed, 04 Feb 2004 11:10:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPaU-0004gL-00 for mmusic@ietf.org; Wed, 04 Feb 2004 11:09:16 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AoPa4-0004c2-00 for mmusic@ietf.org; Wed, 04 Feb 2004 11:08:48 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 04 Feb 2004 08:08:38 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Wed, 04 Feb 2004 08:06:18 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=projects.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1AoPWT-0005de-Or for robla@real.com; Wed, 04 Feb 2004 08:05:05 -0800 Date: Wed, 04 Feb 2004 08:04:19 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #116 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-633779 ] SET_PARAMETER responses (SourceForge.net) 2. [ rtspspec-Bugs-634944 ] Restarting media not allowing seek (SourceForge.net) 3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net) 4. [ rtspspec-Bugs-640265 ] Extension of Transport header (SourceForge.net) 5. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net) 6. [ rtspspec-Feature Requests-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net) 7. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net) 8. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net) 9. [ rtspspec-Feature Requests-647838 ] Warning header (SourceForge.net) 10. [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 07:14:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses Bugs item #633779, was opened at 2002-11-05 13:19 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: SET_PARAMETER responses Initial Comment: Clarify on the usage of SET_PARAMETER when no body is present. A correct syntax with unknown headers will result in a 200 response but also the understanding of a propreitary or new header will result in 200. Clarify that a requester should use the Require header with an option tag to ensure that the responder of the request really understands the propreitary or new header. Also write text recommending on the usage of parameters in the body with the motivation that they are simpler than using require and headers. But both case should be possible to use. How to handle a empty parameter list in the body should also be explained. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 16:14 Message: Logged In: YES user_id=302620 Forgotten to assign it to me. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 16:13 Message: Logged In: YES user_id=302620 Added text trying to clarify that it is allowed to use for keep alive. Also clarified the possible pit-falls with using headers in such a method. Please review! ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:28 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: how to respond if server doesn't understand parameter # Anders: maybe a require header to be used if necessary # Magnus: I can agree with just a clarification # Anders: for proprietary client request, it can expect proprietary response # Magnus: easier if just use body # Anders: don't need to specify more than that # Rob: I agree # Magnus: spec says that SET_PARAMETER can be used for keep alive # Magnus: it's possible to have SET_PARAMETER without body # RESOLUTION: Short explanation of SET_PARAMETER without body being allowed. No other changes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 07:16:27 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-634944 ] Restarting media not allowing seek Bugs item #634944, was opened at 2002-11-07 13:24 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=634944&group_id=23194 Category: None Group: Fix for DS - Need WG Input >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Restarting media not allowing seek Initial Comment: The current proposal for what happens when a on-demand stream reaches its end is that a explicit seek to the begining is required to see the media from the begining. However how this work for media that does not allow seek needs to be clarififed. - I think a media dissalowing random access will still allow the media to be seen from the begining. - Also how the discovery of which time formats that will be allowed needs to be clarified. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 16:16 Message: Logged In: YES user_id=302620 As this is not directly related to RTSP, rather a content type information problem, the bug is closed. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:30 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: we should close the bug, can be solved by standard RTSP server side support # Magnus: some of the OMA DRM work may apply # Anders: maybe something that can be done in SDP. a=type? # Magnus: on demand media stored, but seeking not allowed. # Magnus: can be on the server side # Rob: only complexity is trying to have client interface before seek is tried # Rob: DVDs don't accomodate this, though # Anders: no way to "grey out" the seek buttons on DVD remote # Joerg: it would be possible to define SDP attribute, but we may end up in rathole trying to characterize all of the possible attributes (for speed, etc). # Magnus: I think RTSP will not have problems here. Current spec is fine # Rob: Agreed # RESOLUTION: close the bug as implemented on server ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=634944&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 08:28:01 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL Bugs item #640272, was opened at 2002-11-18 21:19 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Default way of deriving aggregate URL Initial Comment: Currently there is very little said on which aggregated control URL to use. The only given case is the a=control attribute in SDP at session level. In cases when one aggregates media stream that have no common SDP declaration or dependencies in other ways the URL can't be derived. Examples of such cases is when you would like to aggregate a session multiplexed retransmission stream with the original data stream, without requiring aggregatation between all media types part of a stream. Another example is aggregation of streams that are lacking a common SDP description but still can be intressting to aggregate. To fix this a way to derive what a valid aggregate URL is needs to be specified. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 17:28 Message: Logged In: YES user_id=302620 The rules for creating aggregated URIs has been removed upon discussion in the IETF meeting. anything about using aggregated control URIs when not specified by session description has been labeled as unspecified. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:49 Message: Logged In: YES user_id=302620 Currently I have written in the specification text that a client not having received a aggregated control URI SHOULD consider it as no aggregation available. However it does not rule out that one tries to create aggregated control. The rules for how to create the URI is present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:40 Message: Logged In: YES user_id=302620 In the IETF in Vienna discussion July 16th 2003: Issue: Missing session level control URI in SDP. IF the session control URI is missing, should we allow the client to try to to aggregate these? If aggregated which session control URI must be used. Discussion: This needs to be resolved. Tom Marshall did not thought that we should prevent the use case to aggregate unless necessary for interoperability. One possible resolution is to say that any media description missing session level control URI must be setup with individual RTSP session for each media stream and any synchronization between media be done on the receiver side. A practical resolution resolution could be: A client SHOULD follow the above statement but MAY try to aggregate. The server MAY allow this aggregation but MAY also refuse it using 4xx (Only non aggregated operation allowed). Resolution?: Session declarations lacking a session level control URL, MUST be used in non-aggregated control. Further discussion needed? ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:34 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: this is problem when aggregate control done in not obvious way # Magnus: what happens when you try to aggregate things that aren't designed to be aggregated # Joerg: I think this would require a lot of work to make this work correctly # Magnus: solution is to solve this with non-aggregate control # Tom: how does client know # Magnus: reuse session id # Tom: what happens when you pass the session id with a different URL # Rob: it should be undefined # Magnus: it should return error # Rob: that's no more backward compatible # Magnus: do you have proposed wording 11.4 second paragraph # RESOLUTION: Tom to write up wording for 11.4 second paragraph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 07:49:23 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640265 ] Extension of Transport header Bugs item #640265, was opened at 2002-11-18 21:07 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640265&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Extension of Transport header Initial Comment: The current BNF definition of the transport header does not allow extensions of new parameters. I suggest that a trn-parameter-extension is defined in the BNF to allow for future extensions. Further a mechansism explaining that unknwon parameters are allowed to ignore. If a parameter is vital a option-tag and the Require header needs to be used. This might have backwards compatibility issues as it might cause parsers to decalare the transport header as erronous. However not fixing it will cause even more problems in the future. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 16:49 Message: Logged In: YES user_id=302620 A proposal in the syntax and the some text declaring that unknonw paramters shall be ignored is checked into CVS. Pleae Review ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640265&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 02:31:10 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla Bugs item #640848, was opened at 2002-11-19 19:24 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Magnus Westerlund (magwes) Summary: umbiguity in aggregate/non-aggregate pla Initial Comment: It is not clear to me who's choice it is to pick aggregate play vs. non-aggregate play. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 10:19 Message: Logged In: YES user_id=302620 No comments received, closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 18:11 Message: Logged In: YES user_id=302620 No comments has been given for this since my last comment. I have edited this into the specification. Will be available in v5. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-03-12 15:45 Message: Logged In: YES user_id=302620 It is the clients. With the updated specification the client chooses this by setting up multiple streams or not in a each session. This has no impact on a server that supports aggregated control. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 03:26:19 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-662436 ] RTP/AVP/TCP w/o interleaved Feature Requests item #662436, was opened at 2003-01-05 03:01 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=662436&group_id=23194 >Category: None >Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: RTP/AVP/TCP w/o interleaved Initial Comment: If a Transport line specifies RTP/AVP/TCP and does not also use the interleaved parameter, the transport setup details seem undocumented (maybe I'm not looking in the right place ...). I'm thinking of the level of detail the comedia I-D provides for TCP: which side accept()s and which side connect()s, how many connections to set up, framing, etc. Are there pre-existing implementations that use this transport mode? I happened to stumble onto this in writing the TCP appendix for the MWPP "implementation guidelines" ... which may spawn off a generic I-D specifying how to use comedia with RTP (framing, specifying the fmt tokens after TCP, etc). So, one option is to add RTP/AVP/TCP w/o interleaving details to that I-D, if adding it to to the RTSP I-D isn't desirable for some reason ... john lazzaro -- lazzaro@cs.berkeley.edu ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 11:31 Message: Logged In: YES user_id=302620 The relation to different media and lower layer transport has been clarified in the new draft. There are clear explaination of the RTP/AVP/TCP is not currently specified, but can be. I don't expect that we will do much more about it, as it is a extension rather then a fix to current protocol parts. Therefore moving it to the feature request tracker. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:34 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: we should leave this until RTP framing is done # Magnus: this is basically a feature request # Magnus: this might well be a separate draft # Rob: agreed # Aravind: agreed # Tom: we'll have to deal with this issue when DCCP comes along # Anders: I saw this in use # Tom: they might be using interleaving or not # RESOLUTION: separate draft for non-interleaving; narrow spec for interleaving ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=662436&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 03:26:22 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla Bugs item #640848, was opened at 2002-11-19 19:24 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Magnus Westerlund (magwes) Summary: umbiguity in aggregate/non-aggregate pla Initial Comment: It is not clear to me who's choice it is to pick aggregate play vs. non-aggregate play. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 12:26 Message: Logged In: YES user_id=302620 No comments received, closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 10:19 Message: Logged In: YES user_id=302620 No comments received, closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 18:11 Message: Logged In: YES user_id=302620 No comments has been given for this since my last comment. I have edited this into the specification. Will be available in v5. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-03-12 15:45 Message: Logged In: YES user_id=302620 It is the clients. With the updated specification the client chooses this by setting up multiple streams or not in a each session. This has no impact on a server that supports aggregated control. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 03:26:23 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla Bugs item #640848, was opened at 2002-11-19 19:24 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Magnus Westerlund (magwes) Summary: umbiguity in aggregate/non-aggregate pla Initial Comment: It is not clear to me who's choice it is to pick aggregate play vs. non-aggregate play. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 12:26 Message: Logged In: YES user_id=302620 No comments received, closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 12:26 Message: Logged In: YES user_id=302620 No comments received, closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 10:19 Message: Logged In: YES user_id=302620 No comments received, closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 18:11 Message: Logged In: YES user_id=302620 No comments has been given for this since my last comment. I have edited this into the specification. Will be available in v5. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-03-12 15:45 Message: Logged In: YES user_id=302620 It is the clients. With the updated specification the client chooses this by setting up multiple streams or not in a each session. This has no impact on a server that supports aggregated control. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 05:02:17 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-647838 ] Warning header Feature Requests item #647838, was opened at 2002-12-03 15:27 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=647838&group_id=23194 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Warning header Initial Comment: To be able to send more detailed error messages it might be good to include the SIP header "Warning". ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 14:02 Message: Logged In: YES user_id=302620 As this is a feature request rather than a bug. I move it to the feature request tracker. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-12 13:16 Message: Logged In: YES user_id=302620 This was discussed at the 56th IETF meeting and then later on the teleconf of 28th April 2003. The result is to leave it out unless somebody see a real need to included these headers. Their main use would be related to debugging. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=647838&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 08:03:47 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports Bugs item #672160, was opened at 2003-01-22 01:28 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=672160&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) >Assigned to: Magnus Westerlund (magwes) Summary: Describe a interleaved RTSP channel for client RR reports Initial Comment: In the section on RTP interleaved over the RTSP channel (section 10.13), there was no mention of the client sending RTCP RR back to the server. Are these still present? They did specify the sender reports from the server to client, but that's it. The back channel is symmetric to the RTCP for server to send SRs and should be described as such (i.e. described in Transport headers). ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 17:03 Message: Logged In: YES user_id=302620 The above problem has been clarified with the following text: The channel identifier is defined in the Transport header with the interleaved parameter(Section 13.40). When the transport choice is RTP, RTCP messages are also interleaved by the server over the TCP connection. The usage of RTCP messages is indicated by including a range containing a second channel in the interleaved parameter of the Transport header, see section 13.40. If RTCP is used, packets SHALL be sent on the first available channel higher than the RTP channel. The channels are bi-directional and therefore RTCP traffic are sent on the second channel in both directions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=672160&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 5 01:35:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20912 for ; Thu, 5 Feb 2004 01:35: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 1Aod63-0003DQ-DL for mmusic-archive@odin.ietf.org; Thu, 05 Feb 2004 01:34:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i156YhHs012357 for mmusic-archive@odin.ietf.org; Thu, 5 Feb 2004 01:34:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aod63-0003DE-6C for mmusic-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 01:34: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 BAA20900 for ; Thu, 5 Feb 2004 01:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aod5z-00001K-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 01:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aod51-0007kE-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 01:33:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aod4O-0007gC-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 01:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aod4P-00032A-MI; Thu, 05 Feb 2004 01: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 1Aod49-00031Q-6g for mmusic@optimus.ietf.org; Thu, 05 Feb 2004 01:32: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 BAA20893 for ; Thu, 5 Feb 2004 01:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aod46-0007g7-00 for mmusic@ietf.org; Thu, 05 Feb 2004 01:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aod3A-0007br-00 for mmusic@ietf.org; Thu, 05 Feb 2004 01:31:46 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1Aod2s-0007X8-00 for mmusic@ietf.org; Thu, 05 Feb 2004 01:31:26 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 04 Feb 2004 22:31:17 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by serpico.real.com with esmtp; Wed, 04 Feb 2004 22:29:57 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=projects.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Ao2GY-0005pM-EK for robla@real.com; Tue, 03 Feb 2004 07:15:06 -0800 Date: Tue, 03 Feb 2004 07:14:33 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #115 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup (SourceForge.net) 2. [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP (SourceForge.net) 3. [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification (SourceForge.net) 4. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net) 5. [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP (SourceForge.net) 6. [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 (SourceForge.net) 7. [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs (SourceForge.net) 8. [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC (SourceForge.net) 9. [ rtspspec-Bugs-633148 ] Use of TCP and UDP (SourceForge.net) 10. [ rtspspec-Bugs-633779 ] SET_PARAMETER responses (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:39:02 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup Bugs item #563153, was opened at 2002-06-01 03:42 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Magnus Westerlund (magwes) Summary: Appendix C: agg/non-agg mixup Initial Comment: The initial descriptions of aggregate and non-aggregate contol are reversed, and poorly written. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:39 Message: Logged In: YES user_id=302620 No comments received. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 13:37 Message: Logged In: YES user_id=302620 I have went over the SDP appendix once more and found some more strangeness regarding aggregated and non-aggregated. This is now fixed. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-06-06 22:24 Message: Logged In: YES user_id=3796 It turns out this had already been fixed in the draft-00 version. However, the wording was still very confusing. This has been fixed in the version checked into CVS. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/sdp.tex.diff?r1=1.3&r2=1.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:40:04 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP Bugs item #585865, was opened at 2002-07-24 13:22 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=585865&group_id=23194 Category: General Group: Resolved - Added to text >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Use of Date, and Host in RTSP Initial Comment: There exist a number of HTTP headers that are just referenced into the specification. Several is hard to interpret on how they relate to RTSP and what requirement level that is needed. Date: The date header MUST be sent by origin server in responses. What is an origin server and what exceptions exist for RTSP? For RTSP does that include requests also? Host: The comment is that this should not be used in RTSP. This should be reflected in the heade table. Other headers that are simply referenced needs most probably some specification on applicability and exceptions. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:40 Message: Logged In: YES user_id=302620 No comments, closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:43 Message: Logged In: YES user_id=302620 The Host and Date header has both been clarified on there usage. Edits are checked in for both. The Date has been there for some versions, while the host text is new. If some other headers also needs edit, has not been evaluated at this time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=585865&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:40:44 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification Bugs item #608365, was opened at 2002-09-12 15:23 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: 3xx codes overhaul and clarification Initial Comment: The 3xx codes are all directly taken from HTTP. There seem that not all are suitable for RTSP. A review of the codes and the needs should be perforemed. Also the usage of 3xx responses needs some work. What headers to include, etc. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:40 Message: Logged In: YES user_id=302620 No comments closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 20:43 Message: Logged In: YES user_id=302620 Tom marshall wrote up a proposal for new text regarding the 3xx codes that seperate 304 from the rest. This has been edited in since the 03 version of the draft. No new codes has been specified. The use of 303 is still deprecatied. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:27 Message: Logged In: YES user_id=302620 I have written up a proposal for fixing this within the spec. Two new codes are defiend 350, and 351. 303 is suggested to be decapitated. 304 needs further discussion. Also user comments has been added to the status chapter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:41:38 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response Bugs item #619421, was opened at 2002-10-07 01:14 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Magnus Westerlund (magwes) Summary: Range header in PLAY response Initial Comment: Current RTSP RFC makes Range header in PLAY response from server optional. If the PLAY request includes a Range header indicating a possible seek, then it is probably necessary to include Range in the response since it is possible that the requested seek position could not be honored and playback will resume at the nearest seekable point which is not known to the client. Note: To fix this issue in 3GPP, Range in a PLAY response was made mandatory for all PLAY responses. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:41 Message: Logged In: YES user_id=302620 No comments, closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 14:27 Message: Logged In: YES user_id=302620 The inclusion of the Range header in PLAY responses is now a MUST. We haven't found any problem with this. If anybody finds this, please raise it. I have also put in Maureen into the acknowledgement section. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 13:49 Message: Logged In: YES user_id=302620 As discussed in the teleconf the 22 jan 2003: We should look at strengting the requirement on having the Range header also for live streams when using RTP. A solution based on Range:npt=now- with optional time or using Range:clock=x can work. But careful wording is required. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-11-20 21:06 Message: Logged In: YES user_id=3796 One other thing...put Maureen Chesire in the acknowlegements for raising this.... ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-11-20 21:02 Message: Logged In: YES user_id=3796 Per a conversation with Magnus and I, we think we should soften the language somewhat (strong SHOULD instead of MUST). One case to consider is a live stream, which one would think would obviate the need for this header. However, the rationale for having it in live is when dealing with RTP. Since RTP audio and video streams can have a completely different timestamp base, there needs to be an out-of-band technique for synchronization. The two techniques used in RTSP are: 1. RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch 2. RTCP timestamp<->NTP mapping Eventually, a well-behaved RTSP client will synch the streams based on the RTCP timestamps (when received). However, there's a period before the first RTCP packet arrives that there's no sync, unless a Range header is known. So, that also points to what the Range header should look like. The Range header should include an open-ended wallclock range, like so: Range: clock=20021120T133205Z- RTP-Info:url=rtsp://example.com/fizzle/audiotrack; seq=5712;rtptime=934207921, url=rtsp://example.com/fizzle/videotrack; seq=57654;rtptime=2792482193 The spec should make this clear. An interesting consideration to make here is a restriction on Range response. The current rtsp spec states that "The unit of the range in the reply is the same as that in the request". Perhaps an alternate syntax, if the PLAY request has a Range: header in npt is as follows: Range: npt=now;time=20021120T133205Z The "time" allows for mapping to occur. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:36 Message: Logged In: YES user_id=302620 Yes, the range header is need for RTP synchonization. The draft specification has been updated to require this when using RTP to make synchonization possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:47:27 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP Bugs item #625339, was opened at 2002-10-18 19:57 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Magnus Westerlund (magwes) Summary: need clarification for stand alone SDP Initial Comment: When a SDP file is download other than via RTSP (e.g. HTTP, FTP), control strings need to be all absolute. Should probably put clarification or give an example for this case to avoid confusion. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:47 Message: Logged In: YES user_id=302620 No comments, closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 15:39 Message: Logged In: YES user_id=302620 There has been added a new section in the SDP appendix which writes some clarifying notes on the topic. Text will become available in v5. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:38 Message: Logged In: YES user_id=302620 Yes, this is another pice of information that belong to appendix C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:48:55 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 Bugs item #625342, was opened at 2002-10-18 20:00 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Magnus Westerlund (magwes) Summary: DESCRIBE Res needed in C.2 and C.3 Initial Comment: In the examples for aggregate control SDP and subsequent SETUP request, it is confusing how a URL for SETUP is created. It is missing a DESCRIBE response and gives an impression that a sesseion level control string was used as a base URL. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:48 Message: Logged In: YES user_id=302620 No comments, closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 16:32 Message: Logged In: YES user_id=302620 I agree that the example was not clear. This has now been corrected by including a DESCRIBE response for the aggregated example which has defines a Content-Base, which is the most reasonable solution to this problem. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-31 13:24 Message: Logged In: YES user_id=302620 We may also want to define a dedault rule to create control URLs based on the first media setup so that sessions missing session level control URLs are still possible to set up in aggregates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:49:52 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs Bugs item #625352, was opened at 2002-10-18 20:41 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Magnus Westerlund (magwes) Summary: Synchronising multiple SSRCs Initial Comment: taken from a thread in mmusic We have a problem in RTSP when a media stream needs to contain multiple RTP SSRCs. This can't be expressed today clearly. When one is only interested in controlling the media and not each individual source the following scenarios should be supported: A SINGLE SETUP request can result in one of the following: 1. A media stream with a single SSRC. 2. A media stream with retransmission with SSRC multiplexing. This requires a SSRC for the original and one for the retransmission packets. It is an advantage if both can be explicitly signalled, but is no requirement. 3. Live session with any number of participants and unlimited use of dynamic chosen SSRCs. Due to clients capability the different scenarios need to be explicitly signaled. Scenario 2 will be that from an SDP description and support of retransmission will be signaled by requesting AVPF in the transport header. However today there exist no way to signal if it is scenario 1 or 3. So this needs to be resolved in a nice backwards compatible way. I think that support for 3 can require support for any extra signaling while scenario 1 must work without any extra parts. By doing all these scenarios with a single SETUP per media stream we keep the signaling to a minimum and avoid further requirements on SDP. It might be advantageous in the future to create a SDP attribute declaring the streams type. If one desires to control the individual source one either declare individual media streams for each source. This will require use of ANNOUNCE in dynamic settings. The alternative would be to create a new media resource control protocol which is suited for this. However I don't see real need to solve this problem in standard RTSP better than by using ANNOUNCE. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:49 Message: Logged In: YES user_id=302620 No comments, closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 14:07 Message: Logged In: YES user_id=302620 This was discussed in the telecon the 28th April 2003. The resolution was to clarify in RTSP that only a single SSRC one can be given in RTSP. Any furhter SSRC may be present in the stream, however they must be synchronised using RTCP. This has been clarified in the specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:50:44 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC Bugs item #630920, was opened at 2002-10-30 08:44 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP-Info does not support multiple SSRC Initial Comment: The RTP-Info header can't be used to synchronize multiple RTP flows using different SSRC as a single media stream. As each SSRC has its own RTP sequence and timestamp space to allow synchronization it needs to be possible to give these values for each SSRC in the media stream. This bug has connection with bug# 625352. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:50 Message: Logged In: YES user_id=302620 No comments, closing bug. ---------------------------------------------------------------------- Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 18:00 Message: Logged In: YES user_id=437699 The following text has been added to 13.33 of bis04 to address this bug: The RTP-Info response-header field is used to set RTP-specific parameters in the PLAY response. These parameters correspond to the synchronization source identified by the ssrc parameter of the Transport response header in the SETUP reponse. For streams using RTP as transport protocol the RTP-Info header SHALL be part of a 200 response to PLAY. . . . Additionally, the RTP-Info header parameter fields only apply to a single SSRC within a stream (the SSRC reported in the transport response header; see section 13.40). If there are multiple synchronization sources present within a RTP session, RTCP must be used to map RTP and NTP timestamps for those sources, for both synchronization and drift-checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 06:55:39 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-633148 ] Use of TCP and UDP Bugs item #633148, was opened at 2002-11-04 08:53 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633148&group_id=23194 Category: General >Group: Fix - Discussed/Resolved >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Use of TCP and UDP Initial Comment: A clarification one how each protocol shall be used to transport RTSP messages seems beneficial. For example one should clarify that TCP are bytes streams and any fragmenetation are valid, but that for efficieny one should send the a message in as few packets as possible. UDP needs rules if fragementation is allowed or not. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 15:55 Message: Logged In: YES user_id=302620 The connection chapter has been a long time ago been updated to clarify these issues. UDP has been deprecatied due to lack of implementations providing feedback. Closing bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633148&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 03 Feb 2004 07:13:50 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses Bugs item #633779, was opened at 2002-11-05 13:19 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: SET_PARAMETER responses Initial Comment: Clarify on the usage of SET_PARAMETER when no body is present. A correct syntax with unknown headers will result in a 200 response but also the understanding of a propreitary or new header will result in 200. Clarify that a requester should use the Require header with an option tag to ensure that the responder of the request really understands the propreitary or new header. Also write text recommending on the usage of parameters in the body with the motivation that they are simpler than using require and headers. But both case should be possible to use. How to handle a empty parameter list in the body should also be explained. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 16:13 Message: Logged In: YES user_id=302620 Added text trying to clarify that it is allowed to use for keep alive. Also clarified the possible pit-falls with using headers in such a method. Please review! ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:28 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: how to respond if server doesn't understand parameter # Anders: maybe a require header to be used if necessary # Magnus: I can agree with just a clarification # Anders: for proprietary client request, it can expect proprietary response # Magnus: easier if just use body # Anders: don't need to specify more than that # Rob: I agree # Magnus: spec says that SET_PARAMETER can be used for keep alive # Magnus: it's possible to have SET_PARAMETER without body # RESOLUTION: Short explanation of SET_PARAMETER without body being allowed. No other changes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 5 11:15:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21624 for ; Thu, 5 Feb 2004 11:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom9k-0008LC-HS for mmusic-archive@odin.ietf.org; Thu, 05 Feb 2004 11:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GF84x032023 for mmusic-archive@odin.ietf.org; Thu, 5 Feb 2004 11:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom9k-0008Jz-7J for mmusic-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:15: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 LAA21592 for ; Thu, 5 Feb 2004 11:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom9e-0007EX-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 11:15:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom8g-00077x-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 11:14:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aom7g-00070k-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 11:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom7g-0007yu-9n; Thu, 05 Feb 2004 11:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom6k-0007uX-58 for mmusic@optimus.ietf.org; Thu, 05 Feb 2004 11:12:02 -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 LAA21386 for ; Thu, 5 Feb 2004 11:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom6j-0006ti-00 for mmusic@ietf.org; Thu, 05 Feb 2004 11:12:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom5l-0006my-00 for mmusic@ietf.org; Thu, 05 Feb 2004 11:11:02 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Aom4w-0006bG-00 for mmusic@ietf.org; Thu, 05 Feb 2004 11:10:10 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15G9VA03114; Thu, 5 Feb 2004 10:09:32 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVY79W>; Thu, 5 Feb 2004 10:09:32 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578FAA@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'jdrosen@dynamicsoft.com'" Cc: "'mmusic@ietf.org'" Date: Thu, 5 Feb 2004 10:09:32 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [MMUSIC] Comments/questions on draft-ietf-mmusic-ice-00 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 Hi Jonathan, Per my note on the SIPPING WG mailing list around your NAT scenarios draft based on ICE, I also had a few comments on the ICE draft itself. My primary comments are around the prioritization of the transport addresses, with a few minor nits also noted: 1) Page 12, section 5.3, Prioritizing the Transport Addresses. It seems that the effectiveness of ICE is highly dependent upon the choices of qvalues in terms of getting the optimal path. However, the current recommendations for the assigning priorities are fairly imprecise relative to the overall importance of this aspect of the algorithm. Based on the point in the second paragraph of section 5.3, it seems that rather than a client having knowledge of topology, with ICE, the client is now configured with these relative priorities reflected in the qvalues, which are an indirect reflection of the network configuration. So, it seems that it might be useful to either be more prescriptive on what priorities would give the most desireable results for particular configarations (eg per the scenarios document) or to determine a formula or equation by which the priorities SHOULD be defined, including factors such as the number of intermediaries, etc. At a minimum, some examples in this document would be useful, perhaps just bringing in a snippet or 2 from the scenarios draft. 2) Page 12, section 5.3, Why is it that you would want the local addresses obtained from VPN interfaces to be lowest priority? It would seem that there are some cases where you might want that to be a higher priority. 3) Page 17, section 5.7, 3rd sentence, "...it SHOULD just sent..." should be "...it SHOULD just send...". 4) Page 18, section 5.8, OPEN ISSUE: "doesnt" should be "doesn't" 5) Page 34, Reference [4] RFC 3261, since the qvalue in the alt-attibute is from RFC 3261, shouldn't this be a normative reference? Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 5 12:04:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24172 for ; Thu, 5 Feb 2004 12:04: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 1AomvB-0006Ut-BU for mmusic-archive@odin.ietf.org; Thu, 05 Feb 2004 12:04:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15H49qj024974 for mmusic-archive@odin.ietf.org; Thu, 5 Feb 2004 12:04:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomvB-0006Uj-7L for mmusic-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 12:04:09 -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 MAA24042 for ; Thu, 5 Feb 2004 12:04:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aomv9-0004yq-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 12:04:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aomtb-0004da-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 12:02:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AomsX-0004TZ-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 12:01:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AomjU-0003xN-Ch for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 11:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomjR-0004va-HT; Thu, 05 Feb 2004 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomiU-0004sj-Au for mmusic@optimus.ietf.org; Thu, 05 Feb 2004 11:51:02 -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 LAA23623 for ; Thu, 5 Feb 2004 11:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomiS-0003Zi-00 for mmusic@ietf.org; Thu, 05 Feb 2004 11:51:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomhX-0003VN-00 for mmusic@ietf.org; Thu, 05 Feb 2004 11:50:06 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AomhM-0003Qs-00 for mmusic@ietf.org; Thu, 05 Feb 2004 11:49:52 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 05 Feb 2004 08:49:41 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Thu, 05 Feb 2004 08:47:16 -0800 Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1Aomde-0005jZ-Lp for robla@real.com; Thu, 05 Feb 2004 08:46:02 -0800 Date: Thu, 05 Feb 2004 08:45:08 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #117 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-678107 ] Change of Proxy-Require header (SourceForge.net) 2. [ rtspspec-Feature Requests-707252 ] Update the RTSP URI schemes to support IRI (SourceForge.net) 3. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net) 4. [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip (SourceForge.net) 5. [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT. (SourceForge.net) 6. [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter (SourceForge.net) 7. [ rtspspec-Bugs-770522 ] Request to response time is not limited. (SourceForge.net) 8. [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media (SourceForge.net) 9. [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session (SourceForge.net) 10. [ rtspspec-Bugs-770522 ] Request to response time is not limited. (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 08:12:14 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-678107 ] Change of Proxy-Require header Bugs item #678107, was opened at 2003-01-31 13:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194 Category: General Group: Resolved - Added to text >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Change of Proxy-Require header Initial Comment: Current text: Says that proxy-require applies to both proxy and server. New Proposal: The feature tags in a "Proxy-require" header will only apply to the proxies, and not the server. For feature that the server must support the "Require" header shall be used. If required feature support from both proxy and server both "Proxy-Require" and "Require" must be used. Pro: - Align with SIP's usage of header - Makes it possible to create features tags for proxy only functionality. Otherwise all servers will be mandated to also know about proxy only features. Cons: - Backwards compatibility. (Actually this does not matter much as: A old server implementing the old way would also not work with any new feature tags for proxies. So it will block operation independent of changed semantics or not.) ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 17:12 Message: Logged In: YES user_id=302620 No comments received, text incorperated. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 13:54 Message: Logged In: YES user_id=302620 The necessary text changes have been written in and will become available in version 05 of the draft. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=302620 Whas resolved at the telecon january 22 2003. Resolution: Proxy-require shall only apply to proxies not servers. Needs to be changed in the specification. Should also clarify that a feature tag can be of type, proxy, server or both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 08:14:04 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-707252 ] Update the RTSP URI schemes to support IRI Feature Requests item #707252, was opened at 2003-03-21 01:45 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=707252&group_id=23194 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Nobody/Anonymous (nobody) >Summary: Update the RTSP URI schemes to support IRI Initial Comment: The current RTSP schemes has been updated to allow for literall IPv6. However the URI scheme should also be updated to cover IRI (Internationalized Resource Identifiers). I (Magnus W) will try to get more information on this from the people having created the IRI. Hopefully this is little or no work. For people to read up on URI scheme considerations and other things should look at: RFC 2717 and 2718. I hade so far not had time to dig up any references to the IRI work. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 17:13 Message: Logged In: YES user_id=302620 Moving this to feature request as it is an extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=707252&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 08:16:55 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules Bugs item #739845, was opened at 2003-05-19 14:13 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: "a=range" is missing IANA registration and clear rules Initial Comment: The "a=range" SDP attribute in appendix C.1.5 of the specification has some issues. 1. The parameter is not registered with IANA. Write IANA registration request. 2. The parameter is not clearly defined in regards to ABNF. Write ABNF definition for attribute don't forget extension for new format types. 3. Is multiple range specifications allowed? 4. Write normative language on usage regarding session and media level. 5. Is multiple instances for the different formats allowed? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 17:16 Message: Logged In: YES user_id=302620 No Comments, text available. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 13:16 Message: Logged In: YES user_id=302620 As discussed in MMUSIC the following definition will be added: If the "a=range" attribute contains an open ended range (fmt=start-) this media or session is of unknown duration and SHALL be considered as non seekable unless this property is overriden. This has been edited in and will appear in the 05 draft version. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 12:45 Message: Logged In: YES user_id=302620 Changes are now editied in. See IANA.tex and SDP.tex ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 11:31 Message: Logged In: YES user_id=302620 Has been discussed at telecon 1. Write IANA registration 2. Write ABNF 3. No 4. Yes, will be included. 5. No ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 04 Feb 2004 08:24:36 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip Bugs item #742328, was opened at 2003-05-23 15:44 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194 Category: None Group: Fix - Discussed/Resolved >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: How to handle PLAY request when at the end of a media clip Initial Comment: This is a problem that has surfaced in interoperability test. It shouldn't surface in a correct implemented client talking to a correct server. However how should the server handle it if still happens. The scenario is: The server is playing a stored media clip to the client. The client has a certain amount of buffer space. The client hits PAUSE. However when the PAUSE request reaches the server the server has played all media for the clip. The server respond to the PAUSE request with a Range header containing the pause point. The problem arise when the client likes to resume the playout of the media to the end. The client has all the rest of the media already in its buffer and this should be totally local operation. There are three reasons I see why the client may not know that this is a local operation: 1. The client has not been informed about the duration of the media. Therefore it can use the pause point in the response to determine that the server is at the end of the media clip. 2. The server has not included the pause point in the PAUSE response, may happen for RFC 2326 servers. This is a MUST in the new specification. 3. The client does not check the duration against the given pause point. This the client SHOULD do to prevent this from happening. Any of the three above would result in that the client sends a PLAY request to resume playing (no range header) at the pause point. However the server is already at the of the media clip. So the big question is how the server handles this PLAY request? I can see two ways of resolving it and would like some input on which is the recommended one. A. The server sends a 200 OK on the request to continue. The RTP-Info is for the next packet which will not be sent as result of this PLAY request. The Range header response indicate that the server will play from the given end of the clip to the end of the clip. Then no RTP packets are sent. B. The server sends a 457 (Invalid Range) including in the response the range header for the pause point. In my opinion the best alternative is B. This clearly indicate to the client that no media will be delivered. Also it is in line with the semantics that a PLAY request is only performed when the range is within the media clip. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-04 17:24 Message: Logged In: YES user_id=302620 No comments, closing issue. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 13:38 Message: Logged In: YES user_id=302620 The resolution B has been added to the text in the PLAY method. Will become available from draft version 05. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-13 16:08 Message: Logged In: YES user_id=302620 At the telecon 28th of May 2003 it was the conclusion to use resoultion b. Needs to be written up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Feb 2004 02:00:10 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT. Bugs item #742348, was opened at 2003-05-23 16:21 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194 >Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Aravind Narasimhan (arvy_n) Summary: Usage of implicit REDIRECT. Initial Comment: The RTSP specification provides two explict methods of redirection, the REDIRECT method and the 3XX response codes. Further it is possible to do implict redirection in the media description. This is done by affecting the RTSP control URLs present for the different media. By giving the client a description that either contains absolute URLs or URLs that resolve to another host the redirection takes place. The redirection changes the URL in the redirection. This can be done in three ways: Changing the absolute URLs in the description. Using Content-Location header to set the Base URL to point to another host. Using Content-Base header to set the base URL to point to another host. The two last may require changes of any relative URLs in the description also. Of these methods the usage of Content-Location may be the one that have the most correct semantics. This of course requires that the host being redirected to has the complet session including description. As the Content-Location header tells the client that the given location is an possible resolution for this exact description. The Client Implementation requirement to get this functionality is that it after resolving the URLs check them against the current server address. If different it needs to get a new connection to the new server. This seems fairly simple. Also see mail to MMUSIC mailing list from Philippe Gentric The question is if this behavior shall be considered a valid one or not. The outcome of the discussion should be written in as a clarification to the text of the RTSP specification. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:54 Message: Logged In: YES user_id=302620 From the 57th IETF meeting 16th of July 2003: Issue: How to handle implicit redirection through session description protocol. Discussion: Seems to be desired functionality to have an optimized way for saving a RTT when you perform load balance. There where also the issue that if a server would give a content-base or other base URL. A client should not reconnect unless explicitly redirected. This may result in different behaviour depending if the client are behind a proxy or not. First it was proposed that a new 200 code can be used to indicate that you get the SDP but are redirected. However this seem to have backwards problem. To optimize this in a efficient way you can use a new 350 code to indicate redirection but the client does receive a SDP. This way a old client will do the redirect as it interprets is as 3xx code, while a new client can avoid wasting a extra describe. There are also a need to clarify that a server should not change the host address of the control in regards to the describe URI. Resolution: Create a 350 code for this plus clarify the SHOULD NOT change the host address. Seems reasonable to put into the core specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Feb 2004 06:57:47 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter Bugs item #755472, was opened at 2003-06-16 20:37 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194 Category: None Group: Fix - Discussed/Resolved >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Restricted use of Range header time parameter Initial Comment: The Range header's time parameter has been deprecated from use in PLAY and PAUSE method. The only method still using the time parameter is REDIRECT. The decision to stop using time= for PAUSE and PLAY was discussed at the 56th IETF and at the April 16th telecon. Reasons is that they create hard synchronization problems and possilbe failure modes that does not give the client any error codes. There was also no need seen for the functionality. The change has been edited in and will be published from version 4 of the draft. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-05 15:57 Message: Logged In: YES user_id=302620 No comments given, all edited in, closing issue. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 13:16 Message: Logged In: YES user_id=302620 Sorry, text went on wrong item. Please disregard. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 13:07 Message: Logged In: YES user_id=302620 As discussed in MMUSIC the following definition will be added: If the "a=range" attribute contains an open ended range (fmt=start-) this media or session is of unknown duration and SHALL be considered as non seekable unless this property is overriden. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Feb 2004 06:59:46 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-770522 ] Request to response time is not limited. Bugs item #770522, was opened at 2003-07-13 16:00 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194 >Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Request to response time is not limited. Initial Comment: The time a server is expected to respond to a request in is not defined. This may create interoperability issues that a certain client timesout while another will wait. We should define some time limits for this. Then a server can know that a request needs to be adressed in a certain time. If the server processing takes to long time the server can send a 1xx code to indicate the request as being under processing. The SIP spec can provide hints on how to solve this. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-05 15:59 Message: Logged In: YES user_id=302620 This was further discussed in Minneapolis. Sean has provided text, which was further discussed on the mailing list. Awaiting updated text for integration into specification. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:56 Message: Logged In: YES user_id=302620 From the 57th IETF meeting 16th of July 2003: Issue: Request to Response time-out. The time a request takes until any response is received is not bound. Look at SIP solution? Discussion: The time for a request to be processed is not defined. IF a server is taking long time to process a request it could send a 1xx response to indicate what it is doing. There may be soon need for this, especially if one uses STUN to validate connectivity. Concerns to backwards compatibility that a client will not expect a 1xx response even if this has been defined in RFC 2326. A couple to 10 seconds seem to be a reasonable time for a time-out. Does not seem appropriate to use without a feature tag. However a clarification on the issue is probably not a bad thing. There where also some concerns about the CSeq. Resolution: Not resolved, Aravind to write to the list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Feb 2004 07:01:27 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media Bugs item #771638, was opened at 2003-07-15 16:46 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: a=range in SDP to indicate live media Initial Comment: Today there is some confusion on how a client should know that media is live. To be able to indicate this in SDP the following is proposed: Use a=range with any timeformet but in open ended style will indicate that the media is live, e.g. a=range:npt=0- or a=range:npt=now-. This makes it possible to use also for sessions using SMTPE or UTC times. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-05 16:01 Message: Logged In: YES user_id=302620 Added in, no comments, closing issue. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-09 17:15 Message: Logged In: YES user_id=302620 This has been added into the SDP appendix. Awaiting review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Feb 2004 07:06:20 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session Bugs item #772330, was opened at 2003-07-16 16:09 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 >Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Clarify that RTCP shall be sent during whole session Initial Comment: Appendix B should be clarified to point out that RTCP is expected to be sent from succesful response of SETUP until TEARDOWN. During PAUSE the server and client should both continue to send RTCP as normal. Motivations to this behavior is: - to avoid timing out SSRC, - ensure detection of packet loss at the end of stream. - ensure that RTCP syncrhonization can work (necessary for multiple SSRC). - Ensure that RTP stream work prior to PLAY if there is some delay between them. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-05 16:06 Message: Logged In: YES user_id=302620 No comments given, closing issue. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 17:42 Message: Logged In: YES user_id=302620 A clarification about this has been written into appendix B. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-07-16 16:12 Message: Logged In: YES user_id=302620 At the same time it should be made clear the RTCP BYE is sent when the session is terminated, i.e. at the time of teardown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Feb 2004 08:44:36 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-770522 ] Request to response time is not limited. Bugs item #770522, was opened at 2003-07-13 16:00 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Request to response time is not limited. Initial Comment: The time a server is expected to respond to a request in is not defined. This may create interoperability issues that a certain client timesout while another will wait. We should define some time limits for this. Then a server can know that a request needs to be adressed in a certain time. If the server processing takes to long time the server can send a 1xx code to indicate the request as being under processing. The SIP spec can provide hints on how to solve this. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-05 17:44 Message: Logged In: YES user_id=302620 Text has been added in connections chapter. Please review. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-05 15:59 Message: Logged In: YES user_id=302620 This was further discussed in Minneapolis. Sean has provided text, which was further discussed on the mailing list. Awaiting updated text for integration into specification. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:56 Message: Logged In: YES user_id=302620 From the 57th IETF meeting 16th of July 2003: Issue: Request to Response time-out. The time a request takes until any response is received is not bound. Look at SIP solution? Discussion: The time for a request to be processed is not defined. IF a server is taking long time to process a request it could send a 1xx response to indicate what it is doing. There may be soon need for this, especially if one uses STUN to validate connectivity. Concerns to backwards compatibility that a client will not expect a 1xx response even if this has been defined in RFC 2326. A couple to 10 seconds seem to be a reasonable time for a time-out. Does not seem appropriate to use without a feature tag. However a clarification on the issue is probably not a bad thing. There where also some concerns about the CSeq. Resolution: Not resolved, Aravind to write to the list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 5 17:59:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17569 for ; Thu, 5 Feb 2004 17:59: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 1AosSw-00026W-Qz for mmusic-archive@odin.ietf.org; Thu, 05 Feb 2004 17:59:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15MxMUd008083 for mmusic-archive@odin.ietf.org; Thu, 5 Feb 2004 17:59:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AosSw-00026F-Jc for mmusic-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:59: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 RAA17563 for ; Thu, 5 Feb 2004 17:59:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AosSt-0003e4-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 17:59:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AosRv-0003cB-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 17:58:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AosRj-0003aQ-00 for mmusic-web-archive@ietf.org; Thu, 05 Feb 2004 17:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AosRd-000226-Te; Thu, 05 Feb 2004 17: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 1AoOnG-0000ed-MW for mmusic@optimus.ietf.org; Wed, 04 Feb 2004 10:18: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 KAA10090 for ; Wed, 4 Feb 2004 10:18:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoOnE-00070n-00 for mmusic@ietf.org; Wed, 04 Feb 2004 10:18:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOmG-0006vD-00 for mmusic@ietf.org; Wed, 04 Feb 2004 10:17:24 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AoOlw-0006pP-00 for mmusic@ietf.org; Wed, 04 Feb 2004 10:17:01 -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 ; Wed, 4 Feb 2004 16:16:28 +0100 Received: from gnvasmail1a.gva.ebu.ch ([10.73.222.209]) by gnvasrelay1a.gva.ebu.ch with Microsoft SMTPSVC (5.0.2195.6713); Wed, 4 Feb 2004 16:16:28 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB31.DCB94E84" Subject: RE: [MMUSIC] TVA comments on the framework and requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 4 Feb 2004 16:16:28 +0100 Message-ID: <9BB211A65FCBFD43B95F67BA2485759D1F8F8B@gnvasmail1a.gva.ebu.ch> Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjAA91qE4A== From: "Evain Jean-Pierre" To: "Evain Jean-Pierre" , , X-OriginalArrivalTime: 04 Feb 2004 15:16:28.0827 (UTC) FILETIME=[DCE29EB0:01C3EB31] 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_01C3EB31.DCB94E84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Rod, =20 Any view on my latest comments? =20 Can you please tell me where the metadata model from Luoma is going to be discussed if its not in MMUSIC? =20 Jean-Pierre =20 -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of Evain Jean-Pierre Sent: vendredi, 30. janvier 2004 18:32 To: Rod.Walsh@nokia.com; mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 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 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=20 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 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=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 =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 =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_01C3EB31.DCB94E84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
HI=20 Rod,
 
Any=20 view on my latest comments?
 
Can=20 you please tell me where the metadata model from Luoma is going to be discu= ssed=20 if its not in MMUSIC?
 
Jean-Pierre
 
-----Original Message-----
From:=20 mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of = Evain=20 Jean-Pierre
Sent: vendredi, 30. janvier 2004 18:32
To:=20 Rod.Walsh@nokia.com; mmusic@ietf.org
Subject: RE: [MMUSIC] TVA= comments on the framework and requirements

Hello Rod,
 
as=20 announced earlier...
 
General:  Only one question on the metadata model.  I= have=20 seen a first draft from Oomu.  Isn't it within MMUSIC? If not, can y= ou=20 tell me more?
 
Requirements:
 
R2:=20 Trailer booking for instance is not based on the use of a schedule. = It=20 should be possible e.g. to book the recording of a piece of content from = a=20 trailer proposed on the website.  Full content would be recorde= d=20 when ready for streaming (e.g. Unicast following this client request).&nb= sp;=20 The same schemes as for broadactsing should apply to multicast. = ;=20 I'll try to 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= ot=20 my 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:=
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

F3:
Thanks, it is not Oomu but Luo= ma=20 (sorry).  Where will the work on the metadata model=20 continue?
 
F5
I'll seek advice within TVA fr= om the=20 colleague who proposed this particular comment.
 
Regards,<= /DIV>
 
Jean-Pierre
 
<= FONT=20 face=3DTahoma size=3D2>-----Original Message-----
From:=20 Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]
Sent: mercr= edi,=20 28. janvier 2004 15:18
To: Evain Jean-Pierre;=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the=20 framework and requirements

Hi=20 All
 
Here is my summary (paraphrasing) of the TVA input which relat= es=20 (only) to document review and request for changes (with suggested=20 text).
 
Jean-Pierre, can you validate this and check that the proposed= changes 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 = 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/announceme= nt)=20 possibly in MMUSIC, as well as data models (which would be outside of M= MUSIC=20 charter)
 
 
Requirements:
 
R1. 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 c= overs=20 4.2.2 TV and radio programme delivery, 4.2.3 media coverage of a live e= vent=20 and  4.2.4 distance learning. One could certainly add more use cas= es=20 such as "Trailer booking and recording", "Use of segmented content for= content updates, content replacement for e.g. targeted advertising, an= d=20 virtual programmes", "Discovery and access to related programmes", etc.=  =20  TVA Phase 2 will = enrich=20 these cases by the use of media packages encompassing more content form= ats=20 than audio, video and related ancillary=20 data.
 
Indeed there are many use cases beyond those given in this doc= ument.=20 I propose that no changes are made, however if your experience is that= certain TVA use cases have a strong impact (which is different fr= om the=20 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=20 this sound OK?
 
R3. REQ DEL-3: The TVA data model h= as been=20 designed to deliver data to large audiences <However, TVA does not currently specify IP delive= ry with=20 massive scalability (such as one-to-very-many multicast) and so this is= an=20 open requirement for TVA too>
 
No changes needed
 
R4. REQ DEL-6: TV-Anytime q= ueries are=20 currently client initiated.  The problem of time limited validity = of=20 pushed data remains to be addressed (TVA Phase 2) <and=20 so this is an open requirement for TVA=20 too>
 
= No changes needed
=  
= R5. REQ=20 DES-3: TVA would like to suggest a clarification of this requirements w= ith=20 the need expressed in the IMG framework document for an IMG minimum dat= a=20 model.
=  
=     REQ DES-3: Whereas spec= ific=20 applications relying on IMGs will need to
   select one or more spec= ific=20 application-specific metadata formats
   (standard, syntax, etc.= ), the=20 IMG system MUST be independent of this
   (it may be aware, but i= t will=20 operate in the same way for all).

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

   Thus, a transfer envelo= pe=20 format, that is uniform across all
   different application-s= pecific=20 IMG metadata formats, is needed. The
   payload of this transfe= r=20 envelope would be some application-specific
   metadata, and the envel= ope=20 would support the maintenance of the=20 <= /SPAN>
=    application-specific metadata including th= e=20 metadata relationships=20 <= /SPAN>
=    determined by the data model(s) used.= The=20 transfer envelope would=20 <= /SPAN>
=    not need to be aware of the data model(s) = in=20 use.
=
= R6. REQ=20 DES-6: TV-Anytime should be one of the identifiable metadata=20 formats.
   REQ DES-6: It SHALL be= possible to deduce the metadata format from
   the transfer=20 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 fro= m=20 this list or not recognised". The delivery itself must be independent o= f=20 metadata=20 format.<= /FONT>
= = =  
= = = No changes=20 needed.<= /DIV>
=  
= R7. As concerns the requirements secu= rity=20 mentioned in Section 6, TVA only defines very generic scheme for=20 establishing secure authentication channel between metadata sender and= receiver (TS 102822-7).
=  
= = = No changes=20 needed.
= =  
= =  
= =
Framework:
 
F1. The role of TVA needs clarification =A75.1, which maybe ac= hieved=20 by:
 
   MPEG-7 [6] is a collect= ion of=20 XML-based description tools for general
   multimedia content incl= uding=20 structured multimedia sessions. TV-
   Anytime Forum [7] provi= des=20 descriptions based on MPEG-7 for TV
   specific program guides= . These=20 are likely to be limited to describe
   pictures, music and mov= ies,=20 thus it may be necessary to extend these
   descriptions in order t= o=20 define a variety of documents, game
   programs, binary files,= live=20 events and so on.
--=20 change to ->
 
   MPEG-7 [6] is a collect= ion of=20 XML-based description tools for general
   multimedia content incl= uding=20 structured multimedia sessions.=20
  =20
   The TV-Anytime Forum [7] provides=20 descriptions based on XML=20 schema 
  =20 for TV-specific program guides. TV-Anytime uses= the MPEG-7=20 User
   description profile to a limited exte= nt (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 descr= ibe=20 broadcast schedules,
   on-demand programme guides and progra= mme=20 events.
 
Also, it th= e=20 following is noted 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 schedul= es or=20 events.  Furthermore, TVA has developed a "content referencing" sc= heme=20 and "resolving" mechanisms that provide enhanced flexibility in the=20 management of schedules and associated content.  The type of Phase= 1=20 content is primarily video, audio and ancillary services (Teletext,=20 subtitles, design-for-all features...).  TVA Phase 2 is currently= addressing media packages that will encompass all sorts of data for=20 different media delivery.  It is therefore expected that TVA will = cover=20 a very wide range of applications and content and we would like to ensu= re=20 that IMG allows to TVA data being accessed, transported and delivered u= sing=20 multicast or unicast delivery.
 
&nb= sp;
F2. A more specific= referencing of TVA [7] is desirable, which may be achieved=20 by:
&nb= sp;
   [7] T.-A. Forum, "Metadata=20 specification S-3," TV-Anytime Forum
   Specification SP003v1.2= Part=20 A, TV, TV-Anytime Forum, June 2002.
 
--= change=20 to=20 ->
 
   [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,=20 <= /SPAN>
   select, and rightful use of content on personal s= torage=20 systems<= /FONT>
   ("TV-Anytime Phase 1"); Part 2: System=20 description," ETSI-TS 102=20 <= /SPAN>
   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 work= s on=20 the data model, I will leave related responses to a later email - it se= ems=20 that the information data model submission from Luoma and the TVA data= models should work well together and transport of TVA metadata over IM= G=20 delivery protocols is a natural fit)
 
No changes needed
 
F4. TVA has not specified a unidirectional transport mechanism= for=20 TVA metadata so agrees with the proposal that an IP-based solution is= developed (not SAP)
 
No=20 changes needed
 
F5. TVA has developed some solutions for point-to-point unicas= t=20 metadata delivery with HTTP, TLS, .... These will be interesting to sco= ping=20 the needed work for point-to-point IMG delivery (what can be reused) an= d=20 also subsequent point-to-point protocol work.
 
Open issue: we could describe and= determine limitations and reuse of these in =A75. (Proposed text is=20 welcome!)
= =  
= =  
= = Next instalment in a few=20 days!
= =  
= = Cheers,=20 Rod.
 


********************************************************= **************
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_01C3EB31.DCB94E84-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 6 10:21:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00652 for ; Fri, 6 Feb 2004 10:21: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 1Ap7mj-0002L8-P8 for mmusic-archive@odin.ietf.org; Fri, 06 Feb 2004 10:20:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16FKnuQ008990 for mmusic-archive@odin.ietf.org; Fri, 6 Feb 2004 10:20:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7mj-0002Kv-I2 for mmusic-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:20:49 -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 KAA00602 for ; Fri, 6 Feb 2004 10:20:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7mh-0004Ko-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:20:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7lk-0004Hr-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:19:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7l1-0004F4-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7kz-0001nD-8L; Fri, 06 Feb 2004 10: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 1Ap7kw-0001mz-DH for mmusic@optimus.ietf.org; Fri, 06 Feb 2004 10:18:58 -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 KAA00517 for ; Fri, 6 Feb 2004 10:18:54 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7kt-0004EM-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:18:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7kK-0004Ai-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:18:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7jf-00044D-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:17:39 -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 i16FHcq18899 for ; Fri, 6 Feb 2004 17:17:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 17:17:37 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 17:17:37 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 17:17:36 +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_01C3ECC4.5996379F" Subject: RE: [MMUSIC] TVA comments on the framework and requirements Date: Fri, 6 Feb 2004 17:17:35 +0200 Message-ID: Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjAA91qE4ABhk/UAAAMMMMA= To: Cc: X-OriginalArrivalTime: 06 Feb 2004 15:17:36.0193 (UTC) FILETIME=[59DD5B10:01C3ECC4] 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.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ECC4.5996379F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre (et al.) =20 =20 Sorry for the delay, and thank for your patience. =20 On the data model, the purpose of sharing the data model in MMUSIC is to = ensure that this side of the discussion is included in the IMG Framework = considerations, even though MMUSIC will only charter IMG delivery = protocol work (not "application-specific metadata"). My opinion is that = DVB-CMBS and OMA are the prime options for baseline date model = standardisation (although there's a strong "crystal-ball" element to = this prediction as neither have the final solution at this juncture in = time). It is reasonable to exchange ideas and information and develop = the data model openly, but it is necessary to understand the the MMUSIC = chairs have made it absolutely clear that this is the wrong standards WG = to standardise it. =20 (I'm "announcing" this in MMUSIC so those interested are aware that = there will be non-IETF - and possibly non-all-access - related work and = thus can get involved or ask to be kept up-to-date off-line from MMUSIC) =20 =20 On the IMG FW & reqs feedback: =20 Everything's looking good with the extra comments: =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 broadcasting should apply to multicast. I'll = try to provide you with some text next week. =20 So you mean that an IMG metadata could describe the trailer booking = service where details of how to book are described by the IMG metadata? = The IMG system would not be used to do the booking (although possibly to = subscribe to a notification or wait for an announcement indicating that = the booking service is now available). Do you feel that the the = inclusion of this use cases (in the framework) would have a significant = impact on the conclusion of the framework or the IMG metadata delivery = protocols? I guess your text next week should clarify this. =20 The primary use cases described for IMGs are multicast/multiparty = session enablers, so although unicast services could easily be described = too, this is not the primary objective of IMG/MMUSIC work. =20 F2: I don't see why you shouldn't list them all. Each of them is = relevant to my comments and to the IMG requirements and framework at one = moment or another. What would be the problem with a more comprehensive = list of references? =20 I have never seen an IETF document with such a reference format (it's = much more ETSI style). It's much more usual to provide the "boot-strap" = reference so that the full documented list can be found. (Technically, = only a single reference to the TVA body of work is needed from the = document body text as we do not discuss exact particulars of each of the = documents). To give an example, for FLUTE [], we could easily give a set = of related references, but these would easily be found by first finding = the FLUTE specification and then following the subsequent references. =20 e.g. FLUTE ref option 1: [14] T. Paila, "FLUTE - file delivery over unidirectional transport," Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task Force, Dec. 2003. Work in progress. =20 FLUTE ref option 2: [14] [??] =20 [??] =20 [??] =20 [??] =20 [??] where the <> implies expanding these out to be formal reference style =20 My opinion is to go with the single concise TVA document reference as it = reads easily to IETF-eyes and the remainder of documents are easily = found from this. Does this make sense? =20 =20 BTW, DVB-GBS begin work on IP transport week 11 (the week after = IETF-59), if interested I'd be more than happy to discuss these issues = there also (assuming you will not be in South Korea). =20 Cheers, Rod. =20 ------_=_NextPart_001_01C3ECC4.5996379F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Jean-Pierre (et = al.)
 
<note, = this is a=20 "previous email thread deleted" version of the initial reponse since the = original exceeded 50K and is currently waiting moderator=20 approval>
 
Sorry for the delay, and thank for your=20 patience.
 
On the data model, the = purpose=20 of sharing the data model = in MMUSIC=20 is to ensure that this side of the discussion is included in the IMG = Framework=20 considerations, even though MMUSIC will only charter IMG delivery protocol work (not=20 "application-specific metadata"). = My opinion is that DVB-CMBS and OMA are the prime options = for=20 baseline date model standardisation = (although=20 there's a strong "crystal-ball" element to this prediction as neither=20 have the final solution at this juncture in time). It is = reasonable to=20 exchange ideas and information and develop the data model openly, but it = is=20 necessary to understand the the MMUSIC chairs have made it absolutely = clear that=20 this is the wrong standards WG to standardise=20 it.
&nbs= p;
(I'm "announcing" this in MMUSIC so those = interested=20 are aware that there will be non-IETF - and possibly non-all-access - = related=20 work and thus can get involved or ask to be kept up-to-date off-line = from=20 MMUSIC)
&nbs= p;
&nbs= p;
On the IMG FW & reqs=20 feedback:
&nbs= p;
Everything's looking good with the extra=20 comments:
 
R2:=20 Trailer booking for instance is not based on the use of a = schedule.  It=20 should be possible e.g. to book the recording of a piece of content from = a=20 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 broadcasting should apply to multicast.  I'll = try to=20 provide you with some text next=20 week.
 
So you mean that an IMG metadata could = describe the=20 trailer booking service where details of how to book are described by = the IMG=20 metadata? The IMG system would not be used to do the booking (although = possibly=20 to subscribe to a notification or wait for an announcement indicating = that the=20 booking service is now available). Do you feel that the the inclusion of = this=20 use cases (in the framework) would have a significant impact on the = conclusion=20 of the framework or the IMG metadata delivery protocols? I guess your = text next=20 week should clarify this.
 
The primary use cases described for IMGs = are=20 multicast/multiparty session enablers, so although unicast services = could easily=20 be described too, this is not the primary objective of IMG/MMUSIC=20 work.
 
F2:=20 I don't see why you shouldn't list them all.  Each of them = is=20 relevant to my comments and to the IMG requirements and framework at one = moment=20 or another.  What would be the problem with a more comprehensive = list of=20 references?
 
I have never seen an IETF document with such = a=20 reference format (it's much more ETSI style). It's much more usual to = provide=20 the "boot-strap" reference so that the full documented list can be = found.=20 (Technically, only a single reference to the TVA body of work is needed = from the=20 document body text as we do not discuss exact particulars of each of the = documents). To give an example, for FLUTE [], we could easily give a set = of=20 related references, but these would easily be found by first finding the = FLUTE=20 specification and then following the subsequent=20 references.
 
e.g.
FLUTE ref option = 1:
   [14] T. Paila, "FLUTE - file = delivery over=20 unidirectional transport,"
   Internet Draft=20 draft-ietf-rmt-flute-07, Internet Engineering Task
   = Force, Dec.=20 2003.  Work in progress.
 
FLUTE ref option = 2:
   [14] <FLUTE - File Delivery = over=20 Unidirectional Transport,=20 draft-ietf-rmt-flute-07.txt>
<= /FONT>
   [??] <RFC 3450=20 Asynchronous Layered Coding (ALC) Protocol Instantiation>=20
   [??] <RFC 3451 = Layered=20 Coding Transport (LCT) Building Block>=20
   [??] <RFC 3452 = Forward=20 Error Correction (FEC) Building Block>=20
   [??] <RFC 3453 = The Use of=20 Forward Error Correction (FEC) in Reliable Multicast>=20
   [??] <Compact = Forward=20 Error Correction (FEC) Schemes, = draft-ietf-rmt-bb-fec-supp-compact-01.txt>
<= /FONT>
=
where = the <>=20 implies expanding these out to be formal reference=20 style
 
My opinion is to go with the single concise = TVA=20 document reference as it reads easily to IETF-eyes and the remainder of=20 documents are easily found from this. Does this make=20 sense?
 
 
BTW, DVB-GBS begin work on IP transport week = 11 (the=20 week after IETF-59), if interested I'd be more than happy to discuss = these=20 issues there also (assuming you will not be in South=20 Korea).
 
Cheers, Rod.
 
------_=_NextPart_001_01C3ECC4.5996379F-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 6 10:33:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01276 for ; Fri, 6 Feb 2004 10:33: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 1Ap7yK-00035f-FR for mmusic-archive@odin.ietf.org; Fri, 06 Feb 2004 10:32:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16FWm6p011873 for mmusic-archive@odin.ietf.org; Fri, 6 Feb 2004 10:32:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7yK-00035Q-Al for mmusic-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:32:48 -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 KAA01273 for ; Fri, 6 Feb 2004 10:32:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7yI-0004yg-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7xJ-0004wJ-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:31:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7wa-0004uE-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7wc-0002sY-7W; Fri, 06 Feb 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 1Ap7wO-0002rd-Lf for mmusic@optimus.ietf.org; Fri, 06 Feb 2004 10:30:48 -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 KAA01252 for ; Fri, 6 Feb 2004 10:30:44 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7wM-0004tl-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:30:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7vS-0004ra-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:29:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7v8-0004oo-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:29:30 -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 i16FTTq02946 for ; Fri, 6 Feb 2004 17:29:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 17:29:29 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 17:29:28 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 17:29:27 +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_01C3ECC6.01B310DF" Subject: RE: [MMUSIC] TVA comments on the framework and requirements Date: Fri, 6 Feb 2004 17:29:27 +0200 Message-ID: Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjAA91qE4ABhk/UAAAJn1QAAAOcdQA== To: Cc: X-OriginalArrivalTime: 06 Feb 2004 15:29:27.0219 (UTC) FILETIME=[01AB5030:01C3ECC6] 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.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ECC6.01B310DF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre =20 I understand the use case. It is definitely a good idea. The "TV and = Radio Program Delivery" use case covers this to some extent and the = framework clearly enables this.=20 =20 Do you feel the use cases needs adding to the requirements document?=20 =20 Cheers, Rod. =20 -----Original Message----- From: ext Evain Jean-Pierre [mailto:evain@ebu.ch] Sent: Friday, February 06, 2004 5:20 PM To: Walsh Rod (Nokia-NRC/Tampere) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements Rod, =20 First of all, thank-you for the clarification on the data model issue. = I'll be happy to join any off-line work on this subject. Please let me = know... =20 As concerns the draft documents: =20 - R2: I think that you partly answered your own question... =20 "Trailer advertising and booking allow to notify or publicise an = isolated (unicast or multicast) event. The IMG system should allow an = IMG client to subscribe to a service listing such notifications, but = also allow for annoucements being pushed to IMG clients. Although the = resolving and acquisition protocols shall probably be equivalent to = those used for schedules, data delivery and updating might require the = management of smaller fragments/units of information." =20 - F2: Now I understand what you were trying to do with referencing the = "system" part 2 of the TVA specification. I agree, it is probably the = main hook to the other parts of the specification. =20 I'll probably be attending GBS in Finland. What's going on in South = Korea? =20 Best regards, =20 Jean-Pierre =20 ------_=_NextPart_001_01C3ECC6.01B310DF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Jean-Pierre
 
I understand the use case. It is definitely a = good=20 idea. The "TV and = Radio=20 Program Delivery" use case covers this = to some=20 extent and the framework clearly enables this.
 
Do you feel = the use=20 cases needs adding to the requirements document?
 
Cheers, Rod.
 
-----Original Message-----
From: ext Evain = Jean-Pierre=20 [mailto:evain@ebu.ch]
Sent: Friday, February 06, 2004 5:20=20 PM
To: Walsh Rod (Nokia-NRC/Tampere)
Cc:=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the = framework=20 and requirements

Rod,
 
First=20 of all, thank-you for the clarification on the data model issue.  = I'll be=20 happy to join any off-line work on this subject.  Please let me=20 know...
 
As=20 concerns the draft documents:
 
- R2:=20 I think that you partly answered your own = question...
 
"Trailer advertising and booking allow to notify or=20 publicise an isolated  (unicast or multicast) event. The = IMG=20 system should allow an IMG client to subscribe to a service listing such = notifications, but also allow for annoucements being pushed to IMG=20 clients.  Although the resolving and acquisition protocols shall = probably=20 be equivalent to those used for schedules, data delivery and updating = might=20 require the management of smaller fragments/units of=20 information."
 
- F2:=20 Now I understand what you were trying to do with referencing the = "system" part 2=20 of the TVA specification.  I agree, it is probably the main hook to = the=20 other parts of the specification.
 
I'll=20 probably be attending GBS in Finland.  What's going on in South=20 Korea?
 
Best=20 regards,
 
Jean-Pierre
 
------_=_NextPart_001_01C3ECC6.01B310DF-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 6 10:37:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01531 for ; Fri, 6 Feb 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 1Ap82K-0003PI-3Y for mmusic-archive@odin.ietf.org; Fri, 06 Feb 2004 10:36:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Fausp013090 for mmusic-archive@odin.ietf.org; Fri, 6 Feb 2004 10:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap82K-0003P3-01 for mmusic-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:36:56 -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 KAA01477 for ; Fri, 6 Feb 2004 10:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap82H-0005Bw-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:36:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap81H-00059M-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:35:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap80U-00056U-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 10:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap80U-00038L-T1; Fri, 06 Feb 2004 10:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap80L-00037R-Tq for mmusic@optimus.ietf.org; Fri, 06 Feb 2004 10:34:53 -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 KAA01339 for ; Fri, 6 Feb 2004 10:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap80J-000560-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7zQ-00053B-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:33:57 -0500 Received: from mailgate3.ebu.ch ([194.158.3.52]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7z9-0004ze-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:33:39 -0500 Received: from gnvasrelay1b.gva.ebu.ch (unverified) by MAILGATE3.EBU.CH (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 6 Feb 2004 16:30:08 +0100 Received: from gnvasmail1a.gva.ebu.ch ([10.73.222.209]) by gnvasrelay1b.gva.ebu.ch with Microsoft SMTPSVC (5.0.2195.6713); Fri, 6 Feb 2004 16:33:08 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ECC6.855229E0" Subject: RE: [MMUSIC] TVA comments on the framework and requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 6 Feb 2004 16:33:08 +0100 Message-ID: <9BB211A65FCBFD43B95F67BA2485759D1F8FAE@gnvasmail1a.gva.ebu.ch> Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjAA91qE4ABhk/UAAAJn1QAAAOcdQAAATc3g From: "Evain Jean-Pierre" To: Cc: X-OriginalArrivalTime: 06 Feb 2004 15:33:08.0250 (UTC) FILETIME=[8569F7A0:01C3ECC6] 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.6 required=5.0 tests=AWL,EXCUSE_16,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ECC6.855229E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rod, =20 If you believe that there is common understanding that this is covered... I will not make it a point of principle of having it in. =20 Cheers, JP -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: vendredi, 6. f=E9vrier 2004 16:29 To: Evain Jean-Pierre Cc: mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 Hi Jean-Pierre =20 I understand the use case. It is definitely a good idea. The "TV and Radio Program Delivery" use case covers this to some extent and the framework clearly enables this.=20 =20 Do you feel the use cases needs adding to the requirements document? =20 Cheers, Rod. =20 -----Original Message----- From: ext Evain Jean-Pierre [mailto:evain@ebu.ch] Sent: Friday, February 06, 2004 5:20 PM To: Walsh Rod (Nokia-NRC/Tampere) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 Rod, =20 First of all, thank-you for the clarification on the data model issue. I'll be happy to join any off-line work on this subject. Please let me know... =20 As concerns the draft documents: =20 - R2: I think that you partly answered your own question... =20 "Trailer advertising and booking allow to notify or publicise an isolated (unicast or multicast) event. The IMG system should allow an IMG client to subscribe to a service listing such notifications, but also allow for annoucements being pushed to IMG clients. Although the resolving and acquisition protocols shall probably be equivalent to those used for schedules, data delivery and updating might require the management of smaller fragments/units of information." =20 - F2: Now I understand what you were trying to do with referencing the "system" part 2 of the TVA specification. I agree, it is probably the main hook to the other parts of the specification. =20 I'll probably be attending GBS in Finland. What's going on in South Korea? =20 Best regards, =20 Jean-Pierre =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. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** =20 ------_=_NextPart_001_01C3ECC6.855229E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Rod,
 
If you=20 believe that there is common understanding that this is covered...  I = will=20 not make it a point of principle of having it in.
 
Cheers, JP
-----Original Message-----
From:=20 Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]
Sent: vendred= i, 6.=20 f=E9vrier 2004 16:29
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
 
I understand the use case. It is definitely a = good=20 idea. The "TV and R= adio=20 Program Delivery" use case covers this t= o some=20 extent and the framework clearly enables this.
 
Do you feel t= he use=20 cases needs adding to the requirements document?
 
Cheers, Rod.
 
-----Original Message-----
From: ext Evain Jean-Pierre= [mailto:evain@ebu.ch]
Sent: Friday, February 06, 2004 5:20=20 PM
To: Walsh Rod (Nokia-NRC/Tampere)
Cc:=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the frame= work=20 and requirements

Rod,
 
First of all, thank-you for the clarification on the data model= issue.  I'll be happy to join any off-line work on this subject.&nb= sp;=20 Please let me know...
 
As=20 concerns the draft documents:
 
-=20 R2: I think that you partly answered your own question...
 
"Trailer advertising and booking allow to notify or=20 publicise an isolated  (unicast or multicast) event. The I= MG=20 system should allow an IMG client to subscribe to a service listing such= notifications, but also allow for annoucements being pushed to IMG=20 clients.  Although the resolving and acquisition protocols shall pro= bably=20 be equivalent to those used for schedules, data delivery and updating mig= ht=20 require the management of smaller fragments/units of=20 information."
 
-=20 F2: Now I understand what you were trying to do with referencing the "sys= tem"=20 part 2 of the TVA specification.  I agree, it is probably the main h= ook=20 to the other parts of the specification.
 
I'll=20 probably be attending GBS in Finland.  What's going on in South=20 Korea?
 
Best=20 regards,
 
Jean-Pierre
<= FONT=20 face=3DTahoma size=3D2> 


**********************************************************************
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.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************

=00 ------_=_NextPart_001_01C3ECC6.855229E0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 6 12:02:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04461 for ; Fri, 6 Feb 2004 12:02:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9MW-0002O9-AU for mmusic-archive@odin.ietf.org; Fri, 06 Feb 2004 12:01:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16H1qco009175 for mmusic-archive@odin.ietf.org; Fri, 6 Feb 2004 12:01:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9MV-0002No-1j for mmusic-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 12:01: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 MAA04422 for ; Fri, 6 Feb 2004 12:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9MT-0002W9-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 12:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9Lc-0002TQ-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 12:01:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Ks-0002Qn-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 12:00:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Ks-0001yI-G6; Fri, 06 Feb 2004 12:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7og-0002N1-TI for mmusic@optimus.ietf.org; Fri, 06 Feb 2004 10:22: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 KAA00723 for ; Fri, 6 Feb 2004 10:22:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7oe-0004RT-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:22:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7nh-0004OO-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:21:55 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7mo-0004IW-00 for mmusic@ietf.org; Fri, 06 Feb 2004 10:20:54 -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, 6 Feb 2004 16:20:23 +0100 Received: from gnvasmail1a.gva.ebu.ch ([10.73.222.209]) by gnvasrelay1a.gva.ebu.ch with Microsoft SMTPSVC (5.0.2195.6713); Fri, 6 Feb 2004 16:20:23 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ECC4.BD4A1F44" Subject: RE: [MMUSIC] TVA comments on the framework and requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 6 Feb 2004 16:20:23 +0100 Message-ID: <9BB211A65FCBFD43B95F67BA2485759D1F8FAD@gnvasmail1a.gva.ebu.ch> Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjAA91qE4ABhk/UAAAJn1QA= From: "Evain Jean-Pierre" To: Cc: X-OriginalArrivalTime: 06 Feb 2004 15:20:23.0302 (UTC) FILETIME=[BD782A60:01C3ECC4] 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_01C3ECC4.BD4A1F44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rod, =20 First of all, thank-you for the clarification on the data model issue. I'll be happy to join any off-line work on this subject. Please let me know... =20 As concerns the draft documents: =20 - R2: I think that you partly answered your own question... =20 "Trailer advertising and booking allow to notify or publicise an isolated (unicast or multicast) event. The IMG system should allow an IMG client to subscribe to a service listing such notifications, but also allow for annoucements being pushed to IMG clients. Although the resolving and acquisition protocols shall probably be equivalent to those used for schedules, data delivery and updating might require the management of smaller fragments/units of information." =20 - F2: Now I understand what you were trying to do with referencing the "system" part 2 of the TVA specification. I agree, it is probably the main hook to the other parts of the specification. =20 I'll probably be attending GBS in Finland. What's going on in South Korea? =20 Best regards, =20 Jean-Pierre -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: vendredi, 6. f=E9vrier 2004 15:25 To: Evain Jean-Pierre Cc: mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 Hi Jean-Pierre (et al.) =20 =20 Sorry for the delay, and thank for your patience. =20 On the data model, the purpose of sharing the data model in MMUSIC is to ensure that this side of the discussion is included in the IMG Framework considerations, even though MMUSIC will only charter IMG delivery protocol work (not "application-specific metadata"). My opinion is that DVB-CMBS and OMA are the prime options for baseline date model standardisation (although there's a strong "crystal-ball" element to this prediction as neither have the final solution at this juncture in time). It is reasonable to exchange ideas and information and develop the data model openly, but it is necessary to understand the the MMUSIC chairs have made it absolutely clear that this is the wrong standards WG to standardise it. =20 (I'm "announcing" this in MMUSIC so those interested are aware that there will be non-IETF - and possibly non-all-access - related work and thus can get involved or ask to be kept up-to-date off-line from MMUSIC) =20 =20 On the IMG FW & reqs feedback: =20 Everything's looking good with the extra comments: =20 =09 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 broadcasting should apply to multicast. I'll try to provide you with some text next week. =20 So you mean that an IMG metadata could describe the trailer booking service where details of how to book are described by the IMG metadata? The IMG system would not be used to do the booking (although possibly to subscribe to a notification or wait for an announcement indicating that the booking service is now available). Do you feel that the the inclusion of this use cases (in the framework) would have a significant impact on the conclusion of the framework or the IMG metadata delivery protocols? I guess your text next week should clarify this. =20 The primary use cases described for IMGs are multicast/multiparty session enablers, so although unicast services could easily be described too, this is not the primary objective of IMG/MMUSIC work. =20 =09 F2: I don't see why you shouldn't list them all. Each of them is relevant to my comments and to the IMG requirements and framework at one moment or another. What would be the problem with a more comprehensive list of references? =20 I have never seen an IETF document with such a reference format (it's much more ETSI style). It's much more usual to provide the "boot-strap" reference so that the full documented list can be found. (Technically, only a single reference to the TVA body of work is needed from the document body text as we do not discuss exact particulars of each of the documents). To give an example, for FLUTE [], we could easily give a set of related references, but these would easily be found by first finding the FLUTE specification and then following the subsequent references. =20 e.g. FLUTE ref option 1: [14] T. Paila, "FLUTE - file delivery over unidirectional transport," Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task Force, Dec. 2003. Work in progress. =20 FLUTE ref option 2: =09 [14] =09 =09 [??] =20 [??] =20 [??] =20 =09 [??] =20 [??] where the <> implies expanding these out to be formal reference style =20 My opinion is to go with the single concise TVA document reference as it reads easily to IETF-eyes and the remainder of documents are easily found from this. Does this make sense? =20 =20 BTW, DVB-GBS begin work on IP transport week 11 (the week after IETF-59), if interested I'd be more than happy to discuss these issues there also (assuming you will not be in South Korea). =20 Cheers, Rod. =20 =20 -----Original Message----- From: ext Evain Jean-Pierre [mailto:evain@ebu.ch] Sent: Wednesday, February 04, 2004 5:16 PM To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere); mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 HI Rod, =20 Any view on my latest comments? =20 Can you please tell me where the metadata model from Luoma is going to be discussed if its not in MMUSIC? =20 Jean-Pierre =20 -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of Evain Jean-Pierre Sent: vendredi, 30. janvier 2004 18:32 To: Rod.Walsh@nokia.com; mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements =09 =09 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=20 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 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=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 =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 =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 =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_01C3ECC4.BD4A1F44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Rod,
 
First=20 of all, thank-you for the clarification on the data model issue.  I'll= be=20 happy to join any off-line work on this subject.  Please let me=20 know...
 
As=20 concerns the draft documents:
 
- R2:=20 I think that you partly answered your own question...
 
"Trailer advertising and booking allow to notify or=20 publicise an isolated  (unicast or multicast) event. The IMG= system should allow an IMG client to subscribe to a service listing such= notifications, but also allow for annoucements being pushed to IMG=20 clients.  Although the resolving and acquisition protocols shall proba= bly=20 be equivalent to those used for schedules, data delivery and updating might= require the management of smaller fragments/units of=20 information."
 
- F2:=20 Now I understand what you were trying to do with referencing the "system" p= art 2=20 of the TVA specification.  I agree, it is probably the main hook to th= e=20 other parts of the specification.
 
I'll=20 probably be attending GBS in Finland.  What's going on in South=20 Korea?
 
Best=20 regards,
 
Jean-Pierre
-----Original Message-----
From:=20 Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]
Sent: vendred= i, 6.=20 f=E9vrier 2004 15:25
To: Evain Jean-Pierre
Cc:=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the frame= work=20 and requirements

Hi Jean-Pierre (et al.)<= /DIV>
 
 
Sorry for the delay, and thank for your=20 patience.
 
<= SPAN=20 class=3D763114813-06022004>On the data model, the pu= rpose=20 of sharing the data model in= MMUSIC=20 is to ensure that this side of the discussion is included in the IMG Fram= ework=20 considerations, even though MMUSIC will only charter IMG delivery protocol work (not=20 "application-specific metadata"). My opinion is that DVB-CMBS and OMA are the prime options f= or=20 baseline date model standardisation (alt= hough=20 there's a strong "crystal-ball" element to this prediction as neither=20 have the final solution at this juncture in time). It is reason= able=20 to exchange ideas and information and develop the data model openly, but = it is=20 necessary to understand the the MMUSIC chairs have made it absolutely cle= ar=20 that this is the wrong standards WG to standardise=20 it.
<= SPAN=20 class=3D763114813-06022004>&nbs= p;
<= SPAN=20 class=3D763114813-06022004>(I'm "announcing" this in MMUSIC so those inte= rested=20 are aware that there will be non-IETF - and possibly non-all-access - rel= ated=20 work and thus can get involved or ask to be kept up-to-date off-line from= MMUSIC)
<= SPAN=20 class=3D763114813-06022004>&nbs= p;
<= SPAN=20 class=3D763114813-06022004>&nbs= p;
<= SPAN=20 class=3D763114813-06022004>On the IMG FW & reqs=20 feedback:
<= SPAN=20 class=3D763114813-06022004>&nbs= p;
<= SPAN=20 class=3D763114813-06022004>Everything's looking good with the extra=20 comments:
 
R2:=20 Trailer booking for instance is not based on the use of a schedule. = It=20 should be possible e.g. to book the recording of a piece of content from = a=20 trailer proposed on the website.  Full content would be recorde= d=20 when ready for streaming (e.g. Unicast following this client request).&nb= sp;=20 The same schemes as for broadcasting should apply to multicast. = ;=20 I'll try to provide you with some text next=20 week.
 
So you mean that an IMG metadata could descri= be the=20 trailer booking service where details of how to book are described by the= IMG=20 metadata? The IMG system would not be used to do the booking (although=20 possibly to subscribe to a notification or wait for an announcement indic= ating=20 that the booking service is now available). Do you feel that the the incl= usion=20 of this use cases (in the framework) would have a significant impact on t= he=20 conclusion of the framework or the IMG metadata delivery protocols? I gue= ss=20 your text next week should clarify this.
 
The primary use cases described for IMGs= are=20 multicast/multiparty session enablers, so although unicast services could= easily be described too, this is not the primary objective of IMG/MMUSIC= work.
 
F2:=20 I don't see why you shouldn't list them all.  Each of them = is=20 relevant to my comments and to the IMG requirements and framework at one= moment or another.  What would be the problem with a more comprehen= sive=20 list of references?
 
I have never seen an IETF document with such = a=20 reference format (it's much more ETSI style). It's much more usual to pro= vide=20 the "boot-strap" reference so that the full documented list can be found.= (Technically, only a single reference to the TVA body of work is needed = from=20 the document body text as we do not discuss exact particulars of each of = the=20 documents). To give an example, for FLUTE [], we could easily give a set = of=20 related references, but these would easily be found by first finding the = FLUTE=20 specification and then following the subsequent=20 references.
 
e.g.
FLUTE ref option 1:
   [14] T. Paila, "FLUTE - file del= ivery=20 over unidirectional transport,"
   Internet Draft=20 draft-ietf-rmt-flute-07, Internet Engineering Task
   Force,= Dec.=20 2003.  Work in progress.
 
FLUTE ref option 2:
   [14] <FLUTE - File Delivery o= ver=20 Unidirectional Transport,=20 draft-ietf-rmt-flute-07.txt>
<= /FONT>
<= SPAN=20 class=3D763114813-06022004>   [??] <RFC 3450= Asynchronous Layered Coding (ALC) Protocol Instantiation>=20
<= SPAN=20 class=3D763114813-06022004>   [??] <RFC 3451 L= ayered=20 Coding Transport (LCT) Building Block>= ;=20
<= SPAN=20 class=3D763114813-06022004>   [??] <RFC 3452 F= orward=20 Error Correction (FEC) Building Block>= ;=20
<= SPAN=20 class=3D763114813-06022004>   [??] <RFC 3453 T= he Use=20 of Forward Error Correction (FEC) in Reliable Multicast>=20
<= SPAN=20 class=3D763114813-06022004>   [??] <Compact Fo= rward=20 Error Correction (FEC) Schemes, draft-ietf-rmt-bb-fec-supp-compact-01.txt= >
<= /FONT>
where t= he <>=20 implies expanding these out to be formal reference=20 style
 
My opinion is to go with the single concise T= VA=20 document reference as it reads easily to IETF-eyes and the remainder of= documents are easily found from this. Does this make=20 sense?
 
 
BTW, DVB-GBS begin work on IP transport week = 11 (the=20 week after IETF-59), if interested I'd be more than happy to discuss thes= e=20 issues there also (assuming you will not be in South=20 Korea).
 
Cheers, Rod.
 
 
-----Original Message-----
From: ext Evain Jean-Pierre= [mailto:evain@ebu.ch]
Sent: Wednesday, February 04, 2004 5:16= PM
To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere);=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the frame= work=20 and requirements

HI=20 Rod,
 
Any=20 view on my latest comments?
 
Can=20 you please tell me where the metadata model from Luoma is going to be=20 discussed if its not in MMUSIC?
 
Jean-Pierre
 
<= FONT=20 face=3DTahoma size=3D2>-----Original Message-----
From:=20 mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of=20 Evain Jean-Pierre
Sent: vendredi, 30. janvier 2004=20 18:32
To: Rod.Walsh@nokia.com; mmusic@ietf.org
Subject:= =20 RE: [MMUSIC] TVA comments on the framework and=20 requirements

Hello Rod,
 
as=20 announced earlier...
 
General:  Only one question on the metadata model.  = I have=20 seen a first draft from Oomu.  Isn't it within MMUSIC? If not, can= you=20 tell me more?
 
Requirements:
 
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=20 of content from a trailer proposed on the website.  Full=20 content would be recorded when ready for streaming (e.g. Unicast= following this client request).  The same schemes as for broadact= sing=20 should apply to multicast.  I'll try to provide you with some= text=20 next week.
 
R5: seems to respond to the point at this stage<= /DIV>
 
Framework:
 
F1: okay
 
F2:
I=20 don't see why you shouldn't list them all.  Each of them is releva= nt ot=20 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=20 references?

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

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

Hi All
 
Here is my summary (paraphrasing) of the TVA input which rel= ates=20 (only) to document review and request for changes (with suggested=20 text).
 
Jean-Pierre, can you validate this and check that the propos= ed=20 changes are suitable?
 
General:
 
G1. Both documents are in great shape and cover TVA ide= as, use=20 cases & objectives very well
 
G2. TVA would like to ensure that their system fits int= o the=20 IMG framework. TVA wish to work with us to develop and exchange ideas= to=20 do this - i.e. specify the protocols for delivery (service=20 discovery/announcement) possibly in MMUSIC, as well as data models (w= hich=20 would be outside of MMUSIC charter)
 
 
Requirements:
 
R1. Several TVA solutions meet several of the=20 requirements
 
No changes=20 needed
 
R2. on the content orientated use cases in IMG=20 requirements:
 
TVA Phase 1 definitely= covers=20 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 mor= e use=20 cases such as "Trailer booking and recording", "Use of segmented cont= ent=20 for content updates, content replacement for e.g. targeted advertisin= g,=20 and virtual programmes", "Discovery and access to related programmes"= ,=20 etc. =20  TVA Phase 2 wil= l=20 enrich these cases by the use of media packages encompassing more con= tent=20 formats than audio, video and related ancillary=20 data.
 
Indeed there are many use cases beyond those given in this= document. I propose that no changes are made, however if your experi= ence=20 is that certain TVA use cases have a strong impact (which is=20 different from the existing IMG use cases) on metadata delivery (rath= er=20 than the metadata itself), I would be keen to add just these. Are the= re=20 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 d= oes 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 TV= A=20 too>
 
No changes needed
 
R4. REQ DEL-6: TV-Anytime = queries=20 are currently client initiated.  The problem of time limited val= idity=20 of pushed data remains to be addressed (TVA Phase 2) <and so this is an open requirement for TVA=20 too>
 
No changes=20 needed
 
R5. REQ=20 DES-3: TVA would like to suggest a clarification of this requirements= with=20 the need expressed in the IMG framework document for an IMG minimum d= ata=20 model.
 
    REQ DES-3: Whereas sp= ecific=20 applications relying on IMGs will need to
   select one or more sp= ecific=20 application-specific metadata formats
   (standard, syntax, et= c.),=20 the IMG system MUST be independent of this
   (it may be aware, but= it=20 will operate in the same way for all).

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

   Thus, a transfer enve= lope=20 format, that is uniform across all
   different=20 application-specific IMG metadata formats, is needed. The
   payload of this trans= fer=20 envelope would be some application-specific
   metadata, and the env= elope=20 would support the maintenance of the=20
   application-s= pecific=20 metadata including the metadata relationships=20
   determined&nb= sp;by the=20 data model(s) used. The transfer envelope would=20
   not need to b= e aware=20 of the data model(s) in=20 use.
R6. REQ=20 DES-6: TV-Anytime should be one of the identifiable metadata=20 formats.
   <= /SPAN>REQ=20 DES-6: It SHALL be possible to deduce the metadata format from
   the transfer=20 envelope.
In a sense, al= l metadata=20 formats will be identifiable. The solution would need to allow "a=20 metadata application" to recognise a data field as "recognised f= rom=20 this list or not recognised". The delivery itself must be independent= of=20 metadata=20 format.
 
No changes=20 needed.
 
R7. As concerns the requirements s= ecurity=20 mentioned in Section 6, TVA only defines very generic scheme for=20 establishing secure authentication channel between metadata sender an= d=20 receiver (TS 102822-7).
 
No changes=20 needed.
 <= /DIV>
 <= /DIV>
Framework:
 
F1. The role of TVA needs clarification =A75.1, which maybe = achieved=20 by:
 =
   MPEG-7 [6] is a colle= ction=20 of XML-based description tools for general
   multimedia content in= cluding=20 structured multimedia sessions. TV-
   Anytime Forum [7] pro= vides=20 descriptions based on MPEG-7 for TV
   specific program guid= es.=20 These are likely to be limited to describe
   pictures, music and m= ovies,=20 thus it may be necessary to extend these
   descriptions in order= to=20 define a variety of documents, game
   programs, binary file= s, live=20 events and so on.
--=20 change to ->
 
  = MPEG-7 [6] is a collection of XML-based description tools for= general
   mul= timedia=20 content including structured multimedia sessions.=20
  =20
   The TV-Anytime Forum [7] provides= descriptions based on=20 XML schema 
  =20 <= FONT=20 face=3DArial size=3D2>for TV-specific program guides. TV-Anytime uses= the MPEG-7 User=20
   description profile to a limited ex= tent=20 (for user preferences and <= /DIV>
   usage=20 history) and=20 also a TV-Anytime-specific data model for other=20
   schema - which are optimised to des= cribe=20 broadcast schedules,
   on-demand programme guides and prog= ramme=20 events.
<= /FONT> 
Also, it = the=20 following is noted although not necessary to paste into the=20 framework:
<= /FONT> 
The=20 domain of application of TVA Phase 1 is unidirectional broadcast assi= sted=20 by bi-directional access to ancillary metadata services.  The TV= A=20 specification covers the description of broadcast and on-demand sched= ules=20 or events.  Furthermore, TVA has developed a "content referencin= g"=20 scheme and "resolving" mechanisms that provide enhanced flexibility i= n the=20 management of schedules and associated content.  The type of Pha= se 1=20 content is primarily video, audio and ancillary services (Teletext,= subtitles, design-for-all features...).  TVA Phase 2 is current= ly=20 addressing media packages that will encompass all sorts of data for= different media delivery.  It is therefore expected that TVA wi= ll=20 cover a very wide range of applications and content and we would like= to=20 ensure that IMG allows to TVA data being accessed, transported and=20 delivered using multicast or unicast=20 delivery.
<= /FONT> 
&= nbsp;
F2. A more specif= ic=20 referencing of TVA [7] is desirable, which may be achieved=20 by:
&= nbsp;
 <= FONT=20 face=3D"Courier New">  [= 7] T.-A.=20 Forum, "Metadata specification S-3," TV-Anytime Forum
   Specification SP003v1= .2 Part=20 A, TV, TV-Anytime Forum, June 2002.
<= /FONT>=  
-- change to=20 ->
 
   [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,=20
   select, and rightful= use of=20 content on personal storage=20 systems
   ("TV-Anytime Phase 1= "); Part=20 2: System 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 wo= rks on=20 the data model, I will leave related responses to a later email - it = seems=20 that the information data model submission from Luoma and the TVA dat= a=20 models should work well together and transport of TVA metadata over I= MG=20 delivery protocols is a natural fit)
 
No changes needed
 
F4. TVA has not specified a unidirectional transport mechani= sm for=20 TVA metadata so agrees with the proposal that an IP-based solution is= developed (not SAP)
 
No changes needed
 
F5. TVA has developed some solutions for point-to-point unic= ast=20 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=20 work.
 
Open issue: we could describe a= nd=20 determine limitations and reuse of these in =A75. (Proposed text is= welcome!)
 <= /DIV>
 <= /DIV>
Next instalment in a few=20 days!
 <= /DIV>
Cheers,=20 Rod.
 


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

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



********************************************************= **************
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.

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

 ------_=_NextPart_001_01C3ECC4.BD4A1F44-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 6 12:02:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04462 for ; Fri, 6 Feb 2004 12:02:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9MW-0002O6-9l for mmusic-archive@odin.ietf.org; Fri, 06 Feb 2004 12:01:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16H1qQS009174 for mmusic-archive@odin.ietf.org; Fri, 6 Feb 2004 12:01:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9MU-0002Nk-UD for mmusic-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 12:01: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 MAA04419 for ; Fri, 6 Feb 2004 12:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9MS-0002W4-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 12:01:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9LX-0002TI-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 12:00:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9Kq-0002Ql-00 for mmusic-web-archive@ietf.org; Fri, 06 Feb 2004 12:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9Kn-0001xa-Hq; Fri, 06 Feb 2004 12:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6xP-0000Mh-1X for mmusic@optimus.ietf.org; Fri, 06 Feb 2004 09:27: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 JAA26497 for ; Fri, 6 Feb 2004 09:27:43 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6xM-0007ch-00 for mmusic@ietf.org; Fri, 06 Feb 2004 09:27:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6wN-0007ZK-00 for mmusic@ietf.org; Fri, 06 Feb 2004 09:26:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6vV-0007WL-00 for mmusic@ietf.org; Fri, 06 Feb 2004 09:25:50 -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 i16EPUv17767 for ; Fri, 6 Feb 2004 16:25:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 16:25:29 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 16:25:30 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 16:25:29 +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_01C3ECBD.11BB4097" Subject: RE: [MMUSIC] TVA comments on the framework and requirements Date: Fri, 6 Feb 2004 16:25:28 +0200 Message-ID: Thread-Topic: [MMUSIC] TVA comments on the framework and requirements Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAvqVQAAG2PsjAA91qE4ABhk/UA To: Cc: X-OriginalArrivalTime: 06 Feb 2004 14:25:29.0570 (UTC) FILETIME=[12408C20:01C3ECBD] 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.6 required=5.0 tests=AWL,EXCUSE_16,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ECBD.11BB4097 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre (et al.) =20 =20 Sorry for the delay, and thank for your patience. =20 On the data model, the purpose of sharing the data model in MMUSIC is to = ensure that this side of the discussion is included in the IMG Framework = considerations, even though MMUSIC will only charter IMG delivery = protocol work (not "application-specific metadata"). My opinion is that = DVB-CMBS and OMA are the prime options for baseline date model = standardisation (although there's a strong "crystal-ball" element to = this prediction as neither have the final solution at this juncture in = time). It is reasonable to exchange ideas and information and develop = the data model openly, but it is necessary to understand the the MMUSIC = chairs have made it absolutely clear that this is the wrong standards WG = to standardise it. =20 (I'm "announcing" this in MMUSIC so those interested are aware that = there will be non-IETF - and possibly non-all-access - related work and = thus can get involved or ask to be kept up-to-date off-line from MMUSIC) =20 =20 On the IMG FW & reqs feedback: =20 Everything's looking good with the extra comments: =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 broadcasting should apply to multicast. I'll = try to provide you with some text next week. =20 So you mean that an IMG metadata could describe the trailer booking = service where details of how to book are described by the IMG metadata? = The IMG system would not be used to do the booking (although possibly to = subscribe to a notification or wait for an announcement indicating that = the booking service is now available). Do you feel that the the = inclusion of this use cases (in the framework) would have a significant = impact on the conclusion of the framework or the IMG metadata delivery = protocols? I guess your text next week should clarify this. =20 The primary use cases described for IMGs are multicast/multiparty = session enablers, so although unicast services could easily be described = too, this is not the primary objective of IMG/MMUSIC work. =20 F2: I don't see why you shouldn't list them all. Each of them is = relevant to my comments and to the IMG requirements and framework at one = moment or another. What would be the problem with a more comprehensive = list of references? =20 I have never seen an IETF document with such a reference format (it's = much more ETSI style). It's much more usual to provide the "boot-strap" = reference so that the full documented list can be found. (Technically, = only a single reference to the TVA body of work is needed from the = document body text as we do not discuss exact particulars of each of the = documents). To give an example, for FLUTE [], we could easily give a set = of related references, but these would easily be found by first finding = the FLUTE specification and then following the subsequent references. =20 e.g. FLUTE ref option 1: [14] T. Paila, "FLUTE - file delivery over unidirectional transport," Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task Force, Dec. 2003. Work in progress. =20 FLUTE ref option 2: [14] [??] =20 [??] =20 [??] =20 [??] =20 [??] where the <> implies expanding these out to be formal reference style =20 My opinion is to go with the single concise TVA document reference as it = reads easily to IETF-eyes and the remainder of documents are easily = found from this. Does this make sense? =20 =20 BTW, DVB-GBS begin work on IP transport week 11 (the week after = IETF-59), if interested I'd be more than happy to discuss these issues = there also (assuming you will not be in South Korea). =20 Cheers, Rod. =20 =20 -----Original Message----- From: ext Evain Jean-Pierre [mailto:evain@ebu.ch] Sent: Wednesday, February 04, 2004 5:16 PM To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere); mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements HI Rod, =20 Any view on my latest comments? =20 Can you please tell me where the metadata model from Luoma is going to = be discussed if its not in MMUSIC? =20 Jean-Pierre =20 -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of = Evain Jean-Pierre Sent: vendredi, 30. janvier 2004 18:32 To: Rod.Walsh@nokia.com; mmusic@ietf.org Subject: RE: [MMUSIC] TVA comments on the framework and requirements 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 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 ********************************************************************** 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. ********************************************************************** ********************************************************************** 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_01C3ECBD.11BB4097 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi Jean-Pierre (et = al.)
 
 
Sorry for the delay, and thank for your=20 patience.
 
On the data model, the = purpose=20 of sharing the data model = in MMUSIC=20 is to ensure that this side of the discussion is included in the IMG = Framework=20 considerations, even though MMUSIC will only charter IMG delivery protocol work (not=20 "application-specific metadata"). = My opinion is that DVB-CMBS and OMA are the prime options = for=20 baseline date model standardisation = (although=20 there's a strong "crystal-ball" element to this prediction as neither=20 have the final solution at this juncture in time). It is = reasonable to=20 exchange ideas and information and develop the data model openly, but it = is=20 necessary to understand the the MMUSIC chairs have made it absolutely = clear that=20 this is the wrong standards WG to standardise=20 it.
&nbs= p;
(I'm "announcing" this in MMUSIC so those = interested=20 are aware that there will be non-IETF - and possibly non-all-access - = related=20 work and thus can get involved or ask to be kept up-to-date off-line = from=20 MMUSIC)
&nbs= p;
&nbs= p;
On the IMG FW & reqs=20 feedback:
&nbs= p;
Everything's looking good with the extra=20 comments:
 
R2:=20 Trailer booking for instance is not based on the use of a = schedule.  It=20 should be possible e.g. to book the recording of a piece of content from = a=20 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 broadcasting should apply to multicast.  I'll = try to=20 provide you with some text next=20 week.
 
So you mean that an IMG metadata could = describe the=20 trailer booking service where details of how to book are described by = the IMG=20 metadata? The IMG system would not be used to do the booking (although = possibly=20 to subscribe to a notification or wait for an announcement indicating = that the=20 booking service is now available). Do you feel that the the inclusion of = this=20 use cases (in the framework) would have a significant impact on the = conclusion=20 of the framework or the IMG metadata delivery protocols? I guess your = text next=20 week should clarify this.
 
The primary use cases described for IMGs = are=20 multicast/multiparty session enablers, so although unicast services = could easily=20 be described too, this is not the primary objective of IMG/MMUSIC=20 work.
 
F2:=20 I don't see why you shouldn't list them all.  Each of them = is=20 relevant to my comments and to the IMG requirements and framework at one = moment=20 or another.  What would be the problem with a more comprehensive = list of=20 references?
 
I have never seen an IETF document with such = a=20 reference format (it's much more ETSI style). It's much more usual to = provide=20 the "boot-strap" reference so that the full documented list can be = found.=20 (Technically, only a single reference to the TVA body of work is needed = from the=20 document body text as we do not discuss exact particulars of each of the = documents). To give an example, for FLUTE [], we could easily give a set = of=20 related references, but these would easily be found by first finding the = FLUTE=20 specification and then following the subsequent=20 references.
 
e.g.
FLUTE ref option = 1:
   [14] T. Paila, "FLUTE - file = delivery over=20 unidirectional transport,"
   Internet Draft=20 draft-ietf-rmt-flute-07, Internet Engineering Task
   = Force, Dec.=20 2003.  Work in progress.
 
FLUTE ref option = 2:
   [14] <FLUTE - File Delivery = over=20 Unidirectional Transport,=20 draft-ietf-rmt-flute-07.txt>
<= /FONT>
   [??] <RFC 3450=20 Asynchronous Layered Coding (ALC) Protocol Instantiation>
   [??] <RFC 3451 = Layered=20 Coding Transport (LCT) Building Block>
   [??] <RFC 3452 = Forward=20 Error Correction (FEC) Building Block>
   [??] <RFC 3453 = The Use of=20 Forward Error Correction (FEC) in Reliable Multicast>
   [??] <Compact = Forward=20 Error Correction (FEC) Schemes, = draft-ietf-rmt-bb-fec-supp-compact-01.txt>
<= /FONT>
=
where = the <>=20 implies expanding these out to be formal reference=20 style
 
My opinion is to go with the single concise = TVA=20 document reference as it reads easily to IETF-eyes and the remainder of=20 documents are easily found from this. Does this make=20 sense?
 
 
BTW, DVB-GBS begin work on IP transport week = 11 (the=20 week after IETF-59), if interested I'd be more than happy to discuss = these=20 issues there also (assuming you will not be in South=20 Korea).
 
Cheers, Rod.
 
 
-----Original Message-----
From: ext Evain = Jean-Pierre=20 [mailto:evain@ebu.ch]
Sent: Wednesday, February 04, 2004 5:16=20 PM
To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere);=20 mmusic@ietf.org
Subject: RE: [MMUSIC] TVA comments on the = framework=20 and requirements

HI=20 Rod,
 
Any=20 view on my latest comments?
 
Can=20 you please tell me where the metadata model from Luoma is going to be = discussed=20 if its not in MMUSIC?
 
Jean-Pierre
 
-----Original Message-----
From:=20 mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of = Evain=20 Jean-Pierre
Sent: vendredi, 30. janvier 2004 = 18:32
To:=20 Rod.Walsh@nokia.com; mmusic@ietf.org
Subject: RE: [MMUSIC] = TVA=20 comments on the framework and requirements

Hello Rod,
 
as=20 announced earlier...
 
General:  Only one question on the metadata model.  = I have=20 seen a first draft from Oomu.  Isn't it within MMUSIC? If not, = can you=20 tell me more?
 
Requirements:
 
R2:=20 Trailer booking for instance is not based on the use of a = schedule.  It=20 should be possible e.g. to book the recording of a piece of content = from a=20 trailer proposed on the website.  Full content would be = recorded=20 when ready for streaming (e.g. Unicast following this client = request). =20 The same schemes as for broadactsing should apply to = multicast. =20 I'll try to 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 ot=20 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=20 references?

Generic specification = name:=20
ETSI-TS 102 822; Broadcast and = On-line=20 services: Search, select, and
rightful use of content on personal storage systems =
Identification of specification parts = and=20 sub-parts:
ETSI-TS 102 = 822-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, = indexing,=20 encoding)
ETSI-TS 102 = 822-4:=20 Content Referencing
ETSI-TS 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=20
ETSI TS 102 822-7: = Bidirectional Metadata=20 Delivery Protection

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

Hi=20 All
 
Here is my summary (paraphrasing) of the TVA input which = relates=20 (only) to document review and request for changes (with suggested=20 text).
 
Jean-Pierre, can you validate this and check that the = proposed=20 changes 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 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)=20 possibly in MMUSIC, as well as data models (which would be outside = of MMUSIC=20 charter)
 
 
Requirements:
 
R1. 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 covers=20 4.2.2 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=20 such as "Trailer booking and recording", "Use of segmented content = for=20 content updates, content replacement for e.g. targeted advertising, = and=20 virtual programmes", "Discovery and access to related programmes", = etc.  =  TVA Phase 2 = will enrich=20 these cases by the use of media packages encompassing more content = formats=20 than audio, video and related ancillary=20 data.
 
Indeed there are many use cases beyond those given in this = document.=20 I propose that no changes are made, however if your experience is = that=20 certain TVA use cases have a strong impact (which is different = from the=20 existing IMG use cases) on metadata delivery (rather than the = metadata=20 itself), I would be keen to add just these. Are there such use = cases? Does=20 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 specify IP = delivery with=20 massive scalability (such as one-to-very-many multicast) and so this = is an=20 open requirement for TVA too>
 
No changes needed
 
R4. REQ DEL-6: TV-Anytime = queries are=20 currently client initiated.  The problem of time limited = validity of=20 pushed data remains to be addressed (TVA Phase 2) <and=20 so this is an open requirement for TVA=20 too>
 
No changes = needed
 
R5. REQ=20 DES-3: TVA would like to suggest a clarification of this = requirements with=20 the need 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=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=20 format, that is uniform across all
   different = application-specific=20 IMG metadata formats, is needed. The
   payload of this = transfer=20 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 = specific=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=20 format, that is uniform across all
   different = application-specific=20 IMG metadata formats, is needed. The
   payload of this = transfer=20 envelope would be some application-specific
   metadata, and the = envelope=20 would support the maintenance of the=20 =
   application-specific metadata including = the=20 metadata 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=20 DES-6: TV-Anytime should be one of the identifiable metadata=20 formats.
   REQ DES-6: It SHALL = be=20 possible to deduce the metadata format from
   the transfer=20 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=20 this list or not recognised". The delivery itself must be = independent of=20 metadata=20 = format.
&= nbsp;
No changes=20 = needed.
 
R7. As concerns the requirements = security=20 mentioned in Section 6, TVA only defines very generic scheme for=20 establishing secure authentication channel between metadata sender = and=20 receiver (TS 102822-7).
 
No changes=20 needed.
 
 
Framework:
 
F1. 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=20 are likely to be limited to describe
   pictures, music and = movies,=20 thus it may be necessary to extend these
   descriptions in = order to=20 define a variety of documents, game
   programs, binary = files, live=20 events and so on.
--=20 change to ->
 
   MPEG-7 [6] is a = collection of=20 XML-based description tools for general
   multimedia content = including=20 structured multimedia sessions.=20
  =20
   The TV-Anytime Forum [7] provides=20 descriptions = 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=20 following is noted 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=20 and "resolving" mechanisms that provide enhanced flexibility in the=20 management of schedules and associated content.  The type of = Phase 1=20 content is primarily video, audio and ancillary services (Teletext,=20 subtitles, design-for-all features...).  TVA Phase 2 is = currently=20 addressing media packages that will encompass all sorts of data for=20 different media delivery.  It is therefore expected that TVA = will cover=20 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.
 
 
F2. A more = specific=20 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 Part=20 A, TV, TV-Anytime Forum, June 2002.
 
-- change=20 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=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=20 the data model, I will leave related responses to a later email - it = seems=20 that the information data model submission from Luoma and the TVA = data=20 models should work well together and transport of TVA metadata over = IMG=20 delivery protocols is a natural fit)
 
No changes needed
 
F4. TVA has not specified a unidirectional transport = mechanism for=20 TVA metadata so agrees with the proposal that an IP-based solution = is=20 developed (not SAP)
 
No=20 changes needed
 
F5. TVA has developed some solutions for point-to-point = unicast=20 metadata delivery with HTTP, TLS, .... These will be interesting to = scoping=20 the needed work for point-to-point IMG delivery (what can be reused) = and=20 also subsequent point-to-point protocol work.
 
Open issue: we could describe = and=20 determine limitations and reuse of these in =A75. (Proposed text is=20 = welcome!)
 
 
Next instalment in a few=20 days!
 
Cheers,=20 Rod.
 


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

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



********************************************************= **************
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_01C3ECBD.11BB4097-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 10 17:58:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27876 for ; Tue, 10 Feb 2004 17:58: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 1Aqgp4-0003Op-7e for mmusic-archive@odin.ietf.org; Tue, 10 Feb 2004 17:57:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMvgEl013061 for mmusic-archive@odin.ietf.org; Tue, 10 Feb 2004 17:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgp4-0003Oa-1j for mmusic-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:57: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 RAA27778 for ; Tue, 10 Feb 2004 17:57:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgon-0004T1-00 for mmusic-web-archive@ietf.org; Tue, 10 Feb 2004 17:57:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgnr-0004M2-00 for mmusic-web-archive@ietf.org; Tue, 10 Feb 2004 17:56:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgnQ-0004F2-00 for mmusic-web-archive@ietf.org; Tue, 10 Feb 2004 17:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgnR-0003FR-O8; Tue, 10 Feb 2004 17:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSu3-0004wA-VT for mmusic@optimus.ietf.org; Tue, 10 Feb 2004 03:05:56 -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 DAA04991 for ; Tue, 10 Feb 2004 03:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqStz-0005zN-00 for mmusic@ietf.org; Tue, 10 Feb 2004 03:05:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSt6-0005s0-00 for mmusic@ietf.org; Tue, 10 Feb 2004 03:04:58 -0500 Received: from mail0.u-aizu.ac.jp ([163.143.1.43]) by ietf-mx with esmtp (Exim 4.12) id 1AqSs4-0005lk-00; Tue, 10 Feb 2004 03:03:52 -0500 Received: from procsv3.u-aizu.ac.jp (localhost [127.0.0.1]) by mail0.u-aizu.ac.jp (8.11.6+3.4W/8.11.6/u-aizu internet-gw) with ESMTP id i1A83Ys15620; Tue, 10 Feb 2004 17:03:34 +0900 (JST) Received: from smldoc05 (smldoc05 [163.143.134.132]) by procsv3.u-aizu.ac.jp (8.9.3p2+3.1W/3.7Wistcmx+kanji) with SMTP id RAA29185; Tue, 10 Feb 2004 17:03:33 +0900 (JST) Message-ID: <00be01c3efac$6134ced0$84868fa3@smldoc05> From: "hui wang" To: , , , , , , , , , , , , , , , , , , , , , , , , , Cc: "Zhiyong PENG" , "hui wang" Date: Tue, 10 Feb 2004 17:03:33 +0900 Organization: The University of Aizu, Japan MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01C3EFF7.D0F8C230" 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 Subject: [MMUSIC] CFP of CIT2004 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.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE, LINES_OF_YELLING,LINES_OF_YELLING_2 autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00BB_01C3EFF7.D0F8C230 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable With our apologize for any duplicates; -------------------- CIT2004 CALL FOR PAPER ----------------------- The 2004 International Conference on Computer and Information Technology = (CIT2004) Wuhan, China, 14-16 September 2004,=20 http://smlsvr01.u-aizu.ac.jp/~cit2004/ CALL FOR PAPERS =20 Information technology has been widely considered as one of the most=20 important emerging technologies for the 21st century, which has been = made=20 great impact on people and society. In the recent years, throughout=20 society, the explosion of computer network and information technology=20 has been changing the way people work and live. This conference serves = as=20 one of the major forums for researchers and practitioners from academia=20 and industry to discuss and exchange ideas and opinions, and envision=20 the future of computer and information technology.=20 In 2004, it will specially focus on graphics, multimedia, web = services,=20 and wireless/mobile/pervasive computing in the related research,=20 development and application fields. Topics of particular interest=20 include, but are not limited to: 1) Graphics and MultimediaGraphics systems,=20 shape abstraction modeling,=20 geometric modeling,=20 rendering algorithms,=20 virtual reality techniques,=20 volume visualization,=20 animation techniques,=20 pattern recognition,=20 image understanding,=20 interactive multimedia systems,=20 networked multimedia,=20 human-computer interaction 2) Web-based Services=20 =20 Web data management,=20 web mining,=20 semantic web,=20 web services performance and modeling,=20 e-learning,=20 XML structures,=20 grid-based services,=20 grid middleware and tools,=20 distributed algorithms,=20 peer-to-peer networks,=20 next generation internet technologies =20 3) wireless/mobile/pervasive Computing Wireless computing systems,=20 ad hoc networking service discovery,=20 wireless-phone computing,=20 mobile communication,=20 portable devices and smart sensors,=20 wearable computers and PDAs,=20 pervasive system concepts and architectures,=20 pervasive applications,=20 infrastructure and networks of ubiquitous computing =20 4) Applications=20 Intelligent health care system,=20 information retrieval,=20 knowledge management,=20 information design,=20 medical information systems,=20 database and application systems,=20 software agents,=20 software engineering,=20 natural language processing =20 IMPORTANT DATES Paper submission due: 20 April 2004 Acceptance notification: 5 June 2004 Camera-ready due: 25 June 2004 Author registration: 20 July 2004 PUBLICATIONS =20 The accepted papers have to be presented orally within 25 minutes=20 included discussion at the conference and will be published in=20 proceedings of CIT2004 by IEEE Computer Society. The selected best=20 papers will be published in special issues of International Journals. BEST PAPER AWARDS The program committee will select one winner for the Best Paper = Award=20 (all regular papers are eligible) and one winner for the Best Student = Paper=20 Award (only the regular papers whose first author is a full-time student = are eligible). Each winner will be presented with a certification and=20 a cheque. SUBMISSION GUIDELINESSubmissions should include an abstract,=20 5-7 keywords, the e-mail address of the corresponding author, and must = not=20 exceed 8 pages (IEEE format), including tables and figures, with PDF,=20 PostScript, or MS Word format. Submission of a paper should be regarded as an undertaking that, = should=20 the paper be accepted, at least one of the authors will attend the=20 conference to present the work. Submissions to CIT2004 will be conducted = electronically on the CIT2004 website. Authors unable to access e-mail=20 may send 4 hard copies of their papers to: PC Co-Chair, Dr. Hui Wang School of Computer Science and Engineering,=20 University of Aizu,Ikki-machi, Aizu-Wakamatsu City, Fukushima 965-8580, Japan =20 Email: hwang@u-aizu.ac.jp=20 Tel: +81-242-37-2666 Fax: +81-242-37-2728 CONFERENCE WEB SITE: =20 http://smlsvr01.u-aizu.ac.jp/~cit2004/ =20 HONORARY GENERAL CHAIRS Jingnan Liu, Wuhan University, China Tetsuhiko Ikegami, University of Aizu, Japan GENERAL CHAIRS Daming Wei, University of Aizu, Japan Yanxiang He, Wuhan University, China ADVISORY COMMITTEE =20 Chris Constantinou, Stanford University, USA Chin-Chen Chang, National Chung Cheng University, Taiwan Huowang Chen, Changsha Institute of Technology, China Keqing He, Wuhan University, China Lishan Kang, Wuhan University, China=20 Kae Dal Kwack, Hanyang University, Korea Deyi Li, Institute of China Electronic System Engineering, China Sanli Li, Tsinghua University, China Bole Shi, Fudan University, China Gengfeng Wu, Shanghai University, China Guoqing Wu, Wuhan University, China Fumio Okuyama, Suzuka University of Mecial Science, Japan Yoneo Yano, Tokushima University, Japan=20 =20 PROGRAM COMMITTEE CHAIRS =20 Hui Wang, University of Aizu, Japan Zhiyong Peng, Wuhan University, China=20 Atsushi Kara, University of Aizu, Japan PUBLICITY CHAIRS Qun Jin, Waseda University, Japan Qing Li, City University of Hong Kong, China Yanchun Zhang, Victoria University, Australia LOCAL ORGANISATION COMMITTEE =20 Shi Ying, Wuhan University, China Xusheng Yang, Wuhan University, China Huaibei Zhou, Wuhan University, China Jiaheng Cao, Wuhan University, China Xuhui Li, Wuhan University, China PROGRAM COMMITTEE Saeid Belkasim, Georgia State University, USA = =20 Subhash Bhalla, University of Aizu, Japan = =20 Wenxi Chen, University of Aizu, Japan = =20 Zixue Cheng, University of Aizu, Japan = =20 Michael Cohen, University of Aizu, Japan = =20 Brian d'Auriol, University of Texas at EP, USA = =20 Youdong Ding, Shanghai University, China = =20 Zuxiang Fang, Fudan University, China = =20 Jihong Guan, Wuhan University, China = =20 Guoqing Gu, East China Normal University, China = =20 Ning Gu, Fudan University, China = =20 Minyi Guo, University of Aizu, Japan = =20 Khairuddin Hashim, Tun Abdul Razak University, Malaysia = =20 Toshihiro Hayashi, Saga University, Japan = =20 Aiguo He, University of Aizu, Japan = =20 Tingting He, Huazhong Normal University, China = =20 Susantha Herath, St. Cloud State University, USA = =20 Hai Jin, Huazhong University of Science and Technology, China = =20 Hua Hu, Hangzhou Institute of Commerce, China = =20 Jicheng Hu, Wuhan University, China = =20 Xiaohua Hu, Drexel University, USA = =20 Jie Huang, University of Aizu, Japan = =20 Rajgopal Kannan, Louisiana State University, USA = =20 Keqin Li, State University of New York, USA = =20 Minglu Li, Shanghai Jiao Tong University, China = =20 Vitaliy Kluev, University of Aizu, Japan = =20 Yiwen Liang, Wuhan University, China = =20 Yong Liu, University of Aizu, Japan = =20 Zhen Liu, Nagasaki Institute of Applied Science, Japan = =20 Jianhua Ma, Hosei University, Japan = =20 William L. Martens, McGill University, Canada = =20 Geyong Min, University of Bradford, UK = =20 Nikolay N. Mirenkov, University of Aizu, Japan = =20 Mukesh Mohania, IBM India Res Lab, India = =20 Shoji Nishimura, Waseda University, Japan = =20 Fumio Okuyama, Suzuka University of Medical Science, Japan = =20 Incheon Paik, University of Aizu, Japan = =20 Yi Pan, Georgia State University , USA = =20 Lim Ee Peng, Nanyang Technological University , Singapore = =20 Sibabrata Ray, University of Alabama, USA = =20 Kazuyuki Saito, University of Aizu, Japan = =20 Stanislav G. Sedukhin, University of Aizu, Japan = =20 Timothy K. Shih, Tamkang University, Taiwan = =20 Jung-Pil Shin, University of Aizu, Japan = =20 Masahide Sugiyama, University of Aizu, Japan = =20 Xinmin Tian, Intel Corp., USA = =20 Jari Veijalainen, University of Jyvaskyla, Finland = =20 Lina Wang, Wuhan University, China =20 Ying-Hong Wang, Tamkang University, Taiwan = =20 Werner Winiwarter, University of Vienna, Austria = =20 Bing Wu, Dublin Institute Technology, Ireland = =20 Yang Xiao, University of Memphis, USA = =20 Laurence T. Yang, St. Francis Xavier University , Canada = =20 Jeffrey Xu Yu, Chinese University of Hong Kong, China = =20 Qiangfu Zhao, University of Aizu, Japan = =20 Liang Zhang, Fudan University, China = =20 Shensheng Zhang, Shanghai Jiao Tong University, China = =20 Shuigeng Zhou, Fudan University, China = =20 Xiaofang Zhou, University of Queensland, Australia = =20 -------------------- CIT2004 THE END ----------------------- =20 ------=_NextPart_000_00BB_01C3EFF7.D0F8C230 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
 With our = apologize for=20 any duplicates;

--------------------  CIT2004  = CALL FOR=20 PAPER   -----------------------
 
The 2004 International Conference on Computer and = Information=20 Technology=20
           &nb= sp;           &nbs= p;      =20 (CIT2004)
          =        =20 Wuhan, China, 14-16 September 2004,
 
          &nbs= p;      =20 http://smlsvr01.u-aizu.ac= .jp/~cit2004/
 

CALL FOR PAPERS         =
 
   Information technology has been widely considered as = one of=20 the most
important emerging technologies for the 21st century, which = has=20 been made
great impact on people and society. In the recent years,=20 throughout
society, the explosion of computer network and = information=20 technology
has been changing the way people work and live. This = conference=20 serves as
one of the major forums for researchers and practitioners = from=20 academia
and industry to discuss and exchange ideas and opinions, = and=20 envision
the future of computer and information technology.
 
   In 2004, it will specially focus on graphics, = multimedia, web=20 services,
and wireless/mobile/pervasive computing in the related = research,=20
development and application fields. Topics of particular interest=20
include, but are not limited to:
 
1) Graphics and MultimediaGraphics systems,
 
 shape abstraction modeling,
 geometric modeling,=20
 rendering algorithms,
 virtual reality techniques,=20
 volume visualization,
 animation techniques,=20
 pattern recognition,
 image understanding,=20
 interactive multimedia systems,
 networked = multimedia,=20
 human-computer interaction
 
2) Web-based Services
 
 Web data management,=20
 web mining,
 semantic web,
 web services = performance=20 and modeling,
 e-learning,
 XML structures,=20
 grid-based services,
 grid middleware and tools,=20
 distributed algorithms,
 peer-to-peer networks,=20
 next generation internet technologies
 
3)=20 wireless/mobile/pervasive Computing
 
 Wireless computing systems,
 ad hoc networking = service=20 discovery,
 wireless-phone computing,
 mobile = communication,=20
 portable devices and smart sensors,
 wearable = computers and=20 PDAs,
 pervasive system concepts and architectures, =
 pervasive=20 applications,
 infrastructure and networks of ubiquitous=20 computing
 
4) Applications
 
 Intelligent health care system,
 information = retrieval,=20
 knowledge management,
 information design, =
 medical=20 information systems,
 database and application systems,=20
 software agents,
 software engineering, =
 natural=20 language processing
 
 
IMPORTANT DATES
 
 Paper submission = due:        =20 20 April 2004
 Acceptance = notification:      5=20 June 2004
 Camera-ready=20 due:           &nb= sp; 25=20 June 2004
 Author=20 registration:          20 = July=20 2004
 
PUBLICATIONS       
 
    The accepted papers have to be presented orally = within=20 25 minutes
included discussion at the conference and will be = published in=20
proceedings of CIT2004 by IEEE Computer Society. The selected best=20
papers will be published in special issues of International = Journals.
 
BEST PAPER AWARDS
 
    The program committee will select one winner for = the=20 Best Paper Award
(all regular papers are eligible) and one winner = for the=20 Best Student Paper
Award (only the regular papers whose first author = is a=20 full-time student
are eligible). Each winner will be presented with = a=20 certification and
a cheque. SUBMISSION GUIDELINESSubmissions = should=20 include an abstract,
5-7 keywords, the e-mail address of the = corresponding=20 author, and must not
exceed 8 pages (IEEE format), including tables = and=20 figures, with PDF,
PostScript, or MS Word format.
 
    Submission of a paper should be regarded as an=20 undertaking that, should
the paper be accepted, at least one of the = authors=20 will attend the
conference to present the work. Submissions to = CIT2004 will=20 be conducted
electronically on the CIT2004 website. Authors unable = to access=20 e-mail
may send 4 hard copies of their papers to:
 
 PC Co-Chair, Dr. Hui Wang
 School of Computer Science = and=20 Engineering,
 University of Aizu,Ikki-machi, Aizu-Wakamatsu=20 City,
 Fukushima 965-8580, Japan
 
 Email: hwang@u-aizu.ac.jp
 Tel: = +81-242-37-2666
 Fax: +81-242-37-2728
 
CONFERENCE WEB SITE:        =
 http://smlsvr01.u-aizu.ac= .jp/~cit2004/
 
HONORARY=20 GENERAL CHAIRS
 
 Jingnan Liu, Wuhan University, China
 Tetsuhiko = Ikegami,=20 University of Aizu, Japan
 
GENERAL CHAIRS
 
 Daming Wei, University of Aizu, Japan
 Yanxiang He, = Wuhan=20 University, China
 
ADVISORY COMMITTEE
 
 Chris Constantinou, Stanford=20 University, USA
 Chin-Chen Chang, National Chung Cheng = University,=20 Taiwan
 Huowang Chen, Changsha Institute of Technology,=20 China
 Keqing He, Wuhan University, China
 Lishan Kang, = Wuhan=20 University, China
 Kae Dal Kwack, Hanyang University,=20 Korea
 Deyi Li, Institute of China Electronic System = Engineering,=20 China
 Sanli Li, Tsinghua University, China
 Bole Shi, = Fudan=20 University, China
 Gengfeng Wu, Shanghai University,=20 China
 Guoqing Wu, Wuhan University, China
 Fumio = Okuyama,=20 Suzuka University of Mecial Science, Japan
 Yoneo Yano, = Tokushima=20 University, Japan 
 
PROGRAM COMMITTEE=20 CHAIRS
 
 Hui Wang, University of Aizu, = Japan
 Zhiyong=20 Peng, Wuhan University, China
 Atsushi Kara, University of = Aizu,=20 Japan
 
PUBLICITY CHAIRS
 
 Qun Jin, Waseda University, Japan
 Qing Li, City = University=20 of Hong Kong, China
 Yanchun Zhang, Victoria University, = Australia
 
LOCAL ORGANISATION  COMMITTEE
 
 Shi Ying, = Wuhan=20 University, China
 Xusheng Yang, Wuhan University,=20 China
 Huaibei Zhou, Wuhan University, China
 Jiaheng = Cao, Wuhan=20 University, China
 Xuhui Li, Wuhan University, China
 
PROGRAM COMMITTEE
 
 Saeid Belkasim, Georgia State University,=20 USA           &nbs= p;            = ;    =20
 Subhash Bhalla, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;        =20
 Wenxi Chen, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;           &nbs= p;        =20
 Zixue Cheng, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;           =20
 Michael Cohen, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;         =20
 Brian d'Auriol, University of Texas at EP,=20 USA           &nbs= p;            = ;   =20
 Youdong Ding, Shanghai University,=20 China           &n= bsp;           &nb= sp;         =20
 Zuxiang Fang, Fudan University,=20 China           &n= bsp;           &nb= sp;           &nbs= p;=20
 Jihong Guan, Wuhan University,=20 China           &n= bsp;           &nb= sp;           &nbs= p;=20
 Guoqing Gu, East China Normal University,=20 China           &n= bsp;           &nb= sp;  =20
 Ning Gu, Fudan University,=20 China           &n= bsp;           &nb= sp;           &nbs= p;     =20
 Minyi Guo, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;           &nbs= p; =20
 Khairuddin Hashim, Tun Abdul Razak University,=20 Malaysia           = ;      =20
 Toshihiro Hayashi, Saga University,=20 Japan           &n= bsp;           &nb= sp;        =20
 Aiguo He, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;           &nbs= p;  =20
 Tingting He, Huazhong Normal University,=20 China           &n= bsp;           &nb= sp;   =20
 Susantha Herath, St. Cloud State University,=20 USA           &nbs= p;            = ; =20
 Hai Jin, Huazhong University of Science and Technology,=20 China           &n= bsp;=20
 Hua Hu, Hangzhou Institute of Commerce,=20 China           &n= bsp;           &nb= sp;    =20
 Jicheng Hu, Wuhan University,=20 China           &n= bsp;           &nb= sp;           &nbs= p; =20
 Xiaohua Hu, Drexel University,=20 USA           &nbs= p;            = ;            =    =20
 Jie Huang, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;           &nbs= p; =20
 Rajgopal Kannan, Louisiana State University,=20 USA           &nbs= p;            = ;     =20
 Keqin Li, State University of New York,=20 USA           &nbs= p;            = ;      =20
 Minglu Li, Shanghai Jiao Tong University,=20 China           &n= bsp;           &nb= sp;  =20
 Vitaliy Kluev, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;         =20
 Yiwen Liang, Wuhan University,=20 China           &n= bsp;           &nb= sp;           &nbs= p;=20
 Yong Liu, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;           &nbs= p;  =20
 Zhen Liu, Nagasaki Institute of Applied Science,=20 Japan           &n= bsp;       =20
 Jianhua Ma, Hosei University,=20 Japan           &n= bsp;           &nb= sp;           &nbs= p; =20
 William L. Martens, McGill University,=20 Canada           &= nbsp;           &n= bsp;    =20
 Geyong Min, University of Bradford,=20 UK            = ;            =           =20
 Nikolay N. Mirenkov, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;   =20
 Mukesh Mohania, IBM India Res Lab,=20 India           &n= bsp;           &nb= sp;         =20
 Shoji Nishimura, Waseda University,=20 Japan           &n= bsp;           &nb= sp;       =20
 Fumio Okuyama, Suzuka University of Medical Science,=20 Japan           &n= bsp;           &nb= sp;      =20
 Incheon Paik, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;          =20
 Yi Pan, Georgia State University ,=20 USA           &nbs= p;            = ;           =20
 Lim Ee Peng, Nanyang Technological University ,=20 Singapore          &nbs= p;     =20
 Sibabrata Ray, University  of Alabama,=20 USA           &nbs= p;            = ;       =20
 Kazuyuki Saito, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;        =20
 Stanislav G. Sedukhin, University of Aizu,=20 Japan           &n= bsp;           &nb= sp; =20
 Timothy K. Shih, Tamkang University,=20 Taiwan           &= nbsp;           &n= bsp;     =20
 Jung-Pil Shin, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;         =20
 Masahide Sugiyama, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;     =20
 Xinmin Tian, Intel Corp.,=20 USA           &nbs= p;            = ;            =         =20
 Jari Veijalainen, University of Jyvaskyla,=20 Finland           =            =20
 Lina Wang, Wuhan University,=20 China           &n= bsp;           &nb= sp;       =20
 Ying-Hong Wang, Tamkang University,=20 Taiwan           &= nbsp;           &n= bsp;      =20
 Werner Winiwarter, University of Vienna,=20 Austria           =             &= nbsp;=20
 Bing Wu, Dublin Institute Technology,=20 Ireland           =             &= nbsp;    =20
 Yang Xiao, University  of Memphis,=20 USA           &nbs= p;            = ;           =20
 Laurence T. Yang, St. Francis Xavier University ,=20 Canada           &= nbsp;     =20
 Jeffrey Xu Yu, Chinese University of Hong Kong,=20 China           &n= bsp;       =20
 Qiangfu Zhao, University of Aizu,=20 Japan           &n= bsp;           &nb= sp;          =20
 Liang Zhang, Fudan University,=20 China           &n= bsp;           &nb= sp;           &nbs= p;=20
 Shensheng Zhang, Shanghai Jiao Tong University,=20 China           &n= bsp;        =20
 Shuigeng Zhou, Fudan University,=20 China           &n= bsp;           &nb= sp;          =20
 Xiaofang Zhou, University of Queensland, Australia =20             &= nbsp;      =20
 
--------------------  CIT2004  THE = END  =20 -----------------------
   
   =20
------=_NextPart_000_00BB_01C3EFF7.D0F8C230-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 13 11:12:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17143 for ; Fri, 13 Feb 2004 11: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 1ArfvA-0000Ao-Ji for mmusic-archive@odin.ietf.org; Fri, 13 Feb 2004 11:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGC4GE000655 for mmusic-archive@odin.ietf.org; Fri, 13 Feb 2004 11:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfv9-00009i-W8 for mmusic-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:12: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 LAA17088 for ; Fri, 13 Feb 2004 11:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arfv9-0006Dq-00 for mmusic-web-archive@ietf.org; Fri, 13 Feb 2004 11:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfuD-00067L-00 for mmusic-web-archive@ietf.org; Fri, 13 Feb 2004 11:11:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArftB-000624-00 for mmusic-web-archive@ietf.org; Fri, 13 Feb 2004 11:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArftB-0008CJ-Do; Fri, 13 Feb 2004 11: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 1ArfsJ-0008AG-N3 for mmusic@optimus.ietf.org; Fri, 13 Feb 2004 11:09: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 LAA16956 for ; Fri, 13 Feb 2004 11:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfsH-0005yM-00 for mmusic@ietf.org; Fri, 13 Feb 2004 11:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfrN-0005uf-00 for mmusic@ietf.org; Fri, 13 Feb 2004 11:08:11 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1Arfqa-0005pv-00 for mmusic@ietf.org; Fri, 13 Feb 2004 11:07:21 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 13 Feb 2004 08:07:01 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Fri, 13 Feb 2004 08:06:35 -0800 Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1ArfqK-0005a7-7B for robla@real.com; Fri, 13 Feb 2004 08:07:04 -0800 Date: Fri, 13 Feb 2004 08:06:12 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #118 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state (SourceForge.net) 2. [ rtspspec-Bugs-810666 ] Removal of SETUP in play state (SourceForge.net) 3. [ rtspspec-Feature Requests-810678 ] How to indicate end of media stream (SourceForge.net) 4. [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. (SourceForge.net) 5. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net) 6. [ rtspspec-Bugs-850265 ] Removed features are unspecified, not forbidden (SourceForge.net) 7. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net) 8. [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 (SourceForge.net) 9. [ rtspspec-Bugs-494533 ] The use of the word require in the RFC. (SourceForge.net) 10. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 09 Feb 2004 08:50:52 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state Bugs item #795295, was opened at 2003-08-26 14:08 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 Category: None Group: Resolved - Added to text >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: TEARDOWN using * and the Ready-nm state Initial Comment: The 20 february 2002 we discussed http://rtsp.org/bug506412, for conclusion of that discussion see minutes: http://rtsp.org/2002/telecon/minutes20Feb.html However to me it seems that the need for state Ready-nm is not that great. Also the use of "*" as a URL will not work when proxies are present, unless requirements are put on them to maintain certain state in regards to sessions. The use of the presentation URL also is problematic as some sessions may not have a defined session URL, like for example for sessions intended to be used in non-aggregted mode. Therefore my suggestion is that the Ready-nm state is removed and that teardown using "*" is dissallowed. Comments please. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-09 17:50 Message: Logged In: YES user_id=302620 No comments, the change is edited in. Closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:30 Message: Logged In: YES user_id=302620 The removal has now been performed and checked in in the following commit: /cvsroot/rtspspec/changes.tex,v <-- changes.tex new revision: 1.18; previous revision: 1.17 /cvsroot/rtspspec/iana.tex,v <-- iana.tex new revision: 1.14; previous revision: 1.13 /cvsroot/rtspspec/machine.tex,v <-- machine.tex new revision: 1.13; previous revision: 1.12 /cvsroot/rtspspec/methods.tex,v <-- methods.tex new revision: 1.33; previous revision: 1.32 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:04 Message: Logged In: YES user_id=302620 As no comments has been raised, this will be edited out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 09 Feb 2004 08:58:09 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-810666 ] Removal of SETUP in play state Bugs item #810666, was opened at 2003-09-22 17:30 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194 Category: None Group: Resolved - Added to text >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Removal of SETUP in play state Initial Comment: On MMUSIC there is a proposal to remove the functionality for setup in play state to add a new individual media stream. This not about changing transport parameters! First the need for this is not clear. The only use cases seems to be to do switching between different media streams variants. As this doesn't look as the best method and secondly that switching at all is an add on functionality this seem to not belong in core spec. Secondly removing this will simplify the specification writing. Third, if the method is need in the future it will be possible to write an extension specification. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-09 17:58 Message: Logged In: YES user_id=302620 No comments received. Closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:30 Message: Logged In: YES user_id=302620 The removal has now been performed and checked in in the following commit: /cvsroot/rtspspec/changes.tex,v <-- changes.tex new revision: 1.18; previous revision: 1.17 /cvsroot/rtspspec/iana.tex,v <-- iana.tex new revision: 1.14; previous revision: 1.13 /cvsroot/rtspspec/machine.tex,v <-- machine.tex new revision: 1.13; previous revision: 1.12 /cvsroot/rtspspec/methods.tex,v <-- methods.tex new revision: 1.33; previous revision: 1.32 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:03 Message: Logged In: YES user_id=302620 No comment against this removal has been raised. Therefore this will be editied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 09 Feb 2004 08:59:38 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-810678 ] How to indicate end of media stream Feature Requests item #810678, was opened at 2003-09-22 17:48 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=810678&group_id=23194 Category: None >Group: None Status: Open Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: How to indicate end of media stream Initial Comment: discussed at the 57th IETF meeting 16th of July 2003. Issue: Possible methods for signalling end of stream/media (not session) in RTP. Discussion: Need to signal that a stream/media has ended exist mostly in unbound sessions. Proposal brought up to indicate this is RTCP BYE when the sender stops sending and has waited some time it can remove the SSRC of that source and send the BYE to indicate this. Another proposal was to send this information in RTSP methods. One could use sever to client TEARDOWN to indicate this session really are over, nothing more can be done. PAUSE can be sent when the media has been served but the client may rewind do other operations. The TEARDOWN idea was not liked as certain applications require session data to be sent from client to server using SET_PARAMETER. A new method should be evaluated. There might also exist significant synchronization problems in this. Resolution: Propose a RTSP extension with a new method. Thomas Zeng to write strawman proposal for evaluation to mailing list. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-09 17:59 Message: Logged In: YES user_id=302620 Moving this to feature request as this is what it has become. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:44 Message: Logged In: YES user_id=302620 A strawman proposal is avail in this MMUSIC messge: https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01978.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=810678&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 09 Feb 2004 09:02:25 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. Bugs item #840304, was opened at 2003-11-11 22:54 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=840304&group_id=23194 Category: Editorial Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: CSEQ is direction dependent in numberspaces. Initial Comment: IETF 58 off-line discussion resulted in one point to ensure is edited in:It needs to be clarified that CSeq sequence number spaces are direction dependent. The C->S Requests uses a different space then S->C Requests. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 12:54 Message: Logged In: YES user_id=302620 A clarification has been made and is checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=840304&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 09 Feb 2004 09:04:05 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included? Bugs item #850256, was opened at 2003-11-27 15:06 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: When must RTP-Info be included? Initial Comment: At the RTSP discussion at IETF 58 there where some discussion in regards if RTP-Info really can be presented in all Play Responses when the media streams are RTP. The argument was Live media. The current specification (05) requires this. Are there really a reason for changing this? ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:00 Message: Logged In: YES user_id=302620 The text has been changed to have RTP-Info as SHOULD be included for RTP transported streams. Further motivation why it is important has been given. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-11-28 08:59 Message: Logged In: YES user_id=302620 The argument why a server could not present a RTP-Info header in a PLAY response was due to that the distribution server might not be aware of inter media synchronization of the media streams it forwards. If that is the case there exist the possibility to perform intermedia synchronization with RTCP. In regards to Jae-Whan's comments: Regarding "1) The beginning of the live service" the first comment is that there is no way of knowing that a session is live. This we have addressed through the definition that any open range in the SDP a=range attribute shall be considered Live. "When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains." I don't see how this relates to the intermedia synchronization problem. A client can't rely on that all media streams first packet will represent the same point in time and would therefore result in bad synchronization between the media. In regards to 2: In a live session if you are continuing after a couple of minutes there is no reason for removing the timestamp gap. In a live media session the media will have advanced during the paused time, therefore there does not seem to be any reason to synchronize the media prior to the pause to the one after the pause. Therefore the player should in a live case flush the buffers when it resumes play after a pause. Thus the lack of RTP-Info in this case would have no effect. As the RTP timestamp continues correctly during the paused time the intermedia synchronization established prior to pausing will still be valid I think the main problem of not always requiring RTP-Info is the intermedia synchronization. RTCP can be used, however the time until RTCP has been received for all media may be on order of seconds, thus possibly resulting in that playback has to be commeneced without synchronization. ---------------------------------------------------------------------- Comment By: Jaehwan, Kim (kjh1905m) Date: 2003-11-28 07:18 Message: Logged In: YES user_id=365760 IMHO, it is enough that we focus on 2 cases: 1) the beginning of the live service 2) live PAUSE/Resume because we don't believe live streaming session supports random access. 1) The beginning of the live service At this moment, there is no way for a player to see if the session is live or not. But if there is no RTP-Info, the player can start its session by the following way: When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains. 2) Live PAUSE/Resume Currently, we use monotonic rtptimestamp increament for random access. However, if a player requests PAUSE and Resume after a couple of minute, then rtptimestamp has to have the time gap. Without RTP-Info, how can the player remove the rtptimestamp gap? How can it continue the live session without any timegap? If RTSP Range header field also doesn't exist, a player can do that. From the begginning, the player should remember the first rtptimestamp and after the resume, we can just subtract the first from the lastest rtptimestamp. And then, we can calculate the real presentation time from it, comparing with the real PAUSE time gap. But this behavior of a player is different from general on- demand service having RTP-Info. Therefore, we need to chek our if the player can do that the both cases, RTP-Info and no for live. It means a general VOD player might not continue to work after live PAUSE. Feel free to give me an advise regarding this matter if I am wrong. Thank you! Jae-Hwan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 10 Feb 2004 07:54:49 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850265 ] Removed features are unspecified, not forbidden Bugs item #850265, was opened at 2003-11-27 15:25 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850265&group_id=23194 Category: Editorial >Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Removed features are unspecified, not forbidden Initial Comment: In cases where feature has existed or could be defined, but the core specification does not define them, this should be clearly indicated in the text. A convention definition of unspecified can be added. Then used in the interesting places in the text. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-10 16:54 Message: Logged In: YES user_id=302620 At least a few of the cases has been corrected. However a read through is needed to find any remaining places. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850265&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 10 Feb 2004 07:52:00 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter Bugs item #850267, was opened at 2003-11-27 15:38 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 Category: Editorial Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Gather all ABNF in syntax chapter Initial Comment: - All ABNF needs to be gathered in the syntax chapter. - Ensure that it is in 2234 form - When necessary put references into text when the ABNF gets moved. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:23 Message: Logged In: YES user_id=302620 However the ABNF verifier needs to be run over the syntax. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:11 Message: Logged In: YES user_id=302620 The changes are performed and checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 10 Feb 2004 07:50:54 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 Bugs item #831553, was opened at 2003-10-28 06:20 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 Category: Editorial Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) >Assigned to: Magnus Westerlund (magwes) Summary: Error in rfc2326bis-04 example 15.4 Initial Comment: The last two messages in this example is: C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596 M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596 Range:npt=now- But I wonder how the receiver could perform the sync between RTP timestamp and NPT, without a RTP-Info header in the PLAY response? I wouldn't like to see such RTSP conversation in our applicatoin. A real implementation would likely to conduct the PLAY request/response including RTP-Info, for example: C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596 Range: now- M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596 Range:npt=1000- RTP-Info: url=rtsp://live.example.com/concert/audio; seq=1473; rtptime=80000 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 13:58 Message: Logged In: YES user_id=302620 I agree, however as there are only a single media, there is nothing except NPT to synchronize against. As it is a live session no time scale is given, by the now- answer. Thus I think it in this example could actually be okay to exclude the RTP-Info. However I have added the proposed text to the example. If anyone has comments on this resolution please respond. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 07:32:46 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-494533 ] The use of the word require in the RFC. Bugs item #494533, was opened at 2001-12-18 11:16 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494533&group_id=23194 Category: Editorial Group: Fix for DS - Large task Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: The use of the word require in the RFC. Initial Comment: The RFC contains different usage of the word require. Sometimes it means that a implementation must interpret and understand a header or method. Othertimes the a certain header must be sent togheter with a method. One fix is to create a better table for the headers that clarifies the two different cases. Another is looking over the methods and use cases and clearly write when they must be included. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 10:42 Message: Logged In: YES user_id=302620 There are also a great need to look at the usage of normative language according to RFC 2119. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-19 02:29 Message: Logged In: YES user_id=3796 We need to rework that table to clarify the difference between the two. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494533&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 08:03:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP Bugs item #853175, was opened at 2003-12-03 11:00 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Dest_addr needs indicator for using RTSP IP Initial Comment: The transport header parameters dest_addr and src_addr that has been introduced to cope with non-adjacent ports and same IP address for media transport protocols like RTP that requries multiple streams to work. There seem to be motivated to ensure that previously allowed behavoir to exclude giving a destination address and instead have the server to deliver the media to the source ip of the RTSP carrying TCP connection. To enable this with the new paramters some changes are required, the 05 version requries you to put in some address. So either we change this, or define a indicator for this behavior. This will allow that clients in private address spaces using some addesstranslation techniuqes to use them without being requried to learn their external address. Examples of such translation are realm specific IP and NAT's without port translation. Please do also note that for these translations the usage of public STUN server works. However it should be noted the lack of destination address is not without its consideration. IF an RTSP proxy is used, it will be requried to add the destination address, before forwariding any SETUP request. There are also need to furhter review if any furhter security considerations are needed. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-13 17:03 Message: Logged In: YES user_id=302620 I don't think we need to have a indication in dest_addr. The lack of dest_addr or destination will be a indication that the server should perform this. I have added text to indicate this. However I wonder if we also should clarify that a server should always respond with a destination indication to show where it interprets the media should be delivered. This would allow a client to make some error handling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Feb 16 04:59:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08838 for ; Mon, 16 Feb 2004 04:59: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 1AsfX3-0000w3-G8 for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 04:59:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G9xHwC003588 for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 04:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfX2-0000vh-2j for mmusic-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 04:59: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 EAA08822 for ; Mon, 16 Feb 2004 04:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsfWy-0007Er-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 04:59:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsfWC-0007Bk-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 04:58:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsfVq-000778-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 04: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 1AsfVq-0000l9-AX; Mon, 16 Feb 2004 04:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfVA-0000kU-7L for mmusic@optimus.ietf.org; Mon, 16 Feb 2004 04:57: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 EAA08721 for ; Mon, 16 Feb 2004 04:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsfV6-000767-00 for mmusic@ietf.org; Mon, 16 Feb 2004 04:57:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsfUB-00071k-00 for mmusic@ietf.org; Mon, 16 Feb 2004 04:56:19 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AsfTW-0006wL-00 for mmusic@ietf.org; Mon, 16 Feb 2004 04:55:38 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60109 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AsfT3-0003tZ-00; Mon, 16 Feb 2004 09:55:09 +0000 Date: Mon, 16 Feb 2004 09:55:41 +0000 From: Colin Perkins To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de Message-Id: <20040216095541.52cdc82c.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.9 (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] Agenda items for 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, We have requested one agenda slot for MMUSIC at the 59th IETF in Seoul. If you wish agenda time, please contact the chairs by the end of this week. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Feb 16 09:25:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19855 for ; Mon, 16 Feb 2004 09:25:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjgV-0001Po-Ty for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 09:25:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GEPJ4O005434 for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 09:25:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjgV-0001PZ-Nu for mmusic-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 09:25:19 -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 JAA19852 for ; Mon, 16 Feb 2004 09:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsjgT-0007Nt-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 09:25:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asjfd-0007LE-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 09:24:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsjfG-0007IB-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 09:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjfE-0001JF-RK; Mon, 16 Feb 2004 09:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjeW-0001Ie-4q for mmusic@optimus.ietf.org; Mon, 16 Feb 2004 09:23: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 JAA19735 for ; Mon, 16 Feb 2004 09:23:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsjeU-0007Fy-00 for mmusic@ietf.org; Mon, 16 Feb 2004 09:23:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asjda-0007D5-00 for mmusic@ietf.org; Mon, 16 Feb 2004 09:22:18 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Asjch-0007AQ-00 for mmusic@ietf.org; Mon, 16 Feb 2004 09:21:23 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1GELMYG024143 for ; Mon, 16 Feb 2004 15:21:22 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 15:21:22 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FBM8ACJY; Mon, 16 Feb 2004 15:21:22 +0100 Message-ID: <4030D1E0.9090104@ericsson.com> Date: Mon, 16 Feb 2004 15:21:20 +0100 X-Sybari-Trust: 3ef1eaa9 c77f3eb6 787eb308 00000138 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: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2004 14:21:22.0370 (UTC) FILETIME=[270A5220:01C3F498] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] New version of the RTSP specification 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 Hi, A few minutes ago we submitted version 6 of the updated RTSP specificaiton. Using the last minutes as usual. There are a significiant amount of changes in this version. At the same time it also resolves a lot of the issues. Now the amount of open issues not addressed at all are rahter few. Therefore I would now recommend people to start reading it. I know it is a thick bastard, however we are in need of review. Until it is available from the IETF it can be fetched here: Text Version: http://standards.ericsson.net/westerlund/draft-ietf-mmusic-rfc2326bis-06.txt PDF Version: http://standards.ericsson.net/westerlund/draft-ietf-mmusic-rfc2326bis-06.pdf I plan to have both a WG presentation and have an offline meeting to discuss the remaining issues. I will try to get out a agenda for the offline meeting before the meeting starts. 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Feb 16 10:50:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26781 for ; Mon, 16 Feb 2004 10:50:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asl0r-0008L3-Cj for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 10:50:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFoPMV032049 for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 10:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asl0r-0008Kq-8t for mmusic-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:50: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 KAA26768 for ; Mon, 16 Feb 2004 10:50:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asl0o-0006Ap-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 10:50:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Askzw-00067R-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 10:49:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AskzV-00063w-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 10:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskzV-00082t-RZ; Mon, 16 Feb 2004 10:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asknm-0006Hq-AX for mmusic@optimus.ietf.org; Mon, 16 Feb 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 KAA25790 for ; Mon, 16 Feb 2004 10:36:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsknZ-0004vg-00 for mmusic@ietf.org; Mon, 16 Feb 2004 10:36:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Askmn-0004pa-00 for mmusic@ietf.org; Mon, 16 Feb 2004 10:35:53 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Askm2-0004iR-00 for mmusic@ietf.org; Mon, 16 Feb 2004 10:35:06 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1GFZ5YG013107 for ; Mon, 16 Feb 2004 16:35:05 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 16:35:03 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJVNJ4K; Mon, 16 Feb 2004 16:35:02 +0100 Message-ID: <4030E299.4080304@ericsson.com> Date: Mon, 16 Feb 2004 16:32:41 +0100 X-Sybari-Trust: cac03ca3 c77f3eb6 8a146bd5 00000138 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: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2004 15:35:03.0146 (UTC) FILETIME=[720734A0:01C3F4A2] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Updated RTSP and NAT draft 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 Hi, Thomas and I have submitted a new version of the RTSP and NAT draft. Until it becomes available at IETF you can fetch it here: http://standards.ericsson.net/westerlund/draft-ietf-mmusic-rtsp-nat-02.txt The following changes in regards to the previous version has been done: - Added requirements section, per discussions during IETF 58. - Delegated the discussion on using ICE for RTSP to a separate draft. - Removed all the solutions proposal in regards protocol changing mechanism. There are still more required on this draft, especially in regards to ALGs. Input is very welcome. 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 17 10:38:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06054 for ; Tue, 17 Feb 2004 10:38: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 1At7Ia-0001lo-Hi for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 10:38:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFcCIk006709 for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 10:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7IW-0001je-7V for mmusic-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 10:38: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 KAA05994 for ; Tue, 17 Feb 2004 10:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7IT-00019j-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 10:38:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7HU-00015D-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 10:37:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7GV-0000z2-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 10:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7GW-00015N-1e; Tue, 17 Feb 2004 10:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7G0-0000zj-GF for mmusic@optimus.ietf.org; Tue, 17 Feb 2004 10:35:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05531; Tue, 17 Feb 2004 10:35:28 -0500 (EST) Message-Id: <200402171535.KAA05531@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Feb 2004 10:35:28 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol Offer Answer Examples Author(s) : A. Johnston, R. Sparks Filename : draft-ietf-mmusic-offer-answer-examples-02.txt Pages : 24 Date : 2004-2-17 This document gives examples of Session Description Protocol (SDP) offer answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examples-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-offer-answer-examples-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-offer-answer-examples-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17104003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-offer-answer-examples-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-offer-answer-examples-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17104003.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 17 13:24:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24692 for ; Tue, 17 Feb 2004 13:24: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 1At9tW-0005lM-MR for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 13:24:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIOUBl022151 for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 13:24:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9tW-0005lC-IL for mmusic-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:24:30 -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 NAA24573 for ; Tue, 17 Feb 2004 13:24:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9tU-0007Z1-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 13:24:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9sI-0007NU-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 13:23:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1At9r8-0007Ce-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 13:22:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At9r9-00068a-Jc for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 13:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9r6-0005OH-OC; Tue, 17 Feb 2004 13:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9qV-0005Cf-2d for mmusic@optimus.ietf.org; Tue, 17 Feb 2004 13:21: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 NAA24217 for ; Tue, 17 Feb 2004 13:21:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9qT-00076t-00 for mmusic@ietf.org; Tue, 17 Feb 2004 13:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9pP-0006x8-00 for mmusic@ietf.org; Tue, 17 Feb 2004 13:20:16 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1At9oK-0006ll-00 for mmusic@ietf.org; Tue, 17 Feb 2004 13:19:09 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HIJ2S06248; Tue, 17 Feb 2004 20:19:03 +0200 (EET) X-Scanned: Tue, 17 Feb 2004 20:18:59 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1HIIxW8013434; Tue, 17 Feb 2004 20:18:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00K1tHyT; Tue, 17 Feb 2004 20:18:57 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HIIl729085; Tue, 17 Feb 2004 20:18:48 +0200 (EET) Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 20:18:40 +0200 Received: from agni.research.nokia.com (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA27120; Tue, 17 Feb 2004 20:18:50 +0200 (EET) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i1HIIbxk032738; Tue, 17 Feb 2004 20:18:37 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i1HIIa8t032737; Tue, 17 Feb 2004 20:18:36 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: mmusic@ietf.org Cc: alan.johnston@mci.com, rsparks@dynamicsoft.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.txt X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <200402171535.KAA05531@ietf.org> (Internet-Drafts@ietf.org's message of "Tue, 17 Feb 2004 10:35:28 -0500") References: <200402171535.KAA05531@ietf.org> Date: Tue, 17 Feb 2004 20:18:36 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Feb 2004 18:18:40.0027 (UTC) FILETIME=[77C21EB0:01C3F582] 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 autolearn=no version=2.60 Hello all, Just a few comments on offer-answer-examples-02. Based on experience during the last SIPit, it would be nice to have a call hold flow where a=recvonly would be a session-level attribute, e.g., 3.1 [Answer] could have a=recvonly at session level. Also, the RFC 3264 does not require that the rejected media lines have same media type in the answer as they had in offer. So, it could be useful to include such an O/A exchange in the document, for example: This scenario shows Alice sending an offer describing audio, video and text session. Bob does not support video or text, so he rejects both video and text sessions. Bob does not regocnize the text media at all, so he returns a generic media line instead on its place. Alice and Bob may send only AMR audio. [Offer] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 96 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:96 AMR/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=text 36626 RTP/AVP 99 100 a=rtpmap:99 T140/1000 a=rtpmap:100 red/1000 a=fmtp:100 99 [Answer] v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49174 RTP/AVP 96 a=rtpmap:96 AMR/8000 m=video 0 RTP/AVP 13 m=unknown 0 UDP rejected There are some SDP syntax errors and nits, too: - iLBC codec misses the clock rate a=rtpmap:97 iLBC => a=rtpmap:97 iLBC/8000 - telephone-event codec (not telephone-event*s*) sometimes misses clock rate a=rtpmap:98 telephone-event => a=rtpmap:98 telephone-event/8000 a=rtpmap:98 telephone-events => a=rtpmap:98 telephone-event/8000 - in the 3.2 [Second-Offer], there is an extra empty line - in the 4.1 [Second-Answer], the c= line in first m=audio is after a= line. - in the 4.3 [Answer], there is 97 on media line but rtpmap describes PCMU - it should be a=rtpmap:97 iLBC/8000 --Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 17 15:20:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02553 for ; Tue, 17 Feb 2004 15:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBhc-0001gS-04 for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 15:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKKJvG006466 for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 15:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBhb-0001gD-Nt for mmusic-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:20:19 -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 PAA02512 for ; Tue, 17 Feb 2004 15:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBha-00012p-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 15:20:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBgg-00010W-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 15:19:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBgL-0000xZ-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 15: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 1AtBgL-0001KZ-Cz; Tue, 17 Feb 2004 15: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 1AtBfr-0001D5-KT for mmusic@optimus.ietf.org; Tue, 17 Feb 2004 15:18: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 PAA02345 for ; Tue, 17 Feb 2004 15:18:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBfq-0000x5-00 for mmusic@ietf.org; Tue, 17 Feb 2004 15:18:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBf5-0000t9-00 for mmusic@ietf.org; Tue, 17 Feb 2004 15:17:44 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AtBeI-0000la-00 for mmusic@ietf.org; Tue, 17 Feb 2004 15:16:54 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HT8005G4VXZ1N@firewall.mci.com> for mmusic@ietf.org; Tue, 17 Feb 2004 20:08:36 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HT800301VW114@pmismtp02.mcilink.com>; Tue, 17 Feb 2004 20:08:30 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.96.104]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HT8002E2VXCLZ@pmismtp02.mcilink.com>; Tue, 17 Feb 2004 20:08:02 +0000 (GMT) Date: Tue, 17 Feb 2004 14:07:49 -0600 From: Alan Johnston Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.txt In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: Pekka Pessi , mmusic@ietf.org Cc: rsparks@dynamicsoft.com Message-id: <5.2.1.1.0.20040217135857.02674da0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <200402171535.KAA05531@ietf.org> <200402171535.KAA05531@ietf.org> 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 Hi Pekka, Thanks very much for going over the document. We'll fix the nits you list . See some comments below. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 08:18 PM 2/17/2004 +0200, Pekka Pessi wrote: >Hello all, > >Just a few comments on offer-answer-examples-02. > >Based on experience during the last SIPit, it would be nice to >have a call hold flow where a=recvonly would be a session-level >attribute, e.g., 3.1 [Answer] could have a=recvonly at session >level. Is this what you have in mind as an answer? v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 placeholder.biloxi.example.com a=sendonly t=0 0 m=audio 49172 RTP/AVP 97 a=rtpmap:97 iLBC >Also, the RFC 3264 does not require that the rejected media lines >have same media type in the answer as they had in offer. So, it >could be useful to include such an O/A exchange in the document, >for example: > > This scenario shows Alice sending an offer describing audio, > video and text session. Bob does not support video or text, so > he rejects both video and text sessions. Bob does not regocnize > the text media at all, so he returns a generic media line > instead on its place. Alice and Bob may send only AMR audio. > > [Offer] > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s= > c=IN IP4 host.atlanta.example.com > t=0 0 > m=audio 49170 RTP/AVP 0 8 96 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:96 AMR/8000 > m=video 51372 RTP/AVP 31 32 > a=rtpmap:31 H261/90000 > a=rtpmap:32 MPV/90000 > m=text 36626 RTP/AVP 99 100 > a=rtpmap:99 T140/1000 > a=rtpmap:100 red/1000 > a=fmtp:100 99 > > [Answer] > > v=0 > o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com > s= > c=IN IP4 host.biloxi.example.com > t=0 0 > m=audio 49174 RTP/AVP 96 > a=rtpmap:96 AMR/8000 > m=video 0 RTP/AVP 13 > m=unknown 0 UDP rejected OK. >There are some SDP syntax errors and nits, too: > >- iLBC codec misses the clock rate > a=rtpmap:97 iLBC => a=rtpmap:97 iLBC/8000 >- telephone-event codec (not telephone-event*s*) sometimes misses > clock rate > a=rtpmap:98 telephone-event => a=rtpmap:98 telephone-event/8000 > a=rtpmap:98 telephone-events => a=rtpmap:98 telephone-event/8000 >- in the 3.2 [Second-Offer], there is an extra empty line >- in the 4.1 [Second-Answer], the c= line in first m=audio is > after a= line. >- in the 4.3 [Answer], there is 97 on media line but rtpmap > describes PCMU - it should be a=rtpmap:97 iLBC/8000 OK >--Pekka > >_______________________________________________ >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 Feb 17 15:52:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04660 for ; Tue, 17 Feb 2004 15:52: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 1AtCCe-00061S-Cd for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 15:52:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKqOdN023149 for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 15:52:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCCe-00061I-8n for mmusic-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:52:24 -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 PAA04653 for ; Tue, 17 Feb 2004 15:52:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCCc-0003uF-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 15:52:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCBf-0003rD-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 15:51:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtCBL-0003oG-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 15:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCBL-0005og-Fx; Tue, 17 Feb 2004 15:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCAk-0005ma-5a for mmusic@optimus.ietf.org; Tue, 17 Feb 2004 15:50: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 PAA04586 for ; Tue, 17 Feb 2004 15:50:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCAi-0003mr-00 for mmusic@ietf.org; Tue, 17 Feb 2004 15:50:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC9m-0003in-00 for mmusic@ietf.org; Tue, 17 Feb 2004 15:49:26 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtC97-0003de-00 for mmusic@ietf.org; Tue, 17 Feb 2004 15:48:45 -0500 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1HKmCNr005711; Tue, 17 Feb 2004 15:48:15 -0500 (EST) Message-ID: <40327E03.7060607@dynamicsoft.com> Date: Tue, 17 Feb 2004 15:48:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: Pekka Pessi , mmusic@ietf.org, rsparks@dynamicsoft.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.txt References: <200402171535.KAA05531@ietf.org> <200402171535.KAA05531@ietf.org> <5.2.1.1.0.20040217135857.02674da0@pop.mcit.com> In-Reply-To: <5.2.1.1.0.20040217135857.02674da0@pop.mcit.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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Alan Johnston wrote: >> Also, the RFC 3264 does not require that the rejected media lines >> have same media type in the answer as they had in offer. I disagree. I think its implied by: 6.1 Unicast Streams If a stream is offered with a unicast address, the answer for that stream MUST contain a unicast address. The media type of the stream in the answer MUST match that of the offer. The idea with rejection is that you set the port to zero, but otherwise it is a valid answer. So, it >> could be useful to include such an O/A exchange in the document, >> for example: >> >> This scenario shows Alice sending an offer describing audio, >> video and text session. Bob does not support video or text, so >> he rejects both video and text sessions. Bob does not regocnize >> the text media at all, so he returns a generic media line >> instead on its place. Alice and Bob may send only AMR audio. There is no need to even understand the media type in order to reject it - you could just copy the string from offer to answer. >> >> [Offer] >> >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> m=audio 49170 RTP/AVP 0 8 96 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:96 AMR/8000 >> m=video 51372 RTP/AVP 31 32 >> a=rtpmap:31 H261/90000 >> a=rtpmap:32 MPV/90000 >> m=text 36626 RTP/AVP 99 100 >> a=rtpmap:99 T140/1000 >> a=rtpmap:100 red/1000 >> a=fmtp:100 99 >> >> [Answer] >> >> v=0 >> o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com >> s= >> c=IN IP4 host.biloxi.example.com >> t=0 0 >> m=audio 49174 RTP/AVP 96 >> a=rtpmap:96 AMR/8000 >> m=video 0 RTP/AVP 13 >> m=unknown 0 UDP rejected > > > OK. Per above, I think this is wrong. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 17 16:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07834 for ; Tue, 17 Feb 2004 16:40:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCx8-0002d0-CY for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 16:40:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HLeQYL010098 for mmusic-archive@odin.ietf.org; Tue, 17 Feb 2004 16:40:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCx8-0002cn-75 for mmusic-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 16:40: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 QAA07776 for ; Tue, 17 Feb 2004 16:40:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCx6-0000F7-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 16:40:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCwB-0000Ba-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 16:39:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtCvl-00008Q-00 for mmusic-web-archive@ietf.org; Tue, 17 Feb 2004 16:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCvl-0002NJ-7Z; Tue, 17 Feb 2004 16:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCvj-0002Mf-Iq for mmusic@optimus.ietf.org; Tue, 17 Feb 2004 16:38:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07679; Tue, 17 Feb 2004 16:38:56 -0500 (EST) Message-Id: <200402172138.QAA07679@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Feb 2004 16:38:56 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-01.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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-01.txt Pages : 37 Date : 2004-2-17 This document describes a methodology for Network Address Translator (NAT) traversal for multimedia session signaling protocols, such as the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE is not a new protocol, but rather makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP). ICE works through the mutual cooperation of both endpoints in a session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-ice-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-ice-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17165817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17165817.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 18 05:14:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04923 for ; Wed, 18 Feb 2004 05:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOiF-0000Bd-AA for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 05:13:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IADpQG000716 for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 05:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOiE-0000BS-2w for mmusic-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 05:13: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 FAA04902 for ; Wed, 18 Feb 2004 05:13:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOiA-0003bi-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 05:13:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOhA-0003Xo-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 05:12:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtOgV-0003Uv-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 05:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOgU-0008Rp-0R; Wed, 18 Feb 2004 05:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOgH-0008Qw-54 for mmusic@optimus.ietf.org; Wed, 18 Feb 2004 05:11:49 -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 FAA04869 for ; Wed, 18 Feb 2004 05:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOgD-0003UP-00 for mmusic@ietf.org; Wed, 18 Feb 2004 05:11:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOfL-0003Rv-00 for mmusic@ietf.org; Wed, 18 Feb 2004 05:10:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AtOet-0003Oi-00 for mmusic@ietf.org; Wed, 18 Feb 2004 05:10:23 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IAAHK24741; Wed, 18 Feb 2004 12:10:18 +0200 (EET) X-Scanned: Wed, 18 Feb 2004 12:10:05 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1IAA5CU024101; Wed, 18 Feb 2004 12:10:05 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00ygFufN; Wed, 18 Feb 2004 12:10:04 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IA9xO10854; Wed, 18 Feb 2004 12:09:59 +0200 (EET) Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 12:09:26 +0200 Received: from agni.research.nokia.com (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA27166; Wed, 18 Feb 2004 12:09:37 +0200 (EET) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i1IA9Nxk032314; Wed, 18 Feb 2004 12:09:23 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i1IA9Mas032313; Wed, 18 Feb 2004 12:09:22 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Cc: Alan Johnston , Pekka Pessi , mmusic@ietf.org, rsparks@dynamicsoft.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.txt X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <40327E03.7060607@dynamicsoft.com> (Jonathan Rosenberg's message of "Tue, 17 Feb 2004 15:48:03 -0500") References: <200402171535.KAA05531@ietf.org> <200402171535.KAA05531@ietf.org> <5.2.1.1.0.20040217135857.02674da0@pop.mcit.com> <40327E03.7060607@dynamicsoft.com> Date: Wed, 18 Feb 2004 12:09:22 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 18 Feb 2004 10:09:26.0412 (UTC) FILETIME=[4A0DACC0:01C3F607] 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 Jonathan Rosenberg writes: >I disagree. I think its implied by: >6.1 Unicast Streams > If a stream is offered with a unicast address, the answer for that > stream MUST contain a unicast address. The media type of the stream > in the answer MUST match that of the offer. >The idea with rejection is that you set the port to zero, but otherwise it >is a valid answer. You are much better O-A lawyer than I. I interpreted this regarding accepted streams. So, this is not a valid answer either: v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= t=0 0 m=audio 49174 RTP/AVP 96 c=IN IP4 host.biloxi.example.com a=rtpmap:96 AMR/8000 m=video 0 RTP/AVP 13 m=text 0 RTP/AVP 13 I guess not, because having c= line for each media is lower-case must in RFC2327, MUST in sdp-new. --Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 18 16:21:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21885 for ; Wed, 18 Feb 2004 16:21:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ84-0007LI-Qy for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 16:21:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILLCOT028220 for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 16:21:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ84-0007L5-J8 for mmusic-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 16:21: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 QAA21759 for ; Wed, 18 Feb 2004 16:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ82-0001B0-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 16:21:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZ6Y-0000uN-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 16:19:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ4y-0000dx-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 16:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ4y-0006gF-OB; Wed, 18 Feb 2004 16:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ4C-0006bZ-7t for mmusic@optimus.ietf.org; Wed, 18 Feb 2004 16:17: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 QAA21208 for ; Wed, 18 Feb 2004 16:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ4A-0000Ve-00 for mmusic@ietf.org; Wed, 18 Feb 2004 16:17:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZ2o-0000IF-00 for mmusic@ietf.org; Wed, 18 Feb 2004 16:15:46 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtZ1q-00005s-00 for mmusic@ietf.org; Wed, 18 Feb 2004 16:14:46 -0500 Received: from dynamicsoft.com ([63.113.46.51]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1ILEMNr006286; Wed, 18 Feb 2004 16:14:22 -0500 (EST) Message-ID: <4033D5A3.5070201@dynamicsoft.com> Date: Wed, 18 Feb 2004 16:14:11 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: Alan Johnston , mmusic@ietf.org, rsparks@dynamicsoft.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.txt References: <200402171535.KAA05531@ietf.org> <200402171535.KAA05531@ietf.org> <5.2.1.1.0.20040217135857.02674da0@pop.mcit.com> <40327E03.7060607@dynamicsoft.com> In-Reply-To: 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Pessi wrote: > Jonathan Rosenberg writes: > >>I disagree. I think its implied by: > > >>6.1 Unicast Streams > > >> If a stream is offered with a unicast address, the answer for that >> stream MUST contain a unicast address. The media type of the stream >> in the answer MUST match that of the offer. > > >>The idea with rejection is that you set the port to zero, but otherwise it >>is a valid answer. > > > You are much better O-A lawyer than I. I interpreted this > regarding accepted streams. I can understand that read of it; however the intent was certainly not that you can put things like "unknown" in the media type. So, this is not a valid answer either: > > v=0 > o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com > s= > t=0 0 > m=audio 49174 RTP/AVP 96 > c=IN IP4 host.biloxi.example.com > a=rtpmap:96 AMR/8000 > m=video 0 RTP/AVP 13 > m=text 0 RTP/AVP 13 > > I guess not, because having c= line for each media is lower-case > must in RFC2327, MUST in sdp-new. Right. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 19 06:00:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13820 for ; Thu, 19 Feb 2004 06:00:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtluZ-0006ae-Vy for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 06:00:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JB07ax025314 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 06:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtluV-0006Zk-FP for mmusic-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 06:00: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 FAA13757 for ; Thu, 19 Feb 2004 05:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtluR-0005ez-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 05:59:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtltS-0005aw-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 05:58:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtlsX-0005XX-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 05:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtlsX-0006Si-9d; Thu, 19 Feb 2004 05: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 1Atlri-0006QW-Fx for mmusic@optimus.ietf.org; Thu, 19 Feb 2004 05:57: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 FAA13679 for ; Thu, 19 Feb 2004 05:57:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atlre-0005U6-00 for mmusic@ietf.org; Thu, 19 Feb 2004 05:57:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atlqq-0005R3-00 for mmusic@ietf.org; Thu, 19 Feb 2004 05:56:17 -0500 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 1Atlq3-0005Mq-00 for mmusic@ietf.org; Thu, 19 Feb 2004 05:55:27 -0500 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.10/8.12.10) with ESMTP id i1JAtSW0039487 for ; Thu, 19 Feb 2004 02:55:28 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.10/8.12.9/Submit) id i1JAtR9C039484; Thu, 19 Feb 2004 02:55:27 -0800 (PST) (envelope-from rsf) Message-Id: <6.0.1.1.1.20040219025209.02719e40@localhost> X-Sender: rsf@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 19 Feb 2004 02:53:17 -0800 To: mmusic@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.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 In four places, "draft-ietf-mmusic-rfc2326bis-06.txt" contains the string "interleave=" instead of "interleaved=" Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 19 07:29:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16195 for ; Thu, 19 Feb 2004 07:29: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 1AtnIe-0005Di-2J for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 07:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JCT4Tb020060 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 07:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnId-0005DT-PE for mmusic-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 07:29: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 HAA16186 for ; Thu, 19 Feb 2004 07:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnId-0001oK-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnHe-0001mn-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:28:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtnGh-0001lO-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnGf-00056D-Iv; Thu, 19 Feb 2004 07: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 1AtnFn-0004yw-Em for mmusic@optimus.ietf.org; Thu, 19 Feb 2004 07:26: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 HAA16155 for ; Thu, 19 Feb 2004 07:26:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnFm-0001k4-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:26:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnEv-0001iQ-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:25:14 -0500 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 1AtnEi-0001fq-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:25:00 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: R: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt Date: Thu, 19 Feb 2004 13:26:10 +0100 Message-ID: <9F1223587A755D47805AECAB7ECAF5D908C831@swing.cefriel.it> Thread-Topic: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt thread-index: AcP214feHdKBt5f0Sb6WLWwQSeuUbgAC7LDg From: "Enrico Balatti" To: 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section B.1.1 AVP contains the string "dest_addresses" Instead of "dest addr" Enrico =20 -----Messaggio originale----- Da: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] Per conto di = Ross Finlayson Inviato: gioved=EC 19 febbraio 2004 11.53 A: mmusic@ietf.org Oggetto: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt In four places, "draft-ietf-mmusic-rfc2326bis-06.txt" contains the = string "interleave=3D" instead of "interleaved=3D" Ross. _______________________________________________ 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 Feb 19 07:37:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16339 for ; Thu, 19 Feb 2004 07:37:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnQW-0005sx-2c for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 07:37:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JCbBQC022622 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 07:37:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnQV-0005sn-GY for mmusic-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 07:37:11 -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 HAA16336 for ; Thu, 19 Feb 2004 07:37:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnQU-00025Z-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:37:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnPU-00023Z-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:36:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtnPN-00021m-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnPM-0005fM-IW; Thu, 19 Feb 2004 07:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnOT-0005ed-KR for mmusic@optimus.ietf.org; Thu, 19 Feb 2004 07:35: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 HAA16305 for ; Thu, 19 Feb 2004 07:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnOS-00020q-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnNW-0001yv-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:34:07 -0500 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 1AtnMw-0001vK-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:33:31 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: R: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt Date: Thu, 19 Feb 2004 13:34:38 +0100 Message-ID: <9F1223587A755D47805AECAB7ECAF5D908C835@swing.cefriel.it> Thread-Topic: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt thread-index: AcP214feHdKBt5f0Sb6WLWwQSeuUbgAC7LDgAABKeeA= From: "Enrico Balatti" To: 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >Section B.1.1 AVP contains the string > >"dest_addresses" > >Instead of > >"dest addr" > >Enrico =20 "dest_addr" and not "dest addr" Enrico -----Messaggio originale----- Da: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] Per conto di = Ross Finlayson Inviato: gioved=EC 19 febbraio 2004 11.53 A: mmusic@ietf.org Oggetto: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt In four places, "draft-ietf-mmusic-rfc2326bis-06.txt" contains the = string "interleave=3D" instead of "interleaved=3D" Ross. _______________________________________________ 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 Feb 19 07:42:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16487 for ; Thu, 19 Feb 2004 07:42:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnVI-0006Pk-Bh for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 07:42:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JCg8D0024650 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 07:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnVH-0006PV-Uq for mmusic-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 07:42: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 HAA16484 for ; Thu, 19 Feb 2004 07:42:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnVH-0002IO-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnUK-0002GW-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:41:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtnUE-0002En-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 07:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnUD-0006EI-Pr; Thu, 19 Feb 2004 07:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnTK-0006Ck-Sp for mmusic@optimus.ietf.org; Thu, 19 Feb 2004 07:40: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 HAA16409 for ; Thu, 19 Feb 2004 07:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnTK-0002Dl-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:40:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnSO-0002BF-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:39:08 -0500 Received: from artemis.pop-rn.rnp.br ([200.137.0.55]) by ietf-mx with esmtp (Exim 4.12) id 1AtnRY-00029B-00 for mmusic@ietf.org; Thu, 19 Feb 2004 07:38:16 -0500 Received: from artemis.pop-rn.rnp.br (localhost.localdomain [127.0.0.1]) by artemis.pop-rn.rnp.br (8.12.8/8.12.5) with ESMTP id i1JCcFpp022342 for ; Thu, 19 Feb 2004 09:38:15 -0300 From: video conferencia Received: (from apache@localhost) by artemis.pop-rn.rnp.br (8.12.8/8.12.8/Submit) id i1JCcF6X022340; Thu, 19 Feb 2004 09:38:15 -0300 X-Authentication-Warning: artemis.pop-rn.rnp.br: apache set sender to videoconf@pop-rn.rnp.br using -f Received: from 200.137.0.46 (SquirrelMail authenticated user videoconf) by artemis.pop-rn.rnp.br with HTTP; Thu, 19 Feb 2004 09:38:15 -0300 (BRT) Message-ID: <1544.200.137.0.46.1077194295.squirrel@artemis.pop-rn.rnp.br> Date: Thu, 19 Feb 2004 09:38:15 -0300 (BRT) To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by artemis.pop-rn.rnp.br id i1JCcFpp022342 Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] H.323 and SIP tools 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hello everybody I=B4m looking for a videoconference tool that works both in H.323 and SIP. More precisely, it should "switch" between these two standards "on-line". When the tool receives some message, it should check this trying to identify if this is a H.323 or a SIP message, and, automaticaly, it would reply using the rigth message (H.323 or SIP). I hope i=B4ve been understood Thank you very much Daniel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 19 13:05:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00965 for ; Thu, 19 Feb 2004 13:05: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 1AtsY8-0008GR-Gj for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 13:05:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JI5Ovs031766 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 13:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsY8-0008GH-CV for mmusic-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 13:05:24 -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 NAA00937 for ; Thu, 19 Feb 2004 13:05:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsY6-0005W7-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 13:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsXM-0005SO-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 13:04:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtsWp-0005Nj-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 13:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsWo-00085R-1I; Thu, 19 Feb 2004 13:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsWa-00081W-5T for mmusic@optimus.ietf.org; Thu, 19 Feb 2004 13:03:48 -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 NAA00829 for ; Thu, 19 Feb 2004 13:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsWY-0005Lm-00 for mmusic@ietf.org; Thu, 19 Feb 2004 13:03:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsVk-0005Dm-00 for mmusic@ietf.org; Thu, 19 Feb 2004 13:02:57 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AtsUe-00050r-00 for mmusic@ietf.org; Thu, 19 Feb 2004 13:01:49 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1JHxv4U006459; Thu, 19 Feb 2004 19:00:02 +0100 (CET) From: "Gunnar Hellstrom" To: "video conferencia" , Subject: RE: [MMUSIC] H.323 and SIP tools Date: Thu, 19 Feb 2004 19:01:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <1544.200.137.0.46.1077194295.squirrel@artemis.pop-rn.rnp.br> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i1JHxv4U006459 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Daniel, I have it. Please contact me. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of video conferencia Sent: Thursday, February 19, 2004 1:38 PM To: mmusic@ietf.org Subject: [MMUSIC] H.323 and SIP tools Hello everybody I=B4m looking for a videoconference tool that works both in H.323 and SIP. More precisely, it should "switch" between these two standards "on-line". When the tool receives some message, it should check this trying to identify if this is a H.323 or a SIP message, and, automaticaly, it would reply using the rigth message (H.323 or SIP). I hope i=B4ve been understood Thank you very much Daniel _______________________________________________ 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 Feb 19 16:25:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21933 for ; Thu, 19 Feb 2004 16:25:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atvet-0002l2-D4 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 16:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JLOZ3N010594 for mmusic-archive@odin.ietf.org; Thu, 19 Feb 2004 16:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atvet-0002kn-7l for mmusic-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 16:24:35 -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 QAA21329 for ; Thu, 19 Feb 2004 16:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atver-0001CI-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 16:24:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atvdx-00018S-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 16:23:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtvdO-00014N-00 for mmusic-web-archive@ietf.org; Thu, 19 Feb 2004 16:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvdN-0002Z4-78; Thu, 19 Feb 2004 16:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atvd0-0002XF-S5 for mmusic@optimus.ietf.org; Thu, 19 Feb 2004 16:22: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 QAA18912 for ; Thu, 19 Feb 2004 16:22:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atvcy-00013l-00 for mmusic@ietf.org; Thu, 19 Feb 2004 16:22:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtvcA-0000zn-00 for mmusic@ietf.org; Thu, 19 Feb 2004 16:21:47 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Atvba-0000uO-00 for mmusic@ietf.org; Thu, 19 Feb 2004 16:21:10 -0500 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1JLKeYL026554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Feb 2004 16:20:41 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.10/8.12.9) with ESMTP id i1JLKafv078218; Thu, 19 Feb 2004 16:20:36 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.10/8.12.10/Submit) id i1JLKWg6078215; Thu, 19 Feb 2004 16:20:32 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16437.10400.78138.326391@cnr.cs.columbia.edu> Date: Thu, 19 Feb 2004 16:20:32 -0500 To: mmusic@ietf.org Cc: David Yon , hgs@cs.columbia.edu X-Mailer: VM 7.17 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] comedia and TLS 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 was reading the comedia draft, and it occured to me that the TLS section is quite underspecified. Specifically, what certificates should each party to the connection present? And is bidirectional authentication required, or just server-only authentication? TLS without certificates is proof against a passive snooper, but does nothing to protect against a man-in-the-middle attack -- all the same problems that have been discussed with TCP arise with TLS as well, rather defeating the purpose of using a security protocol. I think that with certificates, though, comedia-over-TLS can solve most of the problems that have bedeviled comedia-over-TCP. However, a number of tricky issues arise. First of all, unlike for https or even sips, many comedia end systems will be small devices. Thus, they won't be able to afford to have host certificates signed by a certificate authority. (thawte.com provides certificates with an RFC822 subject for free, but I don't know of anyone who provides one with a hostname or IP address subject.) Second, many end systems have dynamic IP addresses and hostnames, because they're (e.g.) DHCP-configured. Furthermore, since comedia is designed to work through NATs, any hostname or IP address presented in a certificate might bear no relationship to the hostname or IP address to which the active party connected, or from which the passive party received its connection. Third, the device which is participating in the comedia connection might not be the same as the device which is performing the signalling which carries the comedia SDP -- consider, for example, SIP third-party call control. So, picking a relevant certificate for TLS comedia -- or worse, trying to figure out if your counterparty's certificate is legitimate -- is far from trivial. Clearly, the comedia draft needs to specify this. So, here're my suggestions. First of all, consider the case where an attacker can see the SDP, but can't modify it. (Attackers who can modify SDP can perform all sorts of interesting attacks, both on comedia and on RTP or UDP media types, of course; a big part of session establishment security needs to be the protection of SDP.) I propose that the SDP messages carry the certificate fingerprints of the certificates each side will present. (Certificate fingerprints -- MD5 or SHA-1 hashes of a public key -- are a well-known concept, presented by, among other things, web browsers' certificate managers and the "openssl x509 -fingerprint" command.) This will be a new media-level attribute, a=cert-fingerprint. TLS comedia connections will always request client certificates as well as server certificates, so both sides mutually authenticate, and they'll tear down the TLS connections if the fingerprints don't match. Assuming that the integrity of SDP is indeed secure, this is entirely sufficient to prevent man-in-the-middle attacks on comedia, even if both sides are using self-signed keys. (It also provides connection association, corrolating TLS streams to SDP descriptions, for free.) Of course, you can't always be sure of the integrity of SDP -- even if you're using, e.g., sips for every SIP hop, a proxy server might be compromised. Therefore, endpoints should also provide CA-signed keys "if available", or else certificates which are verifiable through a mechanism such as the one Cullen Jennings describes in draft-jennings-sipping-certs. I'm still somewhat uncertain what the certificate subject should be specified as being in these cases, though; it's probably protocol-dependent, and what makes sense for SIP doesn't make sense for RTSP or SAP. Do people have thoughts on all of this? Does it seem sensible, or is there anything I've overlooked or need to explain more closely? I'm willing to write some text for the comedia draft specifying all of this, if people are interested. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 20 08:45:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21967 for ; Fri, 20 Feb 2004 08:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAxf-0002nY-U9 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 08:45:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KDixPV010753 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 08:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAxf-0002nL-Ll for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 08:44: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 IAA21953 for ; Fri, 20 Feb 2004 08:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuAxe-0000yr-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 08:44:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuAwk-0000vH-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 08:44:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuAvm-0000ru-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 08: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 1AuAvl-0002ZG-Bz; Fri, 20 Feb 2004 08: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 1AuAvj-0002Yp-UY for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 08:42: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 IAA21898 for ; Fri, 20 Feb 2004 08:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuAvi-0000rF-00 for mmusic@ietf.org; Fri, 20 Feb 2004 08:42:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuAuo-0000oW-00 for mmusic@ietf.org; Fri, 20 Feb 2004 08:42:02 -0500 Received: from [209.172.119.195] (helo=scha26.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 1AuAuY-0000l0-00 for mmusic@ietf.org; Fri, 20 Feb 2004 08:41:46 -0500 Received: from scha25.neomagic.com (scha25.neomagic.com [192.168.51.25]) by scha26.neomagic.com (8.12.5/8.12.5) with ESMTP id i1KEZqga016986 for ; Fri, 20 Feb 2004 06:35:52 -0800 Received: from neomagic.com ([192.168.31.247]) by scha25.neomagic.com (8.12.5/8.12.5) with ESMTP id i1KEN9Vb019861 for ; Fri, 20 Feb 2004 06:23:10 -0800 Message-ID: <403611D8.6090803@neomagic.com> Date: Fri, 20 Feb 2004 19:25:36 +0530 From: Mukul Purohit Organization: NeoMagic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org References: <9F1223587A755D47805AECAB7ECAF5D908C835@swing.cefriel.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5) Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Minor grammer bug in draft-ietf-mmusic-rfc2326bis-06.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 Section 17.2.3 needquote-url = url //That contains ; or , RTP-Info Header also contains "=" as a delimiter hence, NeedQuote-URL should also mention "=" as it is part of the definition of URL in RFC2396. needquote-url = url //That contains ; or , or = mukul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 20 09:48:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24316 for ; Fri, 20 Feb 2004 09:48:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBwf-0007Eo-Hv for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 09:48:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KEm19G027816 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBwf-0007EZ-BC for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 09:48: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 JAA24292 for ; Fri, 20 Feb 2004 09:47:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBwd-0005EZ-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 09:47:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBvh-0005BI-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 09:47:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuBuj-00058H-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 09:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBuj-000777-FD; Fri, 20 Feb 2004 09:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBuf-00076i-5p for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 09:45: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 JAA24232 for ; Fri, 20 Feb 2004 09:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBud-00057J-00 for mmusic@ietf.org; Fri, 20 Feb 2004 09:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBth-00054m-00 for mmusic@ietf.org; Fri, 20 Feb 2004 09:44:58 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AuBt0-00052J-00 for mmusic@ietf.org; Fri, 20 Feb 2004 09:44:14 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1KEiDYG025337 for ; Fri, 20 Feb 2004 15:44:14 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 15:44:13 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FGALTQLH; Fri, 20 Feb 2004 15:44:13 +0100 Message-ID: <40361CA8.4020804@ericsson.com> Date: Fri, 20 Feb 2004 15:41:44 +0100 X-Sybari-Trust: 007c1fd8 c77f3eb6 1886a979 00000138 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: Mukul Purohit CC: mmusic@ietf.org Subject: Re: [MMUSIC] Minor grammer bug in draft-ietf-mmusic-rfc2326bis-06.txt References: NeoMagic <403611D8.6090803@neomagic.com> In-Reply-To: <403611D8.6090803@neomagic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2004 14:44:13.0958 (UTC) FILETIME=[02390A60:01C3F7C0] 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mukul, Thanks for reviewing. However I don't think that a SAFE URL need to exclude "=". The reason is that the URL in RTP-Info header starts after the "url=" part and must end with a ";". Thus the exclusion of "," is actually not needed in the RTP-Info usage, unless someone makes a syntax violation. However as also using this as a common delimiter I think it is prudent to include it also in the exception. Cheers Magnus Mukul Purohit wrote: > Section 17.2.3 > needquote-url = url //That contains ; or , > > RTP-Info Header also contains "=" as a delimiter hence, > NeedQuote-URL should also mention "=" as it is part of the definition of > > URL in RFC2396. > > needquote-url = url //That contains ; or , or = > > mukul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 20 13:15:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04952 for ; Fri, 20 Feb 2004 13:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFB2-0008Ry-SY for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 13:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIF4ZG032476 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 13:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFB2-0008Rj-ND for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:15: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 NAA04919 for ; Fri, 20 Feb 2004 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFB0-0004xR-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:15:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFA3-0004ua-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:14:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuF94-0004r8-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuF93-0008JW-3Q; Fri, 20 Feb 2004 13: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 1AuF88-0008H9-Ar for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 13:12: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 NAA04794 for ; Fri, 20 Feb 2004 13:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuF86-0004mz-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuF7A-0004jV-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:11:04 -0500 Received: from [66.192.6.226] (helo=pope.teraglobal.com) by ietf-mx with esmtp (Exim 4.12) id 1AuF6G-0004dz-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:10:08 -0500 Received: from WXPvhegde ([66.192.6.37]) by pope.teraglobal.com (Netscape Messaging Server 4.15) with SMTP id HTEAX600.AL2 for ; Fri, 20 Feb 2004 10:19:54 -0800 From: "Veda Hegde" To: Date: Fri, 20 Feb 2004 10:09:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] bandwidth parameter in offer/answer 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 Hi, Based 3264, ofererer and answerer can include a bandwidth parameter to indicate the receive bandwidth. Both offerer and answerer should not send more than what is specified in the bandwith parameter. 2327 says that b=AS:... is the maximum bandwidth an application can use. Can answerer include a bandwidth value that is greater than what is offered if answerer can receive more than what the offerer can receive? Thanks, Veda _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 20 13:34:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05582 for ; Fri, 20 Feb 2004 13:34:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFTX-0001hv-Sj for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 13:34:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIYBIY006557 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 13:34:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFTX-0001hg-NM for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:34:11 -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 NAA05577 for ; Fri, 20 Feb 2004 13:34:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFTV-0006CA-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:34:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFSb-000698-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:33:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFSN-00065c-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFSO-0001cG-NR; Fri, 20 Feb 2004 13:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFRX-0001Zb-Hs for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 13:32: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 NAA05528 for ; Fri, 20 Feb 2004 13:32:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFRV-00064y-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFQc-00062U-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:31:10 -0500 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1AuFQ6-0005zW-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:30:38 -0500 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i1KIUbVf022643 for ; Fri, 20 Feb 2004 10:30:37 -0800 (PST) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i1KIUaFU019735 for ; Fri, 20 Feb 2004 10:30:36 -0800 (PST) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HTEBEY00.SYC for ; Fri, 20 Feb 2004 10:30:34 -0800 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: mmusic@ietf.org From: "John Lazzaro" Date: Fri, 20 Feb 2004 10:30:33 -0800 X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: comedia and TLS 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 > Jonathan Lennox writes: > > [...] Do people have thoughts on all of this? Does it seem sensible, > or is there > anything I've overlooked or need to explain more closely? > > I'm willing to write some text for the comedia draft specifying all of > this, > if people are interested. Maybe we should consider splitting off TLS comedia functionality into its own I-D ... so that the deliberations on TLS security issues can be decoupled from getting basic TCP session support completed. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Feb 20 13:46:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06290 for ; Fri, 20 Feb 2004 13:46: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 1AuFf7-00037x-Ms for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 13:46:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIk9s7012015 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 13:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFf7-00037i-HH for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:46:09 -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 NAA06275 for ; Fri, 20 Feb 2004 13:46:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFf5-000790-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:46:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFe7-00074o-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:45:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFd7-00070z-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 13:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFd4-0002pk-1r; Fri, 20 Feb 2004 13:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFcI-0002gy-2i for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 13:43: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 NAA06172 for ; Fri, 20 Feb 2004 13:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFcF-0006xW-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:43:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFbR-0006uh-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:42:21 -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 1AuFb2-0006qD-00 for mmusic@ietf.org; Fri, 20 Feb 2004 13:41:57 -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 i1KIchZ21878 for ; Fri, 20 Feb 2004 13:38:43 -0500 Message-Id: <5.1.1.6.0.20040220133932.0332eec0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 20 Feb 2004 13:41:50 -0500 To: mmusic@ietf.org From: David Yon Subject: Re: [MMUSIC] Re: comedia and TLS In-Reply-To: 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 Given the length of time comedia has remained in limbo, and my limited availability to maintain it, I would favor a split as well. There are potentially a lot of issues raised by fleshing out TLS to include certificate validation information within SDP that have nothing to do with basic TCP. The only question I would have is whether I should pull all mention of TLS from the original comedia. At 01:30 PM 2/20/2004, John Lazzaro wrote: >>Jonathan Lennox writes: >> >>[...] Do people have thoughts on all of this? Does it seem sensible, or >>is there >>anything I've overlooked or need to explain more closely? >> >>I'm willing to write some text for the comedia draft specifying all of this, >>if people are interested. > >Maybe we should consider splitting off TLS comedia functionality into >its own I-D ... so that the deliberations on TLS security issues can be >decoupled from getting basic TCP session support completed. > >--- >John Lazzaro >http://www.cs.berkeley.edu/~lazzaro >lazzaro [at] cs [dot] berkeley [dot] edu >--- > > >_______________________________________________ >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 Fri Feb 20 14:30:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08311 for ; Fri, 20 Feb 2004 14:30:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGLt-0007zQ-Bz for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 14:30:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KJULsf030711 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 14:30:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGLt-0007zG-8Q for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 14:30: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 OAA08288 for ; Fri, 20 Feb 2004 14:30:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuGLp-0002Xv-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 14:30:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuGKx-0002Tz-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 14:29:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuGKZ-0002Ou-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 14:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGKa-0007ma-PL; Fri, 20 Feb 2004 14:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGJh-0007kw-6W for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 14:28: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 OAA08136 for ; Fri, 20 Feb 2004 14:28:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuGJe-0002M9-00 for mmusic@ietf.org; Fri, 20 Feb 2004 14:28:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuGIj-0002Hu-00 for mmusic@ietf.org; Fri, 20 Feb 2004 14:27:05 -0500 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1AuGHo-0002DH-00 for mmusic@ietf.org; Fri, 20 Feb 2004 14:26:08 -0500 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i1KJQ7Za024742 for ; Fri, 20 Feb 2004 11:26:07 -0800 (PST) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i1KJQ6FU022008 for ; Fri, 20 Feb 2004 11:26:06 -0800 (PST) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HTEDZD00.MXA for ; Fri, 20 Feb 2004 11:26:01 -0800 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <9DDAB2B6-63DA-11D8-BF38-00039372C384@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mmusic@ietf.org From: "John Lazzaro" Subject: Re: [MMUSIC] Re: comedia and TLS Date: Fri, 20 Feb 2004 11:26:00 -0800 X-Mailer: Apple Mail (2.612) 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > David Yon writes: > > Given the length of time comedia has remained in limbo, and my limited > availability to maintain it, I would favor a split as well. There are > potentially a lot of issues raised by fleshing out TLS to include > certificate validation information within SDP that have nothing to do > with basic TCP. > > The only question I would have is whether I should pull all mention of > TLS from the original comedia. I'm viewing the issue from the perspective of using the RTP over TCP framing defined in the contrans I-D: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing- contrans-00.txt to make RTP MIDI sessions that split a MIDI cable over a UDP RTP stream (for real-time commands) and a TCP RTP stream (for bulk-data commands). Any application that does this, and that needs security, needs it for both the UDP and TCP RTP MIDI streams -- thus, the simplest mechanism is to use SRTP for both the UDP and TCP flows, not to use SRTP for the UDP flow and TLS for the reliable flow. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Feb 22 01:28:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03349 for ; Sun, 22 Feb 2004 01:28:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aun6A-0000YL-I1 for mmusic-archive@odin.ietf.org; Sun, 22 Feb 2004 01:28:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M6SIcl002119 for mmusic-archive@odin.ietf.org; Sun, 22 Feb 2004 01:28:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aun6A-0000Y6-EC for mmusic-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 01:28: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 BAA03344 for ; Sun, 22 Feb 2004 01:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aun67-0002aV-00 for mmusic-web-archive@ietf.org; Sun, 22 Feb 2004 01:28:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aun59-0002Y7-00 for mmusic-web-archive@ietf.org; Sun, 22 Feb 2004 01:27:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aun4u-0002VO-00 for mmusic-web-archive@ietf.org; Sun, 22 Feb 2004 01:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aun4v-0000R2-9i; Sun, 22 Feb 2004 01: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 1Aun4A-0000Ql-Pt for mmusic@optimus.ietf.org; Sun, 22 Feb 2004 01:26: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 BAA03287 for ; Sun, 22 Feb 2004 01:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aun47-0002V1-00 for mmusic@ietf.org; Sun, 22 Feb 2004 01:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aun3F-0002T6-00 for mmusic@ietf.org; Sun, 22 Feb 2004 01:25:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aun2y-0002QL-00 for mmusic@ietf.org; Sun, 22 Feb 2004 01:25:00 -0500 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1M6OfNr007599; Sun, 22 Feb 2004 01:24:41 -0500 (EST) Message-ID: <40384B19.6020007@dynamicsoft.com> Date: Sun, 22 Feb 2004 01:24:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Veda Hegde CC: mmusic@ietf.org Subject: Re: [MMUSIC] bandwidth parameter in offer/answer References: In-Reply-To: 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Veda Hegde wrote: > Hi, > > Based 3264, ofererer and answerer can include a bandwidth parameter to > indicate the receive bandwidth. Both offerer and answerer should not send > more than what is specified in the bandwith parameter. > > 2327 says that b=AS:... is the maximum bandwidth an application can use. > > Can answerer include a bandwidth value that is greater than what is offered > if answerer can receive more than what the offerer can receive? Yes. The bandwidth parameters in each direction are independent of each other. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Feb 23 03:41:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13661 for ; Mon, 23 Feb 2004 03:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBeE-0002oL-Q7 for mmusic-archive@odin.ietf.org; Mon, 23 Feb 2004 03:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N8f6cs010799 for mmusic-archive@odin.ietf.org; Mon, 23 Feb 2004 03:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBeD-0002o2-N0 for mmusic-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 03:41: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 DAA13641 for ; Mon, 23 Feb 2004 03:41:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvBeB-0005Sw-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 03:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvBdD-0005Ow-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 03:40:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvBcG-0005KY-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 03:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBcG-0002de-1E; Mon, 23 Feb 2004 03:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBbK-0002Tc-6o for mmusic@optimus.ietf.org; Mon, 23 Feb 2004 03:38: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 DAA13490 for ; Mon, 23 Feb 2004 03:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvBbH-0005Fq-00 for mmusic@ietf.org; Mon, 23 Feb 2004 03:38:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvBaI-0005AW-00 for mmusic@ietf.org; Mon, 23 Feb 2004 03:37:03 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AvBZJ-00052j-00 for mmusic@ietf.org; Mon, 23 Feb 2004 03:36:01 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60747 helo=[192.168.0.5]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1AvBYk-0003Yt-00; Mon, 23 Feb 2004 08:35:27 +0000 In-Reply-To: <20040216095541.52cdc82c.csp@csperkins.org> References: <20040216095541.52cdc82c.csp@csperkins.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39D8369A-65DB-11D8-BE02-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?J=F6rg_Ott?= From: Colin Perkins Subject: Re: [MMUSIC] Agenda items for Seoul Date: Mon, 23 Feb 2004 08:35:25 +0000 To: mmusic@ietf.org X-Mailer: Apple Mail (2.612) 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 16 Feb 2004, at 09:55, Colin Perkins wrote: > We have requested one agenda slot for MMUSIC at the 59th IETF in > Seoul. If > you wish agenda time, please contact the chairs by the end of this > week. To date, we have received agenda requests to discuss specification of time in URI queries and fragments, ICE, and the updated RTSP specification. If you wish to request agenda time to discuss another subject, please contact the working group chairs immediately. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Feb 23 04:48:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16032 for ; Mon, 23 Feb 2004 04:48: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 1AvCh4-0007Ey-3R for mmusic-archive@odin.ietf.org; Mon, 23 Feb 2004 04:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N9m5qR027830 for mmusic-archive@odin.ietf.org; Mon, 23 Feb 2004 04:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCh3-0007En-9s for mmusic-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 04:48: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 EAA16015 for ; Mon, 23 Feb 2004 04:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCh0-0002Mz-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 04:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvCg2-0002IZ-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 04:47:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvCf3-0002DX-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 04:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCf3-00078H-LW; Mon, 23 Feb 2004 04:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCeP-00077W-N5 for mmusic@optimus.ietf.org; Mon, 23 Feb 2004 04:45: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 EAA15972 for ; Mon, 23 Feb 2004 04:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCeM-0002B8-00 for mmusic@ietf.org; Mon, 23 Feb 2004 04:45:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvCdK-00026p-00 for mmusic@ietf.org; Mon, 23 Feb 2004 04:44:15 -0500 Received: from [212.68.150.1] (helo=embexcil02.emblaze.ent) by ietf-mx with esmtp (Exim 4.12) id 1AvCcc-0001yI-00 for mmusic@ietf.org; Mon, 23 Feb 2004 04:43:31 -0500 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_01C3F9F1.96BD2602" Date: Mon, 23 Feb 2004 11:44:10 +0200 Message-ID: Thread-Topic: draft-ietf-avt-rtp-h264-03.doc question Thread-Index: AcP58ZacRXLmV4YmRlKkw3Y4NLqEAA== From: "Amir Wolf" To: "mmusic (E-mail)" Subject: [MMUSIC] draft-ietf-avt-rtp-h264-03.doc question 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=HTML_60_70,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F9F1.96BD2602 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi All, I have one question about the above draft related to packetization-mode. The draft specifies that when packetization-mode is set to 2=20 single NAL unit packets and STAP-As MUST NOT be present in the stream. I really don't understand this limitation, It is possible for a server = to use MTAP when having small frames, though aggregating several frames = in one RTP packet to fill the MTU size. On the other hand, when getting a large frame, The server may use STAP-A = and not STAP-B to reduce overheads. Am I missing something? Thanks=20 Amir wolf Direct: +972-9-7699386 Mobile: +972-55-509035 Fax: +972 9 7699 373 EMBLAZE Systems,Ltd. www.emblaze.com 22 Zarhin St. Raanana 43662, ISRAEL =20 ------_=_NextPart_001_01C3F9F1.96BD2602 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
I have = one question=20 about the above draft related to packetization-mode.
The=20 draft specifies that when packetization-mode=20 is set to 2=20

single NAL unit packets and = STAP-As MUST=20 NOT be present in the = stream.

I really don't understand this limitation, It = is=20 possible for a server to use MTAP when having small frames, though = aggregating=20 several frames in one RTP packet to fill the MTU size.

On the other hand, when getting a large = frame, The=20 server may use STAP-A and not STAP-B to reduce = overheads.

Am I missing something?

Thanks 

Amir=20 wolf

Direct: = +972-9-7699386

Mobile: = +972-55-509035

Fax: +972 9 = 7699=20 373

EMBLAZE = Systems,Ltd.=20 www.emblaze.com

22 Zarhin St. = Raanana =20 43662, ISRAEL

 
------_=_NextPart_001_01C3F9F1.96BD2602-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Feb 23 05:18:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17657 for ; Mon, 23 Feb 2004 05:18:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDAW-0001du-8e for mmusic-archive@odin.ietf.org; Mon, 23 Feb 2004 05:18:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NAIW0c006313 for mmusic-archive@odin.ietf.org; Mon, 23 Feb 2004 05:18:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDAV-0001dj-Bt for mmusic-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 05:18: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 FAA17635 for ; Mon, 23 Feb 2004 05:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDAS-000579-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 05:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvD9S-000520-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 05:17:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvD91-0004wU-00 for mmusic-web-archive@ietf.org; Mon, 23 Feb 2004 05:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvD94-0001QY-5L; Mon, 23 Feb 2004 05:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvD89-00011K-Cv for mmusic@optimus.ietf.org; Mon, 23 Feb 2004 05:16: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 FAA17485 for ; Mon, 23 Feb 2004 05:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvD86-0004tb-00 for mmusic@ietf.org; Mon, 23 Feb 2004 05:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvD77-0004pl-00 for mmusic@ietf.org; Mon, 23 Feb 2004 05:15:02 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvD6E-0004mT-00; Mon, 23 Feb 2004 05:14:06 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NAE7Ah005975; Mon, 23 Feb 2004 11:14:07 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 11:14:06 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMFLNRM4; Mon, 23 Feb 2004 11:14:13 +0100 Message-ID: <4039D1D3.9030109@ericsson.com> Date: Mon, 23 Feb 2004 11:11:31 +0100 X-Sybari-Trust: f554d453 c77f3eb6 eb01e110 00000138 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: Amir Wolf , "mmusic (E-mail)" , IETF AVT WG Subject: Re: [MMUSIC] draft-ietf-avt-rtp-h264-03.doc question References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2004 10:14:06.0975 (UTC) FILETIME=[C558F0F0:01C3F9F5] 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Amir, This question belong to the AVT mailing list not MMUSIC. If you respond please exclude the MMUSIC list. The reason for not allowing the usage of single NAL unit packets and STAP-As in Interleaved mode is that they do not contain Decoding Order Numbers. To avoid the inconsistencies with some NALU having DON and other not, this restriction is in place. You will have to use STAP-B in interleaved mode to send a single NALU. This is the overhead you will have to pay for using interleaving mode. I hope that clarifies things. Cheers Magnus Amir Wolf wrote: > Hi All, > I have one question about the above draft related to packetization-mode. > The draft specifies that when packetization-mode is set to 2 > > single NAL unit packets and STAP-As MUST NOT be present in the stream. > > I really don't understand this limitation, It is possible for a server > to use MTAP when having small frames, though aggregating several frames > in one RTP packet to fill the MTU size. > > On the other hand, when getting a large frame, The server may use STAP-A > and not STAP-B to reduce overheads. > > Am I missing something? > > Thanks > > Amir wolf > > Direct: +972-9-7699386 > > Mobile: +972-55-509035 > > Fax: +972 9 7699 373 > > EMBLAZE Systems,Ltd. www.emblaze.com > > 22 Zarhin St. Raanana 43662, ISRAEL > > > -- 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 24 04:01:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07869 for ; Tue, 24 Feb 2004 04:01:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYQy-0003Mx-IH for mmusic-archive@odin.ietf.org; Tue, 24 Feb 2004 04:00:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O90uST012942 for mmusic-archive@odin.ietf.org; Tue, 24 Feb 2004 04:00:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYQy-0003Mb-0R for mmusic-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 04:00:56 -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 EAA07845 for ; Tue, 24 Feb 2004 04:00:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYQv-0004Ld-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 04:00:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYQ5-0004Es-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 04:00:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvYP7-00047C-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 03:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYP8-00035p-1z; Tue, 24 Feb 2004 03:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYOG-0002yq-59 for mmusic@optimus.ietf.org; Tue, 24 Feb 2004 03:58: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 DAA07670 for ; Tue, 24 Feb 2004 03:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYOD-000407-00 for mmusic@ietf.org; Tue, 24 Feb 2004 03:58:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYNM-0003sM-00 for mmusic@ietf.org; Tue, 24 Feb 2004 03:57:13 -0500 Received: from smtp2.clb.oleane.net ([213.56.31.18]) by ietf-mx with esmtp (Exim 4.12) id 1AvYMN-0003eO-00 for mmusic@ietf.org; Tue, 24 Feb 2004 03:56:11 -0500 Received: from oleane.com (cust1.clb.oleane.net [213.56.31.97]) (authenticated) by smtp2.clb.oleane.net with ESMTP id i1O8tg0S017545 for ; Tue, 24 Feb 2004 09:55:42 +0100 Date: Tue, 24 Feb 2004 09:55:42 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "=?utf-8?Q?mg263-8?=" To: "=?iso-8859-1?Q?mmusic?=" X-XaM3-API-Version: 3.2 R32 (B53pl7) X-type: 0 X-SenderIP: 194.206.151.59 Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] =?iso-8859-1?Q?WiMAX_Summit?= 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: quoted-printable Content-Transfer-Encoding: quoted-printable WiMAX is considered the next step beyond WiFi because it is optimized for= =0D=0Abroadband operation, fixed and later mobile. The WiMAX Summit, to = be organised =0D=0Ain Paris next May 25-28, will gather the most distingu= ished experts and key =0D=0Aplayers in the field.=0D=0A=95 Are WiMAX and = WiFi complementary?=0D=0A=95 When and how will WiMAX evolve towards mobil= ity? =0D=0A=95 Can WiMAX be considered as a migration path to 4G? =0D=0A=95= How is addressed the interoperability challenge? =0D=0AThese questions, = among others, will be addressed during the event.=0D=0A =0D=0AMore detail= s at:=0D=0Ahttp://www.upperside.fr/wimax04/wimax04intro.htm=0D=0A _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 24 04:18:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08527 for ; Tue, 24 Feb 2004 04:18:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYhM-0004lM-7E for mmusic-archive@odin.ietf.org; Tue, 24 Feb 2004 04:17:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9HqSV018301 for mmusic-archive@odin.ietf.org; Tue, 24 Feb 2004 04:17:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYhL-0004l6-Hb for mmusic-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 04:17: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 EAA08494 for ; Tue, 24 Feb 2004 04:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYhI-0005l3-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 04:17:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYgN-0005gl-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 04:16:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvYfY-0005d3-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 04:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYfZ-0004at-49; Tue, 24 Feb 2004 04: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 1Auhql-0007dD-3a for mmusic@optimus.ietf.org; Sat, 21 Feb 2004 19:52: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 TAA23019 for ; Sat, 21 Feb 2004 19:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Auhqj-00051h-00 for mmusic@ietf.org; Sat, 21 Feb 2004 19:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auhpp-0004z1-00 for mmusic@ietf.org; Sat, 21 Feb 2004 19:51:06 -0500 Received: from orion.lrg.ufsc.br ([150.162.63.1]) by ietf-mx with esmtp (Exim 4.12) id 1Auhor-0004vK-00; Sat, 21 Feb 2004 19:50:05 -0500 Received: by orion.lrg.ufsc.br (Postfix, from userid 3002) id 38FDAA2A6; Sat, 21 Feb 2004 22:51:05 -0400 (WST) Received: from localhost (localhost [127.0.0.1]) by orion.lrg.ufsc.br (Postfix) with ESMTP id E0F04DD6D; Sat, 21 Feb 2004 22:51:04 -0400 (WST) Date: Sat, 21 Feb 2004 22:51:04 -0400 (WST) From: Carlos Becker Westphall To: jwkhong@postech.ac.kr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] [ieee-cnom] NOMS 2004 Early-Bird Registration Due Extended to Feb. 29, 2004 (fwd) 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 We apologize if you receive multiple copies of this message. NOMS 2004 OC has decided to extend the Early-Bird Registration Due Date to **Feb. 29, 2004** in order to encourage more participants to attend at low, discounted fee. Please pass this message to your colleagues and students. The detail information can be found on the NOMS 2004 homepage (http://www.noms2004.org). -------------------------------------------------------------------------- Join us in Seoul, Korea for the 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004) which will be held 19-23 April, 2004 in COEX Convention Center, Seoul, Korea. NOMS 2004 will feature the following on various network and service management topics: * 15 technical sessions * 5 panel sessions * 6 keynote speeches * 12 tutorials * 2 poster sessions * Exbitions by vendors and service providers Featured for the first time - Application Sessions on - Next Generation OSS - OSS Platforms - QoS and Service Management - Policy and Security Management The advance program, registration and hotel booking can all be found on the NOMS 2004 home page (www.noms2004.org ) Don't delay - register now for a greatly discounted early-bird rate. NOMS 2004 19-23 April, 2004 COEX, Convention Center, Seoul, Korea www.noms2004.org -- ---------------------------------------------------------------------------- James Won-Ki Hong, PhD, Associate Professor Dept. of Computer Science & Engineering, POSTECH, Pohang Korea 790-784 Tel: +82-54-279-2244 Fax: +82-54-279-5663 Mobile: +82-11-810-5641 Email: jwkhong@postech.ac.kr http://dpnm.postech.ac.kr/~jwkhong/ KNOM Chair: http://www.knom.or.kr NOMS 2004: http://www.noms2004.org IEEE ComSoc CNOM Vice Chair: http://www.comsoc.org/~cnomwww/ IEEE ComSoc Director of Online Content: http://www.comsoc.org/socstr/org/bog/officers/2004/ ---------------------------------------------------------------------------- _______________________________________________ Cnom mailing list Cnom@orion.lrg.ufsc.br http://orion.lrg.ufsc.br/mailman/listinfo/cnom _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Feb 24 11:27:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28033 for ; Tue, 24 Feb 2004 11:27: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 1AvfP4-0002hz-6E for mmusic-archive@odin.ietf.org; Tue, 24 Feb 2004 11:27:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OGRQQV010409 for mmusic-archive@odin.ietf.org; Tue, 24 Feb 2004 11:27:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfP3-0002ho-Ey for mmusic-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 11:27: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 LAA27946 for ; Tue, 24 Feb 2004 11:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfP2-0006Zu-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 11:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avf9A-00053W-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 11:11:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avf8D-0004xW-00 for mmusic-web-archive@ietf.org; Tue, 24 Feb 2004 11:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avf8E-000299-Dm; Tue, 24 Feb 2004 11:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avf7L-00025R-RL for mmusic@optimus.ietf.org; Tue, 24 Feb 2004 11:09: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 LAA27766 for ; Tue, 24 Feb 2004 11:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avf7I-0004rT-00 for mmusic@ietf.org; Tue, 24 Feb 2004 11:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avf6Z-0004kR-00 for mmusic@ietf.org; Tue, 24 Feb 2004 11:08:20 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1Avf3n-0004Z9-00; Tue, 24 Feb 2004 11:05:27 -0500 Received: from rubin.informatik.uni-bremen.de (rubin.informatik.uni-bremen.de [134.102.224.59]) by imh.informatik.uni-bremen.de (8.12.11/8.12.9) with ESMTP id i1OG56HN019555; Tue, 24 Feb 2004 17:05:07 +0100 (MET) From: Joerg Ott Received: (from jo@localhost) by rubin.informatik.uni-bremen.de (8.11.6/8.8.7) id i1OG54Y25966; Tue, 24 Feb 2004 17:05:04 +0100 Message-Id: <200402241605.i1OG54Y25966@rubin.informatik.uni-bremen.de> To: mmusic@ietf.org, agenda@ietf.org Date: Tue, 24 Feb 2004 17:05:04 +0100 (MET) Cc: csp@csperkins.org, jo@informatik.uni-bremen.de (Joerg Ott) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC agenda 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 a potential resend, but up to now it seems that our mail system swallowed my earlier mail) Please find below the agenda for the MMUSIC WG meeting in Seoul. Colin and Joerg Multiparty Multimedia Session Control (MMUSIC) WG ================================================= Wednesday, 3 March 2004, 09:00 - 11:30, Crystal 1/2 --------------------------------------------------- 0900 Agenda Bashing and Status Update (Chairs, 10) With IESG draft-rajeshkumar-mmusic-gpmd-03.txt draft-ietf-mmusic-sdp-bwparam-05.txt With AD (update needed) draft-ietf-mmusic-sdp-comedia-05.txt draft-ietf-mmusic-srcfilter-05.txt Misc Updates draft-ietf-mmusic-kmgmt-ext-10.txt draft-andreasen-mmusic-securityprecondition-01.txt draft-ietf-mmusic-anat-00.txt Awaiting Update draft-ietf-mmusic-sdp-new-15.txt 0910 Internet Media Guides (Manyfolks, 30) draft-ietf-mmusic-img-req-03.txt draft-nomura-mmusic-img-framework-03.txt (draft-luoma-mmusic-img-metadata-03.txt fyi only) (draft-luoma-mmusic-img-muppet-04.txt fyi only) (draft-luoma-mmusic-img-metadata-envelope-00.txt) 0940 SDP Security Descriptions for Media Streams (Andreasen, 10) draft-ietf-mmusic-sdescriptions-03.txt draft-andreasen-mmusic-securityprecondition-01.txt 0950 SDP Connectivity Preconditions (Andreasen, 10) draft-andreasen-mmusic-connectivityprecondition-00.txt 1000 Interactive Connectivity Establishment (ICE) (Rosenberg, 20) draft-ietf-mmusic-ice-01.txt 1020 RTSP Update (Westerlund/Zeng, 30) draft-ietf-mmusic-rfc2326bis-06.txt draft-ietf-mmusic-rtsp-nat-02.txt draft-zeng-mmusic-map-ice-rtsp-00.txt 1050 Temporal References within URIs (Parker, 10) draft-pfeiffer-temporal-fragments-02.txt 1100 Wrap up (chairs) -------------------------------------------------------------------------- NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 25 15:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11481 for ; Wed, 25 Feb 2004 15:24: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 1Aw5Zd-000719-B1 for mmusic-archive@odin.ietf.org; Wed, 25 Feb 2004 15:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKO5Hk026974 for mmusic-archive@odin.ietf.org; Wed, 25 Feb 2004 15:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Zd-00070z-6y for mmusic-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:24: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 PAA11473 for ; Wed, 25 Feb 2004 15:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Zb-0006v5-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 15:24:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5YX-0006q7-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 15:22:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Xc-0006lS-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 15:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Xc-00064N-BA; Wed, 25 Feb 2004 15:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Wm-0005jo-HE for mmusic@optimus.ietf.org; Wed, 25 Feb 2004 15:21: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 PAA11290 for ; Wed, 25 Feb 2004 15:21:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Wl-0006hT-00 for mmusic@ietf.org; Wed, 25 Feb 2004 15:21:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Vy-0006c9-00 for mmusic@ietf.org; Wed, 25 Feb 2004 15:20:20 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5VM-0006T9-00 for mmusic@ietf.org; Wed, 25 Feb 2004 15:19:41 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1PKIw413914; Wed, 25 Feb 2004 14:18:58 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Feb 2004 14:18:59 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF6279BA@zrc2c000.us.nortel.com> From: "Charlie Clemmer" To: "'jdrosen@dynamicsoft.com'" , "'mmusic@ietf.org'" Cc: "Mary Barnes" Date: Wed, 25 Feb 2004 14:18:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FBDC.970CEA2E" Subject: [MMUSIC] Updated Comments/questions on draft-ietf-mmusic-ice-01 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,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_01C3FBDC.970CEA2E Content-Type: text/plain Jonathan, I hadn't seen any response to Mary's questions earlier in the month, but since a new draft of ICE has been published, I thought I would compare comments against the new draft to see if some of the original concerns were resolved. Echoing the concern that Mary raised in point number two, I am concerned about the priorities assigned to the different transport address mechanisms. For the most part, agree with the priorities cascading down from local IPv6 addresses being the highest priority, then cascading down to local IPv4, etc; however, I'm concerned with the way VPN derived addresses in particular are grouped in the lowest priority. Given the widespread usage of VPN technology throughout the Enterprise segment, the potential exists where voice traffic could take an unencrypted route rather than the available VPN protected route that was anticipated to be used by the Enterprise admin. Perhaps a solution to this dilemma would be to make the transport address priorities something that can be configured by the user. If the priorities need to be something static, I would argue that VPN should not be a low priority transport. I believe Mary's other points below are still valid against the new draft as well. Regards, Charlie Clemmer -----Original Message----- From: Barnes, Mary Sent: Thursday, February 05, 2004 10:10 AM To: 'jdrosen@dynamicsoft.com' Cc: 'mmusic@ietf.org' Subject: [MMUSIC] Comments/questions on draft-ietf-mmusic-ice-00 Hi Jonathan, Per my note on the SIPPING WG mailing list around your NAT scenarios draft based on ICE, I also had a few comments on the ICE draft itself. My primary comments are around the prioritization of the transport addresses, with a few minor nits also noted: 1) Page 12, section 5.3, Prioritizing the Transport Addresses. It seems that the effectiveness of ICE is highly dependent upon the choices of qvalues in terms of getting the optimal path. However, the current recommendations for the assigning priorities are fairly imprecise relative to the overall importance of this aspect of the algorithm. Based on the point in the second paragraph of section 5.3, it seems that rather than a client having knowledge of topology, with ICE, the client is now configured with these relative priorities reflected in the qvalues, which are an indirect reflection of the network configuration. So, it seems that it might be useful to either be more prescriptive on what priorities would give the most desireable results for particular configarations (eg per the scenarios document) or to determine a formula or equation by which the priorities SHOULD be defined, including factors such as the number of intermediaries, etc. At a minimum, some examples in this document would be useful, perhaps just bringing in a snippet or 2 from the scenarios draft. 2) Page 12, section 5.3, Why is it that you would want the local addresses obtained from VPN interfaces to be lowest priority? It would seem that there are some cases where you might want that to be a higher priority. 3) Page 17, section 5.7, 3rd sentence, "...it SHOULD just sent..." should be "...it SHOULD just send...". 4) Page 18, section 5.8, OPEN ISSUE: "doesnt" should be "doesn't" 5) Page 34, Reference [4] RFC 3261, since the qvalue in the alt-attibute is from RFC 3261, shouldn't this be a normative reference? Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C3FBDC.970CEA2E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Updated Comments/questions on draft-ietf-mmusic-ice-01

Jonathan,

I hadn't seen any response to Mary's questions = earlier in the month, but since a new draft of ICE has been published, = I thought I would compare comments against the new draft to see if some = of the original concerns were resolved.

Echoing the concern that Mary raised in point number = two, I am concerned about the priorities assigned to the different = transport address mechanisms. For the most part, agree with the = priorities cascading down from local IPv6 addresses being the highest = priority, then cascading down to local IPv4, etc; however, I'm = concerned with the way VPN derived addresses in particular are grouped = in the lowest priority. Given the widespread usage of VPN technology = throughout the Enterprise segment, the potential exists where voice = traffic could take an unencrypted route rather than the available VPN = protected route that was anticipated to be used by the Enterprise = admin. Perhaps a solution to this dilemma would be to make the = transport address priorities something that can be configured by the = user. If the priorities need to be something static, I would argue that = VPN should not be a low priority transport.

I believe Mary's other points below are still valid = against the new draft as well.

Regards,
Charlie Clemmer

-----Original Message-----
From: Barnes, Mary
Sent: Thursday, February 05, 2004 10:10 AM
To: 'jdrosen@dynamicsoft.com'
Cc: 'mmusic@ietf.org'
Subject: [MMUSIC] Comments/questions on = draft-ietf-mmusic-ice-00


Hi Jonathan,

Per my note on the SIPPING WG mailing list around = your NAT scenarios draft based on ICE, I also had a few comments on the = ICE draft itself.  My primary comments are around the = prioritization of the transport addresses, with a few minor nits also = noted:

1) Page 12, section 5.3, Prioritizing the Transport = Addresses.  It seems that the effectiveness of ICE is highly = dependent upon the choices of qvalues in terms of getting the optimal = path. However, the current recommendations for the assigning priorities = are fairly imprecise relative to the overall importance of this aspect = of the algorithm.  Based on the point in the second paragraph of = section 5.3,  it seems that rather than a client having knowledge = of topology, with ICE, the client is now configured with these relative = priorities reflected in the qvalues, which are an indirect reflection = of the network configuration.  So, it seems that it might be = useful to either be more prescriptive on what priorities would give the = most desireable results for particular configarations (eg per the = scenarios document) or to determine a formula or equation by which the = priorities SHOULD be defined, including factors such as the number of = intermediaries, etc.  At a minimum, some examples in this document = would be useful, perhaps just bringing in a snippet or 2 from the = scenarios draft. 

2) Page 12, section 5.3,  Why is it that you = would want the local addresses
obtained from VPN interfaces to be lowest = priority?    It would seem that
there are some cases where you might want that to be = a higher priority.

3) Page 17, section 5.7, 3rd sentence, "...it = SHOULD just sent..." should be "...it SHOULD just = send...".

4) Page 18, section 5.8, OPEN ISSUE: = "doesnt" should be "doesn't"

5) Page 34, Reference [4] RFC 3261, since the qvalue = in the alt-attibute is from RFC 3261, shouldn't this be a normative = reference? 

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com
972-684-5432



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

------_=_NextPart_001_01C3FBDC.970CEA2E-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 25 15:41:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12935 for ; Wed, 25 Feb 2004 15:41: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 1Aw5px-0000Uy-MT for mmusic-archive@odin.ietf.org; Wed, 25 Feb 2004 15:40:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKevKk001916 for mmusic-archive@odin.ietf.org; Wed, 25 Feb 2004 15:40:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5px-0000Up-FC for mmusic-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:40: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 PAA12893 for ; Wed, 25 Feb 2004 15:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5pw-0001Qe-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 15:40:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5oz-0001M7-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 15:39:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5o4-0001GO-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 15:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5o4-0000Kp-H6; Wed, 25 Feb 2004 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5o2-0000KT-Tq for mmusic@optimus.ietf.org; Wed, 25 Feb 2004 15:38: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 PAA12819 for ; Wed, 25 Feb 2004 15:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5o1-0001Fx-00 for mmusic@ietf.org; Wed, 25 Feb 2004 15:38:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5n6-000144-00 for mmusic@ietf.org; Wed, 25 Feb 2004 15:38:01 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5lY-0000e4-00 for mmusic@ietf.org; Wed, 25 Feb 2004 15:36:24 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PKa3Nr009361; Wed, 25 Feb 2004 15:36:04 -0500 (EST) Message-ID: <403D071D.1010304@dynamicsoft.com> Date: Wed, 25 Feb 2004 15:35:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Clemmer CC: "'mmusic@ietf.org'" , Mary Barnes References: <870397D7C140C84DB081B88396458DAF6279BA@zrc2c000.us.nortel.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF6279BA@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Updated Comments/questions on draft-ietf-mmusic-ice-01 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 Firstly, I have to apologize that I have not responded to her comments yet; responses are pending, I'm just swamped. Indeed, unfortunately the ICE revision has virtually no changes from the previous rev. I realized I would not be able to do anything substantive before IETF, so I put in a rev just to more or less refresh the expiry timer. To answer this specific question, priority allocation is definitely a big question. Indeed, there are multiple criteria one might use to assign a priority. I have prioritized them based on usage of relays. In conversations I had with others, the comment was that ideally true latency through each path would determine priority; a route through a relay might actually yield lower latencies. You are basically proposing that security characteristics might be another way of defining priorities. To a large degree, the viability of ICE is not strongly dependent on a standardized choice of priorities. ICE functions as long as there exists a default poitn of contact which always works; selection of alternates that do better can be based on differing policies. As such, I would be amenable to text which allowed for local determination of priorities, and included discussion of the various axes that might be used in defining such a policy. Thanks, Jonathan R. Charlie Clemmer wrote: > Jonathan, > > I hadn't seen any response to Mary's questions earlier in the month, but > since a new draft of ICE has been published, I thought I would compare > comments against the new draft to see if some of the original concerns > were resolved. > > Echoing the concern that Mary raised in point number two, I am concerned > about the priorities assigned to the different transport address > mechanisms. For the most part, agree with the priorities cascading down > from local IPv6 addresses being the highest priority, then cascading > down to local IPv4, etc; however, I'm concerned with the way VPN derived > addresses in particular are grouped in the lowest priority. Given the > widespread usage of VPN technology throughout the Enterprise segment, > the potential exists where voice traffic could take an unencrypted route > rather than the available VPN protected route that was anticipated to be > used by the Enterprise admin. Perhaps a solution to this dilemma would > be to make the transport address priorities something that can be > configured by the user. If the priorities need to be something static, I > would argue that VPN should not be a low priority transport. > > I believe Mary's other points below are still valid against the new > draft as well. > > Regards, > Charlie Clemmer > > -----Original Message----- > From: Barnes, Mary > Sent: Thursday, February 05, 2004 10:10 AM > To: 'jdrosen@dynamicsoft.com' > Cc: 'mmusic@ietf.org' > Subject: [MMUSIC] Comments/questions on draft-ietf-mmusic-ice-00 > > > Hi Jonathan, > > Per my note on the SIPPING WG mailing list around your NAT scenarios > draft based on ICE, I also had a few comments on the ICE draft itself. > My primary comments are around the prioritization of the transport > addresses, with a few minor nits also noted: > > 1) Page 12, section 5.3, Prioritizing the Transport Addresses. It seems > that the effectiveness of ICE is highly dependent upon the choices of > qvalues in terms of getting the optimal path. However, the current > recommendations for the assigning priorities are fairly imprecise > relative to the overall importance of this aspect of the algorithm. > Based on the point in the second paragraph of section 5.3, it seems > that rather than a client having knowledge of topology, with ICE, the > client is now configured with these relative priorities reflected in the > qvalues, which are an indirect reflection of the network configuration. > So, it seems that it might be useful to either be more prescriptive on > what priorities would give the most desireable results for particular > configarations (eg per the scenarios document) or to determine a formula > or equation by which the priorities SHOULD be defined, including factors > such as the number of intermediaries, etc. At a minimum, some examples > in this document would be useful, perhaps just bringing in a snippet or > 2 from the scenarios draft. > > 2) Page 12, section 5.3, Why is it that you would want the local addresses > obtained from VPN interfaces to be lowest priority? It would seem that > there are some cases where you might want that to be a higher priority. > > 3) Page 17, section 5.7, 3rd sentence, "...it SHOULD just sent..." > should be "...it SHOULD just send...". > > 4) Page 18, section 5.8, OPEN ISSUE: "doesnt" should be "doesn't" > > 5) Page 34, Reference [4] RFC 3261, since the qvalue in the alt-attibute > is from RFC 3261, shouldn't this be a normative reference? > > Regards, > Mary H. Barnes > mary.barnes@nortelnetworks.com > 972-684-5432 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Feb 25 17:48:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20249 for ; Wed, 25 Feb 2004 17:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7oy-0003Wy-3B for mmusic-archive@odin.ietf.org; Wed, 25 Feb 2004 17:48:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMm4im013566 for mmusic-archive@odin.ietf.org; Wed, 25 Feb 2004 17:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7ox-0003Wj-Vc for mmusic-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:48: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 RAA20228 for ; Wed, 25 Feb 2004 17:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7ov-0007jV-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 17:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7nw-0007dJ-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 17:47:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7mz-0007Wb-00 for mmusic-web-archive@ietf.org; Wed, 25 Feb 2004 17:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7n0-00034J-Ms; Wed, 25 Feb 2004 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7m6-000328-8F for mmusic@optimus.ietf.org; Wed, 25 Feb 2004 17:45: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 RAA20108 for ; Wed, 25 Feb 2004 17:45:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7m3-0007Qd-00 for mmusic@ietf.org; Wed, 25 Feb 2004 17:45:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7l9-0007LA-00 for mmusic@ietf.org; Wed, 25 Feb 2004 17:44:08 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7kE-0007Ej-00 for mmusic@ietf.org; Wed, 25 Feb 2004 17:43:10 -0500 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1PMh7mS023778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Feb 2004 17:43:07 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.10/8.12.9) with ESMTP id i1PMh7fv020075; Wed, 25 Feb 2004 17:43:07 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.10/8.12.10/Submit) id i1PMh6UT020072; Wed, 25 Feb 2004 17:43:06 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16445.9466.811267.458095@cnr.cs.columbia.edu> Date: Wed, 25 Feb 2004 17:43:06 -0500 To: David Yon Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Re: comedia and TLS In-Reply-To: <5.1.1.6.0.20040220133932.0332eec0@mail.rfdsoftware.com> References: <5.1.1.6.0.20040220133932.0332eec0@mail.rfdsoftware.com> X-Mailer: VM 7.17 under Emacs 20.7.1 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 On Friday, February 20 2004, "David Yon" wrote to "mmusic@ietf.org" saying: > Given the length of time comedia has remained in limbo, and my limited > availability to maintain it, I would favor a split as well. There are > potentially a lot of issues raised by fleshing out TLS to include > certificate validation information within SDP that have nothing to do with > basic TCP. I'm fine with a split as well. I'm also willing to be an author or co-author of the comedia TLS draft. > The only question I would have is whether I should pull all mention of TLS > from the original comedia. I'd say pull any normative mentions, but informative mentions would be okay (E.g., some text like "this framework could also be used for other connection-oriented protocols, such as SCTP or TLS; however, this specification does not define protocol identifiers for these protocols.") -- Jonathan Lennox lennox at cs dot columbia dot edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Feb 26 11:57:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24163 for ; Thu, 26 Feb 2004 11:57: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 1AwOol-0005NC-RA for mmusic-archive@odin.ietf.org; Thu, 26 Feb 2004 11:56:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QGuxYj020653 for mmusic-archive@odin.ietf.org; Thu, 26 Feb 2004 11:56:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOol-0005N2-Mr for mmusic-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 11:56: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 LAA24117 for ; Thu, 26 Feb 2004 11:56:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOok-0000os-00 for mmusic-web-archive@ietf.org; Thu, 26 Feb 2004 11:56:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOns-0000ex-00 for mmusic-web-archive@ietf.org; Thu, 26 Feb 2004 11:56:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwOms-0000WB-00 for mmusic-web-archive@ietf.org; Thu, 26 Feb 2004 11: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 1AwOmr-00059U-9o; Thu, 26 Feb 2004 11:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOlw-000570-PM for mmusic@optimus.ietf.org; Thu, 26 Feb 2004 11:54: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 LAA24026 for ; Thu, 26 Feb 2004 11:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOlv-0000NE-00 for mmusic@ietf.org; Thu, 26 Feb 2004 11:54:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOkl-0000Ew-00 for mmusic@ietf.org; Thu, 26 Feb 2004 11:52:52 -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 1AwOkQ-000095-00 for mmusic@ietf.org; Thu, 26 Feb 2004 11:52:30 -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 i1QGlxF28674; Thu, 26 Feb 2004 11:47:59 -0500 Message-Id: <5.1.1.6.0.20040226085216.03309c30@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 26 Feb 2004 11:52:00 -0500 To: Jonathan Lennox From: David Yon Subject: Re: [MMUSIC] Re: comedia and TLS Cc: mmusic@ietf.org 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 Sounds good. Comedia-tls is all yours. :-) At 07:10 PM 2/25/2004, you wrote: >On Friday, February 20 2004, "David Yon" wrote to "mmusic@ietf.org" saying: > > > Given the length of time comedia has remained in limbo, and my limited > > availability to maintain it, I would favor a split as well. There are > > potentially a lot of issues raised by fleshing out TLS to include > > certificate validation information within SDP that have nothing to do with > > basic TCP. > >I'm fine with a split as well. I'm also willing to be an author or >co-author of the comedia TLS draft. > > > The only question I would have is whether I should pull all mention of TLS > > from the original comedia. > >I'd say pull any normative mentions, but informative mentions would be okay >(E.g., some text like "this framework could also be used for other >connection-oriented protocols, such as SCTP or TLS; however, this >specification does not define protocol identifiers for these protocols.") > >-- >Jonathan Lennox >lennox at cs dot columbia dot edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Feb 29 16:52:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11464 for ; Sun, 29 Feb 2004 16:52: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 1AxYr8-0001aJ-GN for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 16:52:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TLqEXC006089 for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 16:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYr8-0001a8-8f for mmusic-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 16:52: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 QAA11461 for ; Sun, 29 Feb 2004 16:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxYr6-0004bP-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 16:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxYqA-0004XB-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 16:51:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxYpz-0004Si-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 16:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYpy-0001NP-9E; Sun, 29 Feb 2004 16:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYpD-0001JM-5Q for mmusic@optimus.ietf.org; Sun, 29 Feb 2004 16:50: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 QAA11395 for ; Sun, 29 Feb 2004 16:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxYpB-0004R3-00 for mmusic@ietf.org; Sun, 29 Feb 2004 16:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxYoF-0004Lo-00 for mmusic@ietf.org; Sun, 29 Feb 2004 16:49:18 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AxYnP-0004Gn-00 for mmusic@ietf.org; Sun, 29 Feb 2004 16:48:23 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sun, 29 Feb 2004 13:48:02 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Sun, 29 Feb 2004 13:43:15 -0800 Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1AxYtp-0001fN-MP for robla@real.com; Sun, 29 Feb 2004 13:55:01 -0800 Date: Sun, 29 Feb 2004 13:54:05 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #120 - 7 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net) 2. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net) 3. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net) 4. [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts (SourceForge.net) 5. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net) 6. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net) 7. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:26:46 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods Bugs item #494526, was opened at 2001-12-18 10:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: The use of message-body in methods Initial Comment: The current specification does only allow use of message-body in methods DESCRIBE and GET_PARAMETER according to text below. Chapter 12 secodn paragraph: " ... The last column lists the method for which this header field is meaningful; the designation "entity" refers to all methods that return a message body. Within this specification, DESCRIBE and GET_PARAMETER fall into this class." This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table clarifying which headers that are allowed to have message-body would be good. What is needed to be discussed in the WG is a possiblilty to allow message-body also for the SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. Today there exist no way for a server to express different alternatives in a SDP for a media, primarily regarding media encoding. A selection of media variants may perhaps already be possible through the use of different URLs. A walk-through example would look like this: Client does describe and receives a SDP. This SDP tells the client that the audio media is available AMR and can be packetized both with or without interleaving. Client selects the interleaving case and removes the payload type without interleaving from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks at the received SDP and uses the media information concerning the URL in the setup and use it to configure the payload packetizer. In the above example a number of alternatives could also be given in the SDP. The ones not supported by the client is removed. They can also be prioritized. Then the server is allowed to select and also to switch encoding during the session. This makes it for example possible to adapt to network conditions. This will of course require a more complete overview what the consequences will be of such a change. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:26 Message: Logged In: YES user_id=302620 The bugs part has been resolved. There is a table 8 that shows what methods that can have body and in what directions. Also the status codes 4xx and 5xx and a few more specifying this explicitly can have them. The request for a feature extension for offer answer has been logged seperatly in a feature reuqest: 513787 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 12:58 Message: Logged In: YES user_id=302620 The method table in the beginning of the header chapter now contains a column which tells how body can be used. Also all error messages may include a body. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:29:08 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods Bugs item #494526, was opened at 2001-12-18 10:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: The use of message-body in methods Initial Comment: The current specification does only allow use of message-body in methods DESCRIBE and GET_PARAMETER according to text below. Chapter 12 secodn paragraph: " ... The last column lists the method for which this header field is meaningful; the designation "entity" refers to all methods that return a message body. Within this specification, DESCRIBE and GET_PARAMETER fall into this class." This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table clarifying which headers that are allowed to have message-body would be good. What is needed to be discussed in the WG is a possiblilty to allow message-body also for the SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. Today there exist no way for a server to express different alternatives in a SDP for a media, primarily regarding media encoding. A selection of media variants may perhaps already be possible through the use of different URLs. A walk-through example would look like this: Client does describe and receives a SDP. This SDP tells the client that the audio media is available AMR and can be packetized both with or without interleaving. Client selects the interleaving case and removes the payload type without interleaving from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks at the received SDP and uses the media information concerning the URL in the setup and use it to configure the payload packetizer. In the above example a number of alternatives could also be given in the SDP. The ones not supported by the client is removed. They can also be prioritized. Then the server is allowed to select and also to switch encoding during the session. This makes it for example possible to adapt to network conditions. This will of course require a more complete overview what the consequences will be of such a change. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:29 Message: Logged In: YES user_id=302620 The bugs part has been resolved. There is a table 8 that shows what methods that can have body and in what directions. Also the status codes 4xx and 5xx and a few more specifying this explicitly can have them. The request for a feature extension for offer answer has been logged seperatly in a feature reuqest: 513787 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:26 Message: Logged In: YES user_id=302620 The bugs part has been resolved. There is a table 8 that shows what methods that can have body and in what directions. Also the status codes 4xx and 5xx and a few more specifying this explicitly can have them. The request for a feature extension for offer answer has been logged seperatly in a feature reuqest: 513787 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 12:58 Message: Logged In: YES user_id=302620 The method table in the beginning of the header chapter now contains a column which tells how body can be used. Also all error messages may include a body. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:30:47 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods Bugs item #494526, was opened at 2001-12-18 10:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: The use of message-body in methods Initial Comment: The current specification does only allow use of message-body in methods DESCRIBE and GET_PARAMETER according to text below. Chapter 12 secodn paragraph: " ... The last column lists the method for which this header field is meaningful; the designation "entity" refers to all methods that return a message body. Within this specification, DESCRIBE and GET_PARAMETER fall into this class." This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table clarifying which headers that are allowed to have message-body would be good. What is needed to be discussed in the WG is a possiblilty to allow message-body also for the SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. Today there exist no way for a server to express different alternatives in a SDP for a media, primarily regarding media encoding. A selection of media variants may perhaps already be possible through the use of different URLs. A walk-through example would look like this: Client does describe and receives a SDP. This SDP tells the client that the audio media is available AMR and can be packetized both with or without interleaving. Client selects the interleaving case and removes the payload type without interleaving from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks at the received SDP and uses the media information concerning the URL in the setup and use it to configure the payload packetizer. In the above example a number of alternatives could also be given in the SDP. The ones not supported by the client is removed. They can also be prioritized. Then the server is allowed to select and also to switch encoding during the session. This makes it for example possible to adapt to network conditions. This will of course require a more complete overview what the consequences will be of such a change. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:30 Message: Logged In: YES user_id=302620 The bugs part has been resolved. There is a table 8 that shows what methods that can have body and in what directions. Also the status codes 4xx and 5xx and a few more specifying this explicitly can have them. The request for a feature extension for offer answer has been logged seperatly in a feature reuqest: 513787 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:29 Message: Logged In: YES user_id=302620 The bugs part has been resolved. There is a table 8 that shows what methods that can have body and in what directions. Also the status codes 4xx and 5xx and a few more specifying this explicitly can have them. The request for a feature extension for offer answer has been logged seperatly in a feature reuqest: 513787 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:26 Message: Logged In: YES user_id=302620 The bugs part has been resolved. There is a table 8 that shows what methods that can have body and in what directions. Also the status codes 4xx and 5xx and a few more specifying this explicitly can have them. The request for a feature extension for offer answer has been logged seperatly in a feature reuqest: 513787 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 12:58 Message: Logged In: YES user_id=302620 The method table in the beginning of the header chapter now contains a column which tells how body can be used. Also all error messages may include a body. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:35:28 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts Bugs item #506684, was opened at 2002-01-21 23:46 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194 Category: None >Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Magnus Westerlund (magwes) Summary: Allow Rtp-Info header in more contexts Initial Comment: Currently, the RFC states that the Rtp-Info header is required in the PLAY response. But it is not clear whether or not the Rtp-Info is allowed in other contexts. I think of three other cases where it might be useful: 1. In the RECORD request. If a client is sending data to the server, the client SHOULD send the Rtp-Info header to the server, so that the server can know the initial RTP sequence number and RTP timestamp. 2. In the SETUP response. If the server is already playing, and the client sends a SETUP command to select a stream that previously was not selected, I believe the server will start sending data for this stream immediately. (Check the RFC, I am not sure it clearly states whether the newly selected stream will be streamed immediately or not.) In this case, it would be useful for the client to be able to recieve an Rtp-Info header as a part of the SETUP response. But this has to be seen as an optional optimization -- the client can always send a second PLAY command, and the Rtp-Info header will then be available in the PLAY response. 3. In the ANNOUNCE command. If the server is already playing, and something related to the SDP description suddenly changes, the server can send a new SDP to the client using the ANNOUNCE command. It might be necessary to include a new Rtp-Info header in this case. A similar situation happens when the server is reconding something, and the client sends an ANNOUNCE command to the server. Again, this is probably just an optional optimization, because the client can always send a new PLAY command and obtain the Rtp-Info header again. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:35 Message: Logged In: YES user_id=302620 The header tables are missing RTP-Info. Needs to be added. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:05 Message: Logged In: YES user_id=302620 The usage of RTP-Info is now furhter clarified in relation to PLAY and SETUP. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-25 13:44 Message: Logged In: YES user_id=302620 As Record and Announce has been removed from the specification these questions are not longer relevant to the core specification. However any future definition needs to consider them. RTP-Info for SETUP is currently used in two cases: 1. When in play state adding a stream to the session 2. When in play state changing the transport parameters ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:35 Message: Logged In: YES user_id=302620 I agree that RTP-Info i SETUP while be necessary for the optional functionality of SETUP and TEARDOWN while playing. For RECORD this should be part of the work in defining how it should really work. For ANNOUNCE we need to further discuss this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:37:55 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause Bugs item #507882, was opened at 2002-01-24 09:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP timestamps when playing after pause Initial Comment: What happends to the RTP timestamp when you issue a play after being paused for some time? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:37 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:12 Message: Logged In: YES user_id=302620 Aravind has agreed to write up the example and necessary text. Transfering bug to him. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 10:48 Message: Logged In: YES user_id=302620 A Clear example of RTP Timestamp and synchronization will be added in appendix B - RTP transport. The discussion in MMUSIC has made it clear that a continous time model is needed to make RTCP work correctly. It has to be accpeted that for on-demand media this will result in slightly more code for the clients and servers. However all pices to makes things work is already present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-23 16:05 Message: Logged In: YES user_id=302620 This has been further discussed in the MMUSIC mailing list. A important point is that RTP and RTCP to function as intended in this environment must have a timestamp space that increase continously with real time. A client handling the RTSP range header and RTP-Info can always synchronize the data correctly independtly of which case the server sent out. Using a continous RTP Timestamp space allows the same timestamp model for both on-demand and live media. The proposed resolution is to clrafiy in the RTP appendix of the specification that a RTP timestamp space continous in regards to real-time SHALL be used. Further write a warning that this has been missunderstood and clients is RECOMMENDED to handle both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:40:28 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause Bugs item #507882, was opened at 2002-01-24 09:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP timestamps when playing after pause Initial Comment: What happends to the RTP timestamp when you issue a play after being paused for some time? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:40 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:37 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:12 Message: Logged In: YES user_id=302620 Aravind has agreed to write up the example and necessary text. Transfering bug to him. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 10:48 Message: Logged In: YES user_id=302620 A Clear example of RTP Timestamp and synchronization will be added in appendix B - RTP transport. The discussion in MMUSIC has made it clear that a continous time model is needed to make RTCP work correctly. It has to be accpeted that for on-demand media this will result in slightly more code for the clients and servers. However all pices to makes things work is already present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-23 16:05 Message: Logged In: YES user_id=302620 This has been further discussed in the MMUSIC mailing list. A important point is that RTP and RTCP to function as intended in this environment must have a timestamp space that increase continously with real time. A client handling the RTSP range header and RTP-Info can always synchronize the data correctly independtly of which case the server sent out. Using a continous RTP Timestamp space allows the same timestamp model for both on-demand and live media. The proposed resolution is to clrafiy in the RTP appendix of the specification that a RTP timestamp space continous in regards to real-time SHALL be used. Further write a warning that this has been missunderstood and clients is RECOMMENDED to handle both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:41:59 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause Bugs item #507882, was opened at 2002-01-24 09:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP timestamps when playing after pause Initial Comment: What happends to the RTP timestamp when you issue a play after being paused for some time? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:41 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:40 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:37 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:12 Message: Logged In: YES user_id=302620 Aravind has agreed to write up the example and necessary text. Transfering bug to him. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 10:48 Message: Logged In: YES user_id=302620 A Clear example of RTP Timestamp and synchronization will be added in appendix B - RTP transport. The discussion in MMUSIC has made it clear that a continous time model is needed to make RTCP work correctly. It has to be accpeted that for on-demand media this will result in slightly more code for the clients and servers. However all pices to makes things work is already present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-23 16:05 Message: Logged In: YES user_id=302620 This has been further discussed in the MMUSIC mailing list. A important point is that RTP and RTCP to function as intended in this environment must have a timestamp space that increase continously with real time. A client handling the RTSP range header and RTP-Info can always synchronize the data correctly independtly of which case the server sent out. Using a continous RTP Timestamp space allows the same timestamp model for both on-demand and live media. The proposed resolution is to clrafiy in the RTP appendix of the specification that a RTP timestamp space continous in regards to real-time SHALL be used. Further write a warning that this has been missunderstood and clients is RECOMMENDED to handle both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Feb 29 19:49:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19361 for ; Sun, 29 Feb 2004 19:49: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 1AxbcT-0003ZU-2z for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 19:49:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210nH4Y013724 for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 19:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbcS-0003ZH-Us for mmusic-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:49: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 TAA19356 for ; Sun, 29 Feb 2004 19:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbcR-0004fR-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 19:49:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbbX-0004bd-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 19:48:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxbbE-0004XD-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 19:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbbE-0003UJ-M2; Sun, 29 Feb 2004 19:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbab-0003TO-FP for mmusic@optimus.ietf.org; Sun, 29 Feb 2004 19:47: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 TAA19243 for ; Sun, 29 Feb 2004 19:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbaZ-0004WQ-00 for mmusic@ietf.org; Sun, 29 Feb 2004 19:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbZZ-0004RP-00 for mmusic@ietf.org; Sun, 29 Feb 2004 19:46:19 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AxbZA-0004Mm-00 for mmusic@ietf.org; Sun, 29 Feb 2004 19:45:52 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i210jqqY026022 for ; Mon, 1 Mar 2004 01:45:52 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 01:45:52 +0100 Received: from ericsson.com (sealwp02-129.sw.ericsson.se [153.88.142.129]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFNTQLZ; Mon, 1 Mar 2004 01:46:23 +0100 Message-ID: <40428713.4020903@ericsson.com> Date: Mon, 01 Mar 2004 01:42:59 +0100 X-Sybari-Trust: 8f48ed70 c77f3eb6 73f6aa1c 00000138 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: "mmusic (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 00:45:52.0347 (UTC) FILETIME=[8C41D2B0:01C3FF26] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP discussion and status 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, Below is an proposal for an agenda for a off-line discussion of RTSP. If you are at the IETF meeting and interested in participating in a discussion please send me a mail. My three proposals for meeting time if enough interest exist are: Tuesday 15.30-17.00 Wednesday 13.00-15.00 Thursday 9.00-11.00 Please indicate possibility to participate for all of the times. Below the agenda there is a message indicating my view of the status of all the Bugs currently open in the sourceforge bug tracker. Cheers Magnus ----- Agenda RTSP discussion IETF 59 1. Opening of meeting and Administrative 2. RTSP Core 2.1 Core specification bugs under development. a. http://rtsp.org/bug507882 - RTP timestamp and pause - Examples edited into 06 b. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Around will write up text. c. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - The text has been removed, it is now unspecified d. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Check if live is written, and try to remove, in benefit for Unbounded session. This has been resolved by defining live as being unbound. See definition chapter of 06 version. - Check if the syntax does not create great clashes with the TiVo use case. However it is unlikely that the full semantics necessary can be expressed with current attributes. Has not been done. e. http://rtsp.org/bug531189 - How does REDIRECT method work - Has been edited in. f. http://rtsp.org/bug770522 - Request to response time is not limited. - The text has been updated and added into the spec, see section 9.5 g. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Text in the SETUP method description seems strict enough. h. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - It seems initial and ready state changes are equal, and the play state being more restricted. - Point out that in the general case the changes can result in that a new RTP session is created. - Another consideration is for connection oriented media, can a switch over be performed relatively seamless. - It seems that not requiring a PAUSE, SETUP, PLAY sequence makes sense, thus motivating the continuation of this work. - However the proposals and text needs more thought. - Geetha will provide new text. i. http://rtsp.org/bug810666 - Removal of SETUP in play state - Magnus will edit in that it is unspecified. [DONE] j. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes - Needs to look into backwards compatibility issues. - This issue is connected to issue (r), to allow a server to announce dual address realm support. - It needs a proposal text for evaluation. k. http://rtsp.org/bug795314 - Caching of OPTIONS request - It seems that the Caching chapter is enough. I don't see a reason for allowing caching of OPTIONS l. http://rtsp.org/bug850256 - When must RTP-Info be included? - Usage of RTP-Info can be a SHOULD, however if the server does not provide it, the client will be required to do synchronization by RTCP. Servers are strongly recommend if able to include RTP-Info with timestamp information. [Edited in] m. http://rtsp.org/bug850265 - Removed features are unspecified, not forbidden - Needs to be edited in. [DONE] n. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces. - Nothing done, needs to be edited in. [Done] o. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one chapter? - Nothing done, needs to be edited in. [Done] p. http://rtsp.org/bug829528 - Usage of Grouping of media lines with RTSP. - For further study and discussion. q. http://rtsp.org/bug853175 - Dest_addr needs indicator for using RTSP IP - The dest_addr allow for empty host specifier, thus if one does not want to specify the address, only port one have an empty host part. This has been clarified in the text. r. http://rtsp.org/bug853178 - Security risk with changing transport parameters - For further study and discussion. s. http://rtsp.org/bug853184 - How to learn servers multicast capabilities - For further study and discussion. t. http://rtsp.org/bug889699 - Change requirement level on auth for media destination 2.2 Tracking of items not require actions currently. http://rtsp.org/bug464462 - Content-Length header wrong in examples http://rtsp.org/bug810681 - The updated specification version number 3. RTSP Specification Extensions 3.1 Streaming Relays. 3.2 End of Media 3.3 RTSP and NAT issues 4. Next meeting - Will be in mid January 5. Meeting closed. Current Sourceforge bugs and their status ========================================== Nr Class --------------------------------------------------- 10 Stable Resolution exist, proposed to be closed 17 Resolution Exist, needs further review 7 Needs write-up of Resolution 4 Needs Discussion 2 Has dependencies forcing delay Stable Resolution exist, proposed to be closed ---------------------------------------------- 493054 IPv6 issues * 2001-12-13 23:49 magwes nobody - Awaiting review before being closed. 493265 Pause - Play behaviour clarification * 2001-12-14 12:55 magwes magwes - I think it has been clarified, intend to close if not comments are given. 494526 The use of message-body in methods * 2001-12-18 10:43 nobody magwes - The bug part is resolve, the feature request has its own feature request in that tracker. Recommend that we close bug. 506412 RTSP Teardown functionality * 2002-01-21 13:41 magwes magwes - Is now clarified, please review. Propose to close. 513880 How to use Range when Scale is negative * 2002-02-06 19:48 arvy_n klemets - This has been resolved, and been available since last revision. Close bug. 533691 Clarify Range Where t0 <= t1 * 2002-03-22 18:36 arvy_n zengtm - Is clarified in text, propose to close bug 556061 When can REDIRECT be received? * 2002-05-14 20:33 magwes robla - Has been made clear, review and then close. 640265 Extension of Transport header * 2002-11-18 21:07 magwes magwes - The possibility to extend Transport header is clarified. Needs review 640272 Default way of deriving aggregate URL * 2002-11-18 21:19 magwes magwes - Has been resolved as being undefined. Clarified in text. 663715 Requirement levels for Transport:SSRC needs clarification * 2003-01-07 15:31 arvy_n magwes - This is now clarified. Review and close Resolution Exist, needs further review -------------------------------------- 494533 The use of the word require in the RFC. * 2001-12-18 11:16 magwes magwes - There has been some editing done in relation of this. However further review of the usage of RFC 2119 normative language is recommended. 500868 Require: option-tag values unclear * 2002-01-08 17:09 magwes seansh - The IANA registry is proposed, some values has been defined. Further review solicited. If no comments forth coming, propose to close this bug. 507882 RTP timestamps when playing after pause * 2002-01-24 09:30 arvy_n magwes - This has been added to Appendix B. Please review. 531189 How does REDIRECT method work * 2002-03-18 05:14 magwes magwes - Is edited in, needs review. Possible issue with connection handling. Current text resolves this. Acceptable? 538997 Need to flesh out 1.5 (Extending RTSP) * 2002-04-04 01:26 magwes robla - IANA section is in good shape. Please review 1.5 if it is enough. 631957 Use of # and ? in RTSP URLs * 2002-11-01 09:49 magwes magwes - The URI part is clarified to allow both. However the actual usage is not defined. 633779 SET_PARAMETER responses * 2002-11-05 13:19 magwes magwes - Text for SET_PARAMETER has been updated. Needs review. 672160 Describe a interleaved RTSP channel for client RR reports * 2003-01-22 01:28 magwes zengtm - The bi-directional nature of channels has been clarified. Needs review. 770522 Request to response time is not limited. * 2003-07-13 16:00 magwes magwes - Text proposal in spec. Needs review. 803064 Teardown text needs rewrite * 2003-09-09 13:20 magwes magwes - Has been updated, needs review. 804219 How to handle sync in re-SETUP * 2003-09-11 09:20 magwes magwes - Has been clarified. Needs review 831553 Error in rfc2326bis-04 example 15.4 * 2003-10-28 06:20 magwes zengtm - Has been fixed. Resolution needs review. More than a single solution possible. 840304 CSEQ is direction dependent in numberspaces. * 2003-11-11 22:54 magwes magwes - Has been clarified, needs review. 850256 When must RTP-Info be included? * 2003-11-27 15:06 magwes magwes - The level has been lowered to SHOULD, strengthen motivation. 850265 Removed features are unspecified, not forbidden * 2003-11-27 15:25 magwes magwes - Definition written in and applied in most cases. Needs review. 850267 Gather all ABNF in syntax chapter * 2003-11-27 15:38 magwes magwes - Performed, needs review. 853175 Dest_addr needs indicator for using RTSP IP * 2003-12-03 11:00 magwes magwes - Proposal to solve using empty host in dest_addr. Needs write-up of Resolution ---------------------------- 506684 Allow Rtp-Info header in more contexts * 2002-01-21 23:46 magwes klemets - The usage has been extended to SETUP. Missing RTP-Info in header table. 631148 Better Info on usage of Proxies * 2002-10-30 18:23 nobody magwes - Needs to be written up. 640298 Use cases for RTSP * 2002-11-18 21:55 nobody magwes - A skeleton chapter is created, needs to be edited in. 742348 Usage of implicit REDIRECT. * 2003-05-23 16:21 arvy_n magwes - Needs text. Needs Discussion ---------------- 792973 Clarify changing of transport parameters * 2003-08-22 09:21 nobody magwes - Needs text proposal for further discussion. 806404 Re-SETUP of transport parameters * 2003-09-15 10:52 nobody magwes - Needs discussion, see also 792973. 811815 Use of c= in SDP to know possible address classes * 2003-09-24 16:59 nobody magwes - Needs discussion 829528 SDP appendix and RFC 3388 * 2003-10-24 13:38 nobody magwes - Needs discussion 853178 Security risk with changing transport parameters * 2003-12-03 11:07 nobody magwes - Open for further discussion 853184 How to learn servers multicast capabilities * 2003-12-03 11:16 nobody magwes - Needs discussion 889699 Change requirement level on auth for media destination 2004-02-03 14:14 nobody magwes - Needs discussion Has dependencies forcing delay ----------------------------- 464462 Content-Length header wrong in examples * 2001-09-24 18:09 nobody nobody - Editorial, needs to be checked after the examples themselves has been reviewed. 810681 The updated specification version number * 2003-09-22 17:59 nobody magwes - Open, however author target is for 1.0. Will need discussion when edits are in. -- 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Feb 29 20:21:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20379 for ; Sun, 29 Feb 2004 20:21: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 1Axc7U-0006AD-Ui for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 20:21:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211LKhZ023687 for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 20:21:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc7U-00069y-Qg for mmusic-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:21: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 UAA20372 for ; Sun, 29 Feb 2004 20:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc7S-0007Ol-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 20:21:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc6Y-0007KW-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 20:20:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axc6F-0007Fz-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 20:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc6F-00063U-MZ; Sun, 29 Feb 2004 20:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc5T-00061n-BJ for mmusic@optimus.ietf.org; Sun, 29 Feb 2004 20:19: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 UAA20320 for ; Sun, 29 Feb 2004 20:19:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc5R-0007Ez-00 for mmusic@ietf.org; Sun, 29 Feb 2004 20:19:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc4S-0007AV-00 for mmusic@ietf.org; Sun, 29 Feb 2004 20:18:13 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Axc3a-00076B-00 for mmusic@ietf.org; Sun, 29 Feb 2004 20:17:18 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i211HIYG011465 for ; Mon, 1 Mar 2004 02:17:18 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 02:17:17 +0100 Received: from ericsson.com (sealwp02-129.sw.ericsson.se [153.88.142.129]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF4VBWZ; Mon, 1 Mar 2004 02:17:17 +0100 Message-ID: <40428E72.6010800@ericsson.com> Date: Mon, 01 Mar 2004 02:14:26 +0100 X-Sybari-Trust: e3ee33d5 c77f3eb6 73f6aa1c 00000138 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: Enrico Balatti CC: mmusic@ietf.org Subject: Re: R: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt References: <9F1223587A755D47805AECAB7ECAF5D908C831@swing.cefriel.it> In-Reply-To: <9F1223587A755D47805AECAB7ECAF5D908C831@swing.cefriel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 01 Mar 2004 01:17:17.0888 (UTC) FILETIME=[F0208C00:01C3FF2A] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id i211HIYG011465 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for reviewing both of you. I will fix these erros. Cheers Magnus Enrico Balatti wrote: > Section B.1.1 AVP contains the string >=20 > "dest_addresses" >=20 > Instead of >=20 > "dest addr" >=20 > Enrico >=20 > =20 >=20 > -----Messaggio originale----- > Da: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] Per conto di > Ross Finlayson > Inviato: gioved=EC 19 febbraio 2004 11.53 > A: mmusic@ietf.org > Oggetto: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-06.txt >=20 >=20 > In four places, "draft-ietf-mmusic-rfc2326bis-06.txt" contains the > string > "interleave=3D" > instead of > "interleaved=3D" >=20 > Ross. >=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 >=20 --=20 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 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Feb 29 21:06:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23667 for ; Sun, 29 Feb 2004 21:06: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 1AxcoW-0002rd-SN for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2125mVJ011003 for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcoW-0002rO-MZ for mmusic-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:05:48 -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 VAA23515 for ; Sun, 29 Feb 2004 21:05:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcoU-0005DW-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 21:05:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axcnh-00053V-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 21:04:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axcmm-0004tO-0E for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 21:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcd7-0001wi-3X; Sun, 29 Feb 2004 20:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxccU-0001uY-1r for mmusic@optimus.ietf.org; Sun, 29 Feb 2004 20:53: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 UAA22894 for ; Sun, 29 Feb 2004 20:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxccR-0003ww-00 for mmusic@ietf.org; Sun, 29 Feb 2004 20:53:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axcbd-0003na-00 for mmusic@ietf.org; Sun, 29 Feb 2004 20:52:30 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1AxcaF-0003Re-00 for mmusic@ietf.org; Sun, 29 Feb 2004 20:51:03 -0500 Received: from imh.informatik.uni-bremen.de (localhost [127.0.0.1]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i211oiU0005838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2004 02:50:48 +0100 (MET) Received: (from jo@localhost) by imh.informatik.uni-bremen.de (8.12.11/8.12.11/Submit) id i211oili005837; Mon, 1 Mar 2004 02:50:44 +0100 (MET) From: Joerg Ott Message-Id: <200403010150.i211oili005837@imh.informatik.uni-bremen.de> To: mmusic@ietf.org Date: Mon, 1 Mar 2004 02:50:44 +0100 (MET) Cc: jo@informatik.uni-bremen.de (Joerg Ott), csp@csperkins.org X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Slides for Wednesday morning meeting 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 All presenters, please send us a copy of your slides (PPT, PDF or PS, with PPT preferred) by 8:00 am Wednesday morning. Thanks, Colin & Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Feb 29 23:13:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29835 for ; Sun, 29 Feb 2004 23:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axenk-0005Hf-Cu for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 23:13:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214D8hb020307 for mmusic-archive@odin.ietf.org; Sun, 29 Feb 2004 23:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axenk-0005HS-64 for mmusic-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:13: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 XAA29735 for ; Sun, 29 Feb 2004 23:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axeni-0002Qh-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 23:13:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axem9-0002Fa-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 23:11:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axeki-00024l-00 for mmusic-web-archive@ietf.org; Sun, 29 Feb 2004 23:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axekk-00054G-7u; Sun, 29 Feb 2004 23:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxekZ-00053g-Eq for mmusic@optimus.ietf.org; Sun, 29 Feb 2004 23:09: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 XAA29655 for ; Sun, 29 Feb 2004 23:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxekU-00024A-00 for mmusic@ietf.org; Sun, 29 Feb 2004 23:09:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axeje-0001z2-00 for mmusic@ietf.org; Sun, 29 Feb 2004 23:08:58 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1Axeij-0001uK-00 for mmusic@ietf.org; Sun, 29 Feb 2004 23:07:57 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sun, 29 Feb 2004 20:07:30 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Sun, 29 Feb 2004 20:02:59 -0800 Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1AxepV-0008Qw-ML for robla@real.com; Sun, 29 Feb 2004 20:14:57 -0800 Date: Sun, 29 Feb 2004 20:06:02 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #121 - 3 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net) 2. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net) 3. [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT. (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:43:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause Bugs item #507882, was opened at 2002-01-24 09:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP timestamps when playing after pause Initial Comment: What happends to the RTP timestamp when you issue a play after being paused for some time? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:43 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:41 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:40 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:37 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:12 Message: Logged In: YES user_id=302620 Aravind has agreed to write up the example and necessary text. Transfering bug to him. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 10:48 Message: Logged In: YES user_id=302620 A Clear example of RTP Timestamp and synchronization will be added in appendix B - RTP transport. The discussion in MMUSIC has made it clear that a continous time model is needed to make RTCP work correctly. It has to be accpeted that for on-demand media this will result in slightly more code for the clients and servers. However all pices to makes things work is already present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-23 16:05 Message: Logged In: YES user_id=302620 This has been further discussed in the MMUSIC mailing list. A important point is that RTP and RTCP to function as intended in this environment must have a timestamp space that increase continously with real time. A client handling the RTSP range header and RTP-Info can always synchronize the data correctly independtly of which case the server sent out. Using a continous RTP Timestamp space allows the same timestamp model for both on-demand and live media. The proposed resolution is to clrafiy in the RTP appendix of the specification that a RTP timestamp space continous in regards to real-time SHALL be used. Further write a warning that this has been missunderstood and clients is RECOMMENDED to handle both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:45:22 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause Bugs item #507882, was opened at 2002-01-24 09:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP timestamps when playing after pause Initial Comment: What happends to the RTP timestamp when you issue a play after being paused for some time? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:45 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:43 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:41 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:40 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:37 Message: Logged In: YES user_id=302620 There has been a major update of the text in the RTP integration appendix. This now has clear text and examples. Needs review if satifsfactory. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:12 Message: Logged In: YES user_id=302620 Aravind has agreed to write up the example and necessary text. Transfering bug to him. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 10:48 Message: Logged In: YES user_id=302620 A Clear example of RTP Timestamp and synchronization will be added in appendix B - RTP transport. The discussion in MMUSIC has made it clear that a continous time model is needed to make RTCP work correctly. It has to be accpeted that for on-demand media this will result in slightly more code for the clients and servers. However all pices to makes things work is already present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-23 16:05 Message: Logged In: YES user_id=302620 This has been further discussed in the MMUSIC mailing list. A important point is that RTP and RTCP to function as intended in this environment must have a timestamp space that increase continously with real time. A client handling the RTSP range header and RTP-Info can always synchronize the data correctly independtly of which case the server sent out. Using a continous RTP Timestamp space allows the same timestamp model for both on-demand and live media. The proposed resolution is to clrafiy in the RTP appendix of the specification that a RTP timestamp space continous in regards to real-time SHALL be used. Further write a warning that this has been missunderstood and clients is RECOMMENDED to handle both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 29 Feb 2004 13:55:34 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT. Bugs item #742348, was opened at 2003-05-23 16:21 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194 Category: General >Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: Usage of implicit REDIRECT. Initial Comment: The RTSP specification provides two explict methods of redirection, the REDIRECT method and the 3XX response codes. Further it is possible to do implict redirection in the media description. This is done by affecting the RTSP control URLs present for the different media. By giving the client a description that either contains absolute URLs or URLs that resolve to another host the redirection takes place. The redirection changes the URL in the redirection. This can be done in three ways: Changing the absolute URLs in the description. Using Content-Location header to set the Base URL to point to another host. Using Content-Base header to set the base URL to point to another host. The two last may require changes of any relative URLs in the description also. Of these methods the usage of Content-Location may be the one that have the most correct semantics. This of course requires that the host being redirected to has the complet session including description. As the Content-Location header tells the client that the given location is an possible resolution for this exact description. The Client Implementation requirement to get this functionality is that it after resolving the URLs check them against the current server address. If different it needs to get a new connection to the new server. This seems fairly simple. Also see mail to MMUSIC mailing list from Philippe Gentric The question is if this behavior shall be considered a valid one or not. The outcome of the discussion should be written in as a clarification to the text of the RTSP specification. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-29 22:55 Message: Logged In: YES user_id=302620 There is need for text proposal on this bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:54 Message: Logged In: YES user_id=302620 From the 57th IETF meeting 16th of July 2003: Issue: How to handle implicit redirection through session description protocol. Discussion: Seems to be desired functionality to have an optimized way for saving a RTT when you perform load balance. There where also the issue that if a server would give a content-base or other base URL. A client should not reconnect unless explicitly redirected. This may result in different behaviour depending if the client are behind a proxy or not. First it was proposed that a new 200 code can be used to indicate that you get the SDP but are redirected. However this seem to have backwards problem. To optimize this in a efficient way you can use a new 350 code to indicate redirection but the client does receive a SDP. This way a old client will do the redirect as it interprets is as 3xx code, while a new client can avoid wasting a extra describe. There are also a need to clarify that a server should not change the host address of the control in regards to the describe URI. Resolution: Create a 350 code for this plus clarify the SHOULD NOT change the host address. Seems reasonable to put into the core specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic