From exim@www1.ietf.org Mon Mar 1 04:24:06 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 EAA04599 for ; Mon, 1 Mar 2004 04:24:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxjeD-0005Ai-3Y for mmusic-archive@odin.ietf.org; Mon, 01 Mar 2004 04:23:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i219NaYV019869 for mmusic-archive@odin.ietf.org; Mon, 1 Mar 2004 04:23:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxjeC-0005AO-2y for mmusic-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 04:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04574 for ; Mon, 1 Mar 2004 04:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axje9-0003Q7-00 for mmusic-web-archive@ietf.org; Mon, 01 Mar 2004 04:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxjdD-0003Kt-00 for mmusic-web-archive@ietf.org; Mon, 01 Mar 2004 04:22:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axjcd-0003G8-00 for mmusic-web-archive@ietf.org; Mon, 01 Mar 2004 04:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axjce-00053H-K5; Mon, 01 Mar 2004 04: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 1AxjcC-00050f-9m for mmusic@optimus.ietf.org; Mon, 01 Mar 2004 04:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04444 for ; Mon, 1 Mar 2004 04:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axjc9-0003Dk-00 for mmusic@ietf.org; Mon, 01 Mar 2004 04:21:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxjbD-00037Z-00 for mmusic@ietf.org; Mon, 01 Mar 2004 04:20:32 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AxjaP-0002xc-00 for mmusic@ietf.org; Mon, 01 Mar 2004 04:19:41 -0500 Received: from mac-0-20-e0-89-cb-be.dhcp.ietf59.or.kr ([218.37.226.114]:1756 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AxjZq-0004Qq-00; Mon, 01 Mar 2004 09:19:06 +0000 Date: Mon, 1 Mar 2004 18:19:42 +0900 From: Colin Perkins To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de Message-Id: <20040301181942.1b90cb7b.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG last call: IMG requirements and framework 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 This is to announce a working group last call on the Protocol Requirements for Internet Media Guides and Framework for Usage of Internet Media Guides Please send any final comments on these drafts to the mailing list by 15th March 2004. If no substantive technical comments are received by that time, we propose to request the IESG to publish these as Informational RFCs. Colin and Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Mar 1 18:44:29 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 SAA13430 for ; Mon, 1 Mar 2004 18:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx4s-0001Hq-Rh for mmusic-archive@odin.ietf.org; Mon, 01 Mar 2004 18:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Ni2MH004942 for mmusic-archive@odin.ietf.org; Mon, 1 Mar 2004 18: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 1Axx4s-0001Hd-M7 for mmusic-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 18:44: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 SAA13383 for ; Mon, 1 Mar 2004 18:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx4p-0002LU-00 for mmusic-web-archive@ietf.org; Mon, 01 Mar 2004 18:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx3q-0002Dn-00 for mmusic-web-archive@ietf.org; Mon, 01 Mar 2004 18:43:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axx2t-00024x-00 for mmusic-web-archive@ietf.org; Mon, 01 Mar 2004 18:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx2u-00018I-SM; Mon, 01 Mar 2004 18:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx2C-00014S-45 for mmusic@optimus.ietf.org; Mon, 01 Mar 2004 18:41: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 SAA13350 for ; Mon, 1 Mar 2004 18:41:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx29-0001yj-00 for mmusic@ietf.org; Mon, 01 Mar 2004 18:41:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx1L-0001sG-00 for mmusic@ietf.org; Mon, 01 Mar 2004 18:40:24 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Axx0b-0001jj-00 for mmusic@ietf.org; Mon, 01 Mar 2004 18:39:37 -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 i21NdYqY024773 for ; Tue, 2 Mar 2004 00:39:37 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 00:39:34 +0100 Received: from ericsson.com (sealwp02-130.sw.ericsson.se [153.88.142.130]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFRQP43; Tue, 2 Mar 2004 00:40:01 +0100 Message-ID: <4043C908.6090103@ericsson.com> Date: Tue, 02 Mar 2004 00:36:40 +0100 X-Sybari-Trust: 24a5f425 c77f3eb6 1d2f25c0 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)" Subject: Re: [MMUSIC] RTSP discussion and status References: <40428713.4020903@ericsson.com> In-Reply-To: <40428713.4020903@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 23:39:34.0180 (UTC) FILETIME=[737F7640:01C3FFE6] 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, The RTSP off-line discussion will be today (Tuseday) at 15.30-17.00. We meet at the message board on the second floor. Cheers Magnus Magnus Westerlund wrote: > 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 Tue Mar 2 16:41:21 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 QAA02556 for ; Tue, 2 Mar 2004 16:41:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHdF-00065V-QW for mmusic-archive@odin.ietf.org; Tue, 02 Mar 2004 16:40:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22LermS023395 for mmusic-archive@odin.ietf.org; Tue, 2 Mar 2004 16:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHdF-00065G-Lx for mmusic-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 16:40: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 QAA02546 for ; Tue, 2 Mar 2004 16:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyHdD-0002so-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 16:40:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyHcK-0002lo-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 16:39:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyHbS-0002dp-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 16:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHbR-0005sA-Ek; Tue, 02 Mar 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 1AyHbI-0005rr-BT for mmusic@optimus.ietf.org; Tue, 02 Mar 2004 16:38:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02418 for ; Tue, 2 Mar 2004 16:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyHbG-0002c3-00 for mmusic@ietf.org; Tue, 02 Mar 2004 16:38:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyHaP-0002UN-00 for mmusic@ietf.org; Tue, 02 Mar 2004 16:37:58 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AyHZm-0002Jt-00 for mmusic@ietf.org; Tue, 02 Mar 2004 16:37:18 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i22LavNr012165; Tue, 2 Mar 2004 16:36:58 -0500 (EST) Message-ID: <4044FE66.3080308@dynamicsoft.com> Date: Tue, 02 Mar 2004 16:36:38 -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: Mary Barnes CC: "'mmusic@ietf.org'" References: <870397D7C140C84DB081B88396458DAF578FAA@zrc2c000.us.nortel.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF578FAA@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit sorry for the multi-week delay in responding, Mary. Answers inline. Mary Barnes wrote: > 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. I commented on this in response to Charlie Clemmer's note a week or so back. > > 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. If the critieria is "minimize relays", which it is as you point out above, VPNs introduce a relay. > > 3) Page 17, section 5.7, 3rd sentence, "...it SHOULD just sent..." should be > "...it SHOULD just send...". Fixed. > > 4) Page 18, section 5.8, OPEN ISSUE: "doesnt" should be "doesn't" Fixed. > > 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? Yes. Fixed. Thanks for your comments, 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 Mar 2 19:23: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 TAA12457 for ; Tue, 2 Mar 2004 19:23: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 1AyKAY-00072G-3R for mmusic-archive@odin.ietf.org; Tue, 02 Mar 2004 19:23:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230NQO6027043 for mmusic-archive@odin.ietf.org; Tue, 2 Mar 2004 19:23:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKAX-000725-Ub for mmusic-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:23: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 TAA12411 for ; Tue, 2 Mar 2004 19:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKAW-0003Nl-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 19:23:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyK9E-0003C4-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 19:22:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyK8U-00033X-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 19:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK8O-0006gz-Lv; Tue, 02 Mar 2004 19: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 1AyK83-0006dx-5o for mmusic@optimus.ietf.org; Tue, 02 Mar 2004 19:20: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 TAA12261 for ; Tue, 2 Mar 2004 19:20:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyK81-000317-00 for mmusic@ietf.org; Tue, 02 Mar 2004 19:20:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyK74-0002sd-00 for mmusic@ietf.org; Tue, 02 Mar 2004 19:19:51 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1AyK6B-0002dn-00 for mmusic@ietf.org; Tue, 02 Mar 2004 19:18:55 -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 i230IC225655; Tue, 2 Mar 2004 18:18:12 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 18:18:12 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF627A02@zrc2c000.us.nortel.com> From: "Charlie Clemmer" To: "'Jonathan Rosenberg'" , "Mary Barnes" Cc: "'mmusic@ietf.org'" Subject: RE: [MMUSIC] Re: Comments/questions on draft-ietf-mmusic-ice-00 Date: Tue, 2 Mar 2004 18:18:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400B5.0156F776" 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,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_01C400B5.0156F776 Content-Type: text/plain Jonathan, Following-up on your second response to Mary (relevant part of the response quoted below), I think you hit the nail on the head regarding the discussion point. It seems to me that ICE potentially brings alot of value as a solution, and the implementation potentially seems to lend itself to the flexibility to either minimize relays or to pick a preferred interface type based on a given implementation. I might have documented this in my last response, but my main concern comes from the scenario where two teleworkers for a particular enterprise have a VPN connection established to their employer, and then attempt to make a VoIP call between each other (for instance). There is a certain level of expectation, I feel, that in such a scenario, the enterprise would prefer to have that voice session traverse the VPN cloud if for no other reason than out of security concerns. If this VoIP session were SIP based, the corporation might prefer that the entire SIP session stay on the VPN so that any additional SIP interaction between the two users such as instant messaging or collaboration activities can also be encrypted by the VPN. If the argument is that VPN technology inherently adds relays, I would agree with that view, but only in the context that because the VPN is providing a tunnel between two endpoints, it makes it harder for ICE or any other client side selection algorithm to correctly quantify the number of "relays" encountered when going over a given VPN connection. Given one teleworker connected back to an enterprise over a VPN communicating with another corporate user inside the company's security perimeter, its possible that there are no extra relays added to the route. However, the same argument could be made for many IPv6 implementations which depend on implicit and explicit tunneling mechanisms in order to provide a cohesive v6 environment over a predominately v4 infrastructure. I don't think any one view of "minimize relays" or "maximize security" is going to be a home run for all implementations, but I do think it would be useful to have some discussion on whether this implementation decision should be something configurable by the end user, and is so, what the possible best case default behavior should be for prioritizing transport interfaces would be. Regards, Charlie Clemmer -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, March 02, 2004 3:37 PM To: Barnes, Mary [NGC:B622:EXCH] Cc: 'mmusic@ietf.org' Subject: [MMUSIC] Re: Comments/questions on draft-ietf-mmusic-ice-00 sorry for the multi-week delay in responding, Mary. Answers inline. Mary Barnes wrote: [snip] > 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. If the critieria is "minimize relays", which it is as you point out above, VPNs introduce a relay. ------_=_NextPart_001_01C400B5.0156F776 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] Re: Comments/questions on = draft-ietf-mmusic-ice-00

Jonathan,

Following-up on your second response to Mary = (relevant part of the response quoted below), I think you hit the nail = on the head regarding the discussion point. It seems to me that ICE = potentially brings alot of value as a solution, and the implementation = potentially seems to lend itself to the flexibility to either minimize = relays or to pick a preferred interface type based on a given = implementation.

I might have documented this in my last response, but = my main concern comes from the scenario where two teleworkers for a = particular enterprise have a VPN connection established to their = employer, and then attempt to make a VoIP call between each other (for = instance). There is a certain level of expectation, I feel, that in = such a scenario, the enterprise would prefer to have that voice session = traverse the VPN cloud if for no other reason than out of security = concerns. If this VoIP session were SIP based, the corporation might = prefer that the entire SIP session stay on the VPN so that any = additional SIP interaction between the two users such as instant = messaging or collaboration activities can also be encrypted by the = VPN.

If the argument is that VPN technology inherently = adds relays, I would agree with that view, but only in the context that = because the VPN is providing a tunnel between two endpoints, it makes = it harder for ICE or any other client side selection algorithm to = correctly quantify the number of "relays" encountered when = going over a given VPN connection. Given one teleworker connected back = to an enterprise over a VPN communicating with another corporate user = inside the company's security perimeter, its possible that there are no = extra relays added to the route. However, the same argument could be = made for many IPv6 implementations which depend on implicit and = explicit tunneling mechanisms in order to provide a cohesive v6 = environment over a predominately v4 infrastructure.

I don't think any one view of "minimize = relays" or "maximize security" is going to be a home run = for all implementations, but I do think it would be useful to have some = discussion on whether this implementation decision should be something = configurable by the end user, and is so, what the possible best case = default behavior should be for prioritizing transport interfaces would = be.

Regards,
Charlie Clemmer

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, March 02, 2004 3:37 PM
To: Barnes, Mary [NGC:B622:EXCH]
Cc: 'mmusic@ietf.org'
Subject: [MMUSIC] Re: Comments/questions on = draft-ietf-mmusic-ice-00


sorry for the multi-week delay in responding, Mary. = Answers inline.

Mary Barnes wrote:
[snip]
> 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.

If the critieria is "minimize relays", = which it is as you point out
above, VPNs introduce a relay.

------_=_NextPart_001_01C400B5.0156F776-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 2 22:57: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 WAA27266 for ; Tue, 2 Mar 2004 22:57: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 1AyNVO-0002cZ-Vs for mmusic-archive@odin.ietf.org; Tue, 02 Mar 2004 22:57:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233vA8j010069 for mmusic-archive@odin.ietf.org; Tue, 2 Mar 2004 22:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNVO-0002cK-PU for mmusic-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22: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 WAA27244 for ; Tue, 2 Mar 2004 22:57:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNVL-0006nA-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 22:57:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNUI-0006cw-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 22:56:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyNTL-0006UB-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 22:55:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyNTM-0001di-9r for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 22:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNTL-0002Qn-5X; Tue, 02 Mar 2004 22:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLB5-0006Vd-GD for mmusic@optimus.ietf.org; Tue, 02 Mar 2004 20:28: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 UAA17867 for ; Tue, 2 Mar 2004 20:28:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLB3-0006d5-00 for mmusic@ietf.org; Tue, 02 Mar 2004 20:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLAG-0006VC-00 for mmusic@ietf.org; Tue, 02 Mar 2004 20:27:13 -0500 Received: from altair.upf.es ([193.145.44.22] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AyL9O-0006N8-00 for mmusic@ietf.org; Tue, 02 Mar 2004 20:26:18 -0500 Received: (from root@localhost) by altair.upf.es (8.9.3/8.9.3) id CAA16304; Wed, 3 Mar 2004 02:26:16 +0100 (MET) Date: Wed, 3 Mar 2004 02:26:16 +0100 (MET) Message-Id: <200403030126.CAA16304@altair.upf.es> To: mmusic@ietf.org From: WEDELMUSIC2004 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] CFP: WEDELMUSIC 2004, Barcelona, Spain - DEADLINE EXTENDED 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=REMOVE_SUBJ autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry for any multiple reception of this message. If you do not want to receive further information about WEDELMUSIC 2004, please send back an e-mail with REMOVE on the subject. The topics of this e-mail are: Call for Papers, EXTENDED submission deadline: 20th March 2004 4th International Conference on Web Delivering of Music, WEDELMUSIC 2004 Universitat Pompeu Fabra, Barcelona, Spain 13th-15th September 2004 Announcement of co-location of 4th Open Workshop MUSICNETWORK Universitat Pompeu Fabra, Barcelona, Spain 14th-16th September 2004 Call for participation 3rd Open Workshop MUSICNETWORK MPEG AHG on Music Notation Requirements Munich, Germany 13-14 of March 2004 Best regards, Paolo Nesi, Jaime Delgado, Kia Ng .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. Call for Papers 4th International Conference on Web Delivering of Music, WEDELMUSIC 2004 Universitat Pompeu Fabra, Barcelona, Spain 13th-15th September 2004 http://www.upf.edu/wedelmusic2004/ http://www.wedelmusic.org/ Content distribution is presently not anymore limited to music and is becoming more cross media oriented. New distribution models for old and new content formats are opening new paths: i-TV, mobile phones, PDAs, etc. The development of the Internet technologies introduces strong impact on system architectures and business processes. New national and international regulations, policies and market evolution are constraining the distribution mechanisms. Novel distribution models, development and application of pervasive computing and multimedia strongly influence this multi- disciplinary field. The need of content control and monitoring is demanding effective Digital Rights Management (DRM) solutions integrated with sustainable business and transaction models. These technologies impact on the production and modelling of cross media content. WEDELMUSIC-2004 aims to explore these major topics in cross media field, to address novel approaches for distributing content to larger audiences, providing wider access and encouraging broader participation. The impact of these developments on cultural heritage is also considered, together with their availability to people with limited access to content. The conference is open to all the enabling technologies behind these problems. We are promoting discussion and interaction among researchers, practitioners, developers, final users, technology transfer experts, and project managers. Topics Topics of interest include, but are not restricted to: --Protection formats and tools for music --Transaction models for delivering music, Business models for publishers --Copyright ownership protection --Digital Rights Management --High quality Audio Coding --Watermarking techniques for various media types --Formats and models for distribution --Music manipulation and analysis, transcoding, etc.. --Music and tools for impaired people - Braille --Publishers and distributors servers --Cross media delivery on multi-channel systems, mobile, i-TV, PDAs, Internet, etc. --Automatic cross media content production --MPEG-4, MPEG-7 and MPEG-21 --Viewing and listening tools for music --Music editing and manipulation --Music education techniques --Content based retrieval --Conversion and digital adaptation aspects, techniques and tools --Music imaging, music sheet digitalisation, --Solutions for cultural heritage valorisation Lok at the web site for other topics. Research Papers Papers should describe original and significant work in the research and practice of the main topics listed above. Research case studies, applications and experiments are particularly welcome. Papers should be limited to approx. 2000-5000 words (8 pages) in length. Of the accepted paper, 8 pages will be published in the conference proceedings. The conference proceedings book will be published by the IEEE Computer Society. Industrial Papers Proposals for papers and reports of Applications and Tools are also welcome. These may consist of experiences from actual utilisation of tools or industrial practice and models. Proposals will be reviewed by the Industrial members of the Program Committee. Papers should be limited to approx. 1000-2500 words (4 pages) in length. Of the accepted paper, 4 pages will be published in the conference proceedings. Submissions All submissions and proposals should be written in English following the IEEE format and submitted in PDF format via email to wedelmusic04-submission@altair.upf.edu by 20 March 2004. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. 4th Open Workshop MUSICNETWORK Universitat Pompeu Fabra, Barcelona, Spain 14th-16th September 2004 More details and the call for contribution will appear on: http://www.interactivemusicnetwork.org after the 3rd Open Workshop as described in the following section The access is free of charge, supported by the European Commission. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. Call for PARTICIPATION 3rd Open Workshop MUSICNETWORK MPEG AHG on Music Notation Requirements 13-14 of March 2004, Munich, Germany http://www.interactivemusicnetwork.org http://www.dsi.unifi.it/~nesi/mpeg/MUSICNETWORK-OW-March-2004-Description-v1-4-clean.htm http://www.dsi.unifi.it/~nesi/mpeg/ahg-mn-65-66.html located at: Technische Universit=E4t M=FCnchen, Germany: http://www.mpeg-68.de/location.php The Open Workshop of MUSICNETWORK is at its third edition. The modeling of music notation/representation is a complex problem. Music representation can be used for several different purposes: entertainment, music education, infotainment, music archiving and retrieval, music querying, music production, music profiling, etc. In the current Internet and Multimedia age many other applications are strongly getting the market attention and most of them will become more diffuse of the present applications in short time. End users have discovered the multimedia experience, and thus, the traditional music models are going to be replaced by their integration with multimedia, audio visual, cross media. At present, there is a lack of Music Notation/Representation standard integrated with multimedia. The aim of this workshop is to make a further step to arrive at standardizing a Music Notation/Representation Model and Decoder integrated into the MPEG environment, that presently can be regarded as the most active and powerful set of standard formats for multimedia consumers. The topics of the workshop are related mainly focused on: --Music Notation/Representation requirements --Music Protection and Distribution --Music Description and its usage on Archive Query Please Contribute with your work on the above topics, for details see the www site of the workshop. The access is be free of charge, supported by the European Commission. PLEASE MAKE THE REGISTRATION ON THE WWW OF THE MUSICNETWORK. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 2 23:59:38 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 XAA00830 for ; Tue, 2 Mar 2004 23:59:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOTP-0001iG-4h for mmusic-archive@odin.ietf.org; Tue, 02 Mar 2004 23:59:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i234xB4N006578 for mmusic-archive@odin.ietf.org; Tue, 2 Mar 2004 23:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOTO-0001i1-UL for mmusic-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 23:59: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 XAA00792 for ; Tue, 2 Mar 2004 23:59:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOTM-0000uO-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 23:59:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOSJ-0000iv-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 23:58:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyORK-0000ZD-00 for mmusic-web-archive@ietf.org; Tue, 02 Mar 2004 23:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyORI-0001Vf-Uq; Tue, 02 Mar 2004 23:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOQV-0001Qf-V6 for mmusic@optimus.ietf.org; Tue, 02 Mar 2004 23:56: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 XAA00605 for ; Tue, 2 Mar 2004 23:56:08 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOQT-0000R1-00 for mmusic@ietf.org; Tue, 02 Mar 2004 23:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOPc-0000Ik-00 for mmusic@ietf.org; Tue, 02 Mar 2004 23:55:16 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AyOOn-0000AH-00 for mmusic@ietf.org; Tue, 02 Mar 2004 23:54:26 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i234sQZ00130 for ; Wed, 3 Mar 2004 06:54:26 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 06:54:23 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i234sNXg016851 for ; Wed, 3 Mar 2004 06:54:23 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QWGXm7; Wed, 03 Mar 2004 06:54:20 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i234sJ704749 for ; Wed, 3 Mar 2004 06:54:19 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 06:54:18 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 06:54:19 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C400DB.96466308" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 3 Mar 2004 06:54:19 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [MMUSIC] CFP: WEDELMUSIC 2004, Barcelona, Spain - DEADLINE EXTENDED Thread-Index: AcQA0365NGNcM8J2T7ucWuzcTaG94QABsZ6g To: X-OriginalArrivalTime: 03 Mar 2004 04:54:19.0555 (UTC) FILETIME=[9678BF30:01C400DB] Subject: [MMUSIC] IMG Slides 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C400DB.96466308 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi FYI, attached are the IMG slides from today's MMUSIC meeting. Hope you find them useful. Cheers, Rod. ------_=_NextPart_001_01C400DB.96466308 Content-Type: application/x-zip-compressed; name="IMG-MMUSIC-IETF-59.zip" Content-Description: IMG-MMUSIC-IETF-59.zip Content-Disposition: attachment; filename="IMG-MMUSIC-IETF-59.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAFxtYzAoqoZvwDQAANVTAAAWAAAASU1HLU1NVVNJQy1JRVRGLTU5LnBkZtW8BViU TfcHrCidIoIi4AKCNNtBSko3CAKSSzdLikEoKaV0SSstLd0goIBBI6WUIg2KIN8uxqPi+36+z/U8 3/X/dq9775kzM2fOzDnzu2fu2TNsKpLSvCA+CAnb1HTPc3ISGBgABNgbW5EICQFI+BUs7dBGTpae aFMACBtVBsCg2JsMQBeAAEEBYBQYoI/LBQCDoHBcBikAHAyFYwNKABAQe9MAgIEQIARAIiICIEHb meIYA/7+x90JbYaTEFs3CfDrBwQH7N8Bdt9pcDDiVxoISz1AA2Fl/pUGASIP0qAH+SHhB2hgILZ3 fqVBEQfqAMNhwF9pEDACdoAGBR2oA4jr919pKOQPZTFORpY2aCes/kj41bGaA8DhJPyydmb2ABhW EoAaVitq9vYYAAzyNabihHbFqgmMwqqJX1ZSV8gYAUYAYUgzlImpMcLYBIWCwEwQIGMzsCkCYQSD IUX+33PoYxVO4owxcsLsqwxIwsYmpSz9RfUk+zV/NzENDwc0gF/CCGNkY2+OE8fIHO0MgAK/Sien AYB9C+OSFIyM0TbOAAjqC+0Hu4JD/2LLrw4AIRAAnGVCoAB+aUsbDNoJe7cxwqAl0Sb2ptgqFdB2 5hgLABy2zwnHyBnjhDayJSeRCTQ2NDQ0MzQUaG3AM+UALYMBh/hVQk4EoEjO1/RT5j9tNxVVWKox 6atUbLjhnVrjtdUdBzgFlxWJwvc/EaYQIfMw9kXqJMtQhQnnHbR/67Cskl0rXp2U+M3jFGhlq0Tn jBmZLr+zXWgDWiAVJTAPH+8UAUF7wvl40gCpBpYFMqF3FCiyEEoUYy6SwuOh5sdAg5BZpyJzx9gO HWAc5B6lcSz9Ed+YI+FmeMb2Nw4dOVR+FxqM64Qv4n/vDtjX7gAhUN/7CAY92PW4Xt3vXCe0Heav jldDO9u7OJlgdQGDfSVJ2NthsHmwFNR3S8JgexSAwo11RbSppZG4vTsWHHA84CAwAPEVICSc7B1+ m/KD+mCwH0VTcbI3UUdjsCX4sQAF4NdAu2P2WUljZQDgNKyhAQbAEPtyYMNQABz0XY/8Uu6YC+r7 kuFyXlAHYWHpr1QJext7J3UHI5MvyRLOcAAM/j35R5HgX0XSxY0MCQlxI2csEMK/Dhz979kQBzt1 X0zsAHQxxuzHNZxc0Psp2BZYOjljJCyMnAAQMA48jb7GQDBcL160NMVYOGPbDd43+29fBAIJ+DEO gUD27zDgt98vob++YGwJkv1E7MCA7Q+OL184Drmw3QXCKhYOQIDBP7DDUZFI1FcqLp3kSwFcEJf4 JQEFhQKAB75QLBUnxY93HGOSb+KB9xvxLYRr0reUbxcuOwRbP/iHNFyVJL9r4V9fEPA/Jn37knwp jzMhKTssAFjamQOwnW0nZuds+Z1Awo9T8b7u+DUsbdHOSmg3NXtbI7uvhieJdjZxsnTA2DsBYMgD ALRP+o0d/FCKhF/M2QQ3zJAo3ONSwshBBm1pboHBCciPy4dL4wWDcI9QLFiZO3+xERwX8S8DiBcG RwJ4IUAEDrKRuJYjvo8LJSNb9EHBZbHIamkiZmdug96vRh2DttXChX4UHfUDdn4FRggU8nvk/Bkq FcK7lJqBVFJbn4N0UiWt9OqTbDgzudJOpBVQifOktWTOc2sy+fBPXnnIaBHBNlI8+0rQvO2Ollgf Hnkur5KFkK7qB4tjN0moLt5Tx1ejksHI3Xto4WtHTn+6Wa92CICnZ9gEOEWBFyKfdxLY6NDZwHCM eElb5v1mSDZzqzA1SyMNB/EAWfe5oJnsp/BzI41N0ZoUJXVctqcTGI1jjw9cEAf1gfGdESeJ7M/X rPNuhx5nB3enuXSnO8e50dZNu61NHDnbNQfoX2Dpj8HI7elkIIOjQe1CxQaMpUnCFfXSFJd2xCCH C/onnTKLHEp6T9FyTfgY0ElfQ2t4rzzim2QTLR05JjS0K+LfXicy43CkcLfAB331XcIoq7VC3JKO HK9Ej1itdt7FtcA95aNanhxEexIEtW0PARPuEYhWWggi/1h39oxIxBCRVvl7yldmVr1hWDSvH3Hf /Q2aA//ctlBA2H+zLdB/ti049qHBCwHDvtkW5FfbEnOyNLL5Q5vaB+R/ABaxz/EfYRGLDF9xZB+e v+HZPnLsoxgMCd3PgYt9y43L++0i+THy7frC7i/mX9h8Y4+7cDCEu3Bhkn0oxGEYlvC9AJYBElvn fkYs7Ytc34p8A09cGAefJN/4/gxT32UC/hX+sQFgXIXYC5dOggvgavy1MbiWf0PZb8wQXwv9CKQk /xOO4mr71ssQ2H/gcLA1v6FCUf8DDn8zuV+sHQ48OAEEHzS4v2YCWKsTA5gZ2TjvBxUBQD4gCIVC 4lY1Kt/p9g7fg8oqivtrHvELYAB2+JgZudjgTFdTQu2nuMZP0R+l+WGWi10OYbFUDAeldjhZsAVc LU3QahfEv6MtGIZdAPwB3CZGe2iou9G2X7d/nBweVdRsQq57o4ggHGZjFMF4VJVIlugwtbjMIL6Y JD6NlKRfThS43xYjrSyVxFdgkk/Rf3Xh2ZEN4MIcspR2IDSJDnkhSck86/nSmaUt1Jbb0tLYeO1W 0tqhe+cyc8peAkkP3e6/1yMX0kp7gsY4g/jQERIA3rFDYI98Pl5BZsKJyDb5okujxDvByZcJwy1r WRQ6G4DLe4G8A/Pkh86fQhJy3C1zShR0LMhBzClsnkr0yIxiv6V6/O3KUcdy6EOr5NpZrxnUcAvJ bS3vEk7zJPF04Ipl4sWBU1FI1gdIt5cPojaQBq1DmZ33Vad3RmlyVTutDp+fZ68W4+RvH6I0rxI5 J++zhneoA/NSUG+b4vRdcoLnmWdfVknXXtK0axh9wxTLAdUIYeN8m3uXwBcowV54d/5EbMal9DuW pw/H1q8lIrOGjd0jfKVSGxvFr5/pE7y5XZhQr5L16unzO92PksV2SO1tRWcvCpPccKctfLJdUf6M 91BI4dGG1RndhK5Ph4ArdYx1H55e/ZDlwYk4iTGqq9vY2BCxyhxt1+hFbKdQ1J9fqulpx4wmrBo6 doLjHnbeiFtgLyzIgS88vJSkUNDiJ8o4ZcD4Yc3D3Zyz665nJm1YR3O2Qr7m5GI/1wsClzJades9 9ePX0YPKUNGBykqTwsOFg4RFfKuHVitID715dkitlHzc+9U6b1QkIXgZNj75ame0h3h7S31S5Hm6 Vn588B3TN4ZO6XV213rWdfDw7uGxTxzmNqRM9BakwrtOhdckBg0gfAxgfH0Dr4imQwzVe0j4PiHv PUaMN1MRkw1es6HgySPVjdccqEJ8wxqJly84MHkRF3jrGlIr+PobEgjhFwKIWMTIAkh1xCjCuV/j f5Qw5qAO8ldL5bl/iMtbI5wWLM7bS3KfcMH/Vipjr93cVq/q3FEMRdXRq/iKYpT3lu7FAPGeGzHZ EFY31hWdDPVWn2BwJ87zsZ5grzx+mZCyMX1Z5APQC0+E0sD33KT/Mg8eFX3TBYZjzCzSZ2UE1ALu MntmnJiXJohQNRV1IkMF64mxR1zoIL0b4KRKdiJt0oI6Prizj770xKKUf5/+nNE61BM/Sdy8d+Ao QWP0hBQRqwxxMBGXuHBqMFBmUPZDgMMth9tARXe5s9QfJQ+D/GIleQBaVAmBtS35LUdaplvkW6pb dKgDTaVWWaTCn8mCI71fSA2LD1/YDsHEQRU9lbIiGDs+vz7qxKwj/x5AGbkVLspmwD7OWp9WxFFw FygnICVmmbGu2sbRzkHH+fzuRQ245vnb92ZUuO8vvmBeuLZwasF24Tj97RlJ0kz0sxelb0qZh5cs Up5nWfDPMVSd0xfnTzs9/3buzLOw5/VpokbAk3YhFtLMzQ3a7YNPkK0f4ldGQ6xnTNhh6rFlcbdj GeHVNpuxskZVYJNY+TjFbrEZ5hmpGVbam2/aIotM87T6id5yvCWwjn6CDh6ctyGvjqn1vxp6NUVi qtJxCkWidG72yFPOp/p8TS4zcpVO70nen9wic4u/8JrYXe0yfqH/lu6ro/ZtiSZMFsnmrwxFjD8H fjx7ZrJ6JXOH69qZPcCewF7mzSSpkJvPjG+3Xgvuou3hseVJ542KHosm5CnUqSttypvK58qHa9/W HXsonS+cD8l/m1+hk/LwmmlzCXFFxAhmhKH0kSXpiOew2RB85JrhlUbX/qev+PqUzCta398dY71S d7X06s3dG7vZm5QMlRQRFFb+h/17GD4HxZmAtE/A/ZLazBhsGe8w3A4VZDjHYIAiTnRKEkikQI45 ZgkEJ3UlEiYqC/RUIiszHpVWvnN5NC/neKI6utrOVfjtdrfiRPRSeaft6GJdgxrgBJR4k8SuGjKa Pmo9emGs0JNKuIUpiklXuG7dT9hXqEv4ghC/Z+PlxstWhfmXY2qIX6W+urSkunRavAoorX1ulDtx dfJTxjbmQ8gnoU2XFd71sYkr/VtlBuEGUeOx47zHLtzlWaBiPH51dmmef+vMSj19A5EMkQUpknrZ 9t7Fe2AH3YkU30oxS7FcHyWCXVbkWe0zNaIfxALkZWQ7rjAjWoQcb1Ve3PHgYIbCS3nXp3vpjBqN bhX5Gl2npLt18dYScX39+aLzjwxtGseIsol0WkIDHsvwFJ9d3e14jLVBnRcWLxB9T/uC5pL6toyF jLmMN1uFQjeCX7Zfo/mkQM2uw45i8m9ha3NpV2xxnnKe9p+uV3KQU2F7pxgrSyZnoySULCkjJzsc jpGwOhcl7yZvHikRGcOWopSabZpNlu11ZyEuR1k4miCbLdtWobq21yXVddJdQCYmy16h/g5zx/3H HyTYQRBW57Nr/DppedF5JUOj76beCQ8pOxs7bzvZvamapXdWngGtBa26zgp3hXUt9aTova62GEpb w+/HX/BhvZnRVNOUdLMkeJrO/pKQPo3GC03M1UBD2eZIZ/n8GC3e3YxYHR5uEQ1xjsf8Q+qrvjz6 cK4ErAnWXRRgjelAdJ3BLkuOBBF2EqHrVy/rSOpcH7qq6WeVviDmofHR8CNrmaRw3udylgfGV1pL Otc7Kbmv53UWCtxjtpaDXihjsM3cxJRddZHYYEuKKZBH6BzXKnlgJp2SNq5D+pLvgbDxxKSoOl3I +7aotgdVHVURVbMbHhv+9IPkw7dIbyfftqZfgrFBd7NO2UYjUmwcbSzt4y7Rlthc4H5xadiz+Mmj /BJbT4+pVf3FF5udm6IuH1zW3bzqWa63PlSqfvomye0ie8HoCLo/c6nqIZfXy82Xc1YbC4Gww9bl eR5j+XOf09oLzYtm/S97LNFZS1n793+uLLAZkzRwGC/faNkY3hhASNoOvux5b79QXw2ynZ48bHPv ysQnxdaEp+QEFHbjCmM2o0Kou9vKhzIO636OrYw7GxcetxNvEf8yQTyhMJEhMTBxK8k06Vny+eSC FMaU4JTte5b3BlMvpJansadFpxOku6bPZGhltGciMx9k0WcFZ+1m22VP3Fe73/IA8eBBDkNOWC5e rkvufJ5eXm++ZH5lAW9BaiFtYXDRoSKXooWHhg/7i+WLm0qQJQWlbKWJZcfLgsoPl3uUL1dYVExU 6lT2PZJ71FQlWFVWzVedXcNck1B7ojasjqTOr26v3rN+o8Gh4V2jeeN0k0HTSLN284sW1ZanrfKt HW3Sbc3tYu31HcIdNY8FHj/qRHZWdMG7yrth3WVPYE/KnsKflvcgeip7Ub1VfUJ9dc9EnzU+l3ze 9kL2RddLpZd9/Zr9gwN6AxODpoNzQzZDK8Ouw59GbozijwaNUY1Fv2J4lTbOOV44AZ+onZSc7J5S nxqZNpl++9r59c4bvxnymejZM7MP5sBzNfPS870Lugtv3jq8/fTu1uKxxcT3HO9Ll84vdS9rL79Z cVrZWw1ZO7WWvQ5db9pQ2Xi1abv5aSvow6kP9z8iP7ZvX9ye/eS2Q7gTu8u5W/VZ/vPonu3eHh7Z oS2/tU8Hl4mgv/F6D/zr2z3IP/9yD/x/7t0e5OALDxQc+icz8FLNEbtpONXVgYvd6kZHoliCSvk4 LwESbOh0oCOAfhGXTwD50icFPFVnGc/Vq2aPF9U/klCjcFIdPjvWVMSpw5DcFwcxpwh1ISkjmBKp eu/j66aOR8pIRUXVS1MsdJM4mLl79SQN5UxjAhjJ0XV0K2YNQNCZhvTu5QfRyPpdUKVnUynwGdw9 9ZC4ddxnhgJvL8QkpMC3V99Mxc63b35IsHLiup3fFPerU1eJTm5PK1Op34/RrJjw1PtsFDHEFEej GiExR1eDPlXEwtJ95Hne+W7ZhfDgFlbd3sHGXVvl4MZr745TRyDPuasnr+uoVgxcZuO799qKTWCo sxXmRe9YO1N2f3iTHh7vm+ir4zQ4KT96ozEppc1QktX9SEKZBH33uXdGjkkZPGUT/LIRo1lIx8MG DqTvXmlszN6MTCjwJqk3fxbQ1Uk0NPZhjWijtC+5nCVMBs+Dnu2RCcWavHO/r4iS/+CgoPdZdtXO 7Y6rL3ZJjg9D3NFMRavAOD9T1e140+2GVNMmsdpd+DaAnN04Osp7LLrZx03vkc8qd17+Ye4OziX6 AuhJYgiF7qtyla6C5vaaU/6y0VKY0rvDcwkrS28+tccraDMZ6e9R6lCPww043j2NSizzwldXPzUg 1Byl9EworZBlgFAkeHQ0ycFfd4RuR86CtQrfJnOb7PZregHL8+k8Gzv04RtXCZ+gRzrzx3LeuzdS TkCaRAKd5eyHAC2pOnHcIrNBbmW+bwrcRXOtWq+0eJpQ0mfcbBt6azF/JCXjpvs0Uj8/qqalplQ1 YdjmRb7+SZuAz92filOhYZGvTxV7xEWcuAwiq/2o7UpA7G0Q1ZBZ/HI7QMRVz3KpJEwn/nXHrrX2 qrdy8LmHD9NJ+U6U05e/BAi4Dr9O6Ttz5FOs+Qf1qUCUFX2GkRtP3yxd6hTvBXiifzJ3Xb395oux BlfOhTeXs7eJA7cH1jwdODwhz8uoIddu8AJUdp1u15ns6lBaebPF1X64Rds0Wg5hMCNZKFcz5rNK ubGBIiC3b2W7OLB1aZmKgLRZm9aIMZmv+wbLduz1twl3Kur9Xl8pkp+iW4jBxGbzhIE3U660ge5u Ezu+e9wYryuIanxKpAM99dJEsPCCXB6vpZtO03oWs/Bojw+hxmRNIo3UinjxpmqP4/grymyCjftX zkFzFqCerMvvIys4yut7vR5dnTOLbzhcUa5OUZLC/cgnC3wi72yQoXbYnYyAWMW5BI5Vb4nMV6Aw EYYhVK5UiT35BwqlHn5DdqngwmK7vodQjXKjxSH7roncQ0cObccXvzgIm39rV+RX2IT/C3si/+dg E/4b2AT9GWxGj9mNwGnalzZoZnOKvOOOsS3k0h2JhM4LlepQ5dI1F5PqpBnb0aLDNe4IXag2n7Pe VIkUneqMozOlMgwCU/YYiCZTJiW+pXIiL63F8CXd2YKQuA2nAhpWJAKmqPBmms4G6auMciaVvEDJ qlMOZGdO+/QEvG3MOK0nI+Sjiy+SCsqImi5XJib12lHcqdyYFI8fua4XI+a5FJJ1Zrw5s5PrmkFu /bjP2Htzh6sddHE1056Jn9HCxWUX4sPP3pJFTNyVaqAW15ntCaPGnPDLb27RFZRE7A3e1iuKuSpD 7GISdGdd/9wtO1N8190z+QVD2SVDH92bZIBVccn652unuCBp0SrwTp5KH684TlWSyzWMe3GfrTY+ JonUD9DdOsrcxrwicJaDJ0SnMM3kYW7YpRFGiQU16uJXxRXxNvgVFXfLBROflqnq2LlqOMU9idFr roGT9j7Rm5XrRtV4S9uZo1mdqwV0SdYGcwd9EyXPkoRNJO4Jvnu8PXdl+DM7UcE1+eyYetGeSvUt mocXWKk9+c+PnmbyHby9iSYhj/NTEO30SrXSQdAflyy0eoCKHf5cQQw4LeCrJ0x7fFNOL4UAtFj0 ajmSm885dDhne03Mx0hhh+7YOzJ/oveH1y1iND14yWPMumWQPuKGLUEez5PLX7dpHapkTKqvrmKU yFq9CRRC3J56OzrcHHO2Ze3ysZSKxtmyt/ytjAIDgJwoAYWeC8J2O3ietZONH9L7QkmIjMq6nS4z C3dYZ4aT8Yf3I6S9dMGO63btzSS7sUd7OBmoB4YYOPkEeEI3pnYkpnw+eHhJTAkkpIMRXk53mWnr ibgKXG49wT+7yZirLmPrrnVe38cmB8Wu6CjI7iv7tv1hrUer8Zx9kNELtsetvouoFaLnEh2ClVpl D9Y8iWOaBod9pI4lYxQ/aNN5BRYyfxT2IiWSeuE7FvAIJFa6J6xxpbm5rxf+pC9GR10zzrOUQTRA LrY83Fqw1n3wyundE2FTXZRhbgbFx0Gp7v119W82JGZP31g50VwUT/o4OGWCPUlfQovG/Zl9wzLh qAHNoNI9HfJkIGlRQdGA0KSikaNg48WyHKon5iNB2cWj3S+qLlv3ekUZnZGMWpzxpWavPcfgS3U6 MN+k/WK17aALJ1i4VkDKSi04balhuLO6rrGH8GGLSAinnYqO/Op1qrI9NFUFQb1pMUdCJjnzWmXO RnnNYBKf2mw1FgSfjBTeOQiCiL8BgshfQfBf2BhG/p8DQdTvQBD4JyCYF7U/d7yFBUFnzQ4LqWAa l4UxAZGG1hwi47IrfYs3WfqsXWz7MjNMxz6JiI9XSMiVI3RRAc8bblD4mX34mHL91nSCwI0aAqtr Lpd1pluDmrKH01R83uBTSR/+MIp/LkRPpemS7p0X9NmczUvPy974tAd2Nczb8bWEqCyPhruTPUt6 E6/ZdJWy8CFdnLBDnwsqA3UrOyx61+gOTCWQ/8l4+joWYs/ceR7bcgw5Rm7gkXHGXYFjqfiKUUjg bkNGmE7MZfPyvb5Her2itVjQYw3in3/hRHb+nigkTEN9x6wniur6bYYUFd3zJcfCK+QCc7zFZxYp ziz0Lc0rx3e+vV+TzJVBhe8nRUAs5hOwVV01Kzq0psLoHpLGx3Z4qXk7nCI0eaJU5WSdAq3Duc82 8mxkJF6EnpYFxUnudxcgPNku9c0IjHbEBMyL/T041Y09pJqL79V4wyUubS33MbQiZ64NqdtaghFQ GmVUyPz2iAELEyyz7KJiFr3qeZZcFsGdQ2lcvWsisuAo++13yklt7jI7dKcWiafDR8ioISlWLGZ1 yiU9eMPCrhp8btq9ePMLtR1dLnGn3yyc8ZciNW4yYLtE565amix/hUtTR7Pwpo/OBqDcif+WrPHO nXenIpkD+GaCOi2TM8bg9+XGGjRsughTKRxyTVmdH90Mc9XSLM53en6iaGlANJQgTrhT5gPDGtvG dkPXxLt5IGi0ojiPPjvi6WXRhpzaQmfNV8FL16MVH4mcZ1lV1IrasOv1ZqJcf+d1nFTAQHF0rUb3 6TMUAK/8lk+EcixvsdcRp3x/A96Gt21jE3VKKUxLYpIS02vcKjXH5SzwIt/JP7J2G6TgtUvUxL9n LJ66peFqYNc1cygM7WsjkzXRPCXutlwgMjBQQVkzysg4U02oQxvetXu4fYmJUUcrhYwXvnI5tuKS ne7z+uYb3azvUA3M5dh2Zq3QVlRMvxQUUWJ/TNI9D+C+f9OTwzn//UVydQbBhUHU7ox7mvrVROf3 x6AU6B3TZqQ4V9ria+oFwpgM2HuXqhFUGN20NmPvgCh9020BZ6Vi+gssxuNsD9Ip3zQk1++xJZGf aRQ6XzfwYqxl194yYbqFRvncjGwrEWr8fAvfE3zyOEsuwSQFwvzZ6sSWnhSGvYjssEfiKfOFd1Z4 9HmVn42aMFag2e51xJO5UpNv3UaKdFJvr5yec366zhJo9mCjEAuAcvKJT36zeAb+DQQEgX6FQBD4 n8dAEOgfAUFsGA4AI7+FkQAw6h8HRxD4IDoigH+2t6XRZZcOpBlbO+EWF+IzTUdgNtSukR+fozaY qa890d3LHH4YrLp3rUARUFiuJs3zrkVEZIspZXreJR1ge+NRoay8vSfCfLlk5eTrCWJ8owxAOM0O ME3ltP28PtsrqCzNe+VoJnzaO0i8+tPL5h2LkiRKTUSRJ94XpQjHU8udSlNDpONF5iPiKzbYbRFl h/XNZIoKFE06tSo8NEPvIPw+hfTKsLxvm0SeUSIaI35J/d7cDQjJf4rJZQxQaWu86EfoffKGcCgh hbkYIqtjL357zGeHMee0ZziDCm0p8vztViLvwsfNoaGXZdbrhZQo4XONm57v7vGz6ke/zFJ4cvSz TTgGvIl/jJUjF25QVx8yZmS+eO1oaThFDSET5grzwBuNCcKzZGgo9PT6k+JBy0+mw7aae64znDn5 D1J7l7Ls8p7Oqb2q1pDxWf0wdp555ih5IR61zKzqFn+EBa2c8TFy18xzU1XWH1XfRj3MG5/si4wj M9M0I+nySHAn1Cmer0qWoPP+uHG8QHjiHXks2yheOtC3lftmt0niccuulhpOuV5KoVAZQ1a3DdsY 1EedGVPJIotW2QZlFkQHm6B9t0L0W8tLUby3yMDPM1zqynWs2+rONhJtfyJpBgqUxo+bu7pdjhHm vvLys/iQy3MNywJdGhOX8BZWYSRacvEKTTZvMqztpnUIsdGGwFL3ida73G8IThltTAoTcb0zWS+r 7Ds3RSLrmB0SKJDfQAJuiX7EYiZQ0Wk1+3YE/PKtmTqZ/ZCj6rFzelc1X+hwRkq5UoOoz8SA5az0 4W9z7CYfFQxz5QfFqPoyL8hwVoWmvqWdu3bXWwX/qTODfMP5VSotpPlcPZWBPU/2csYwv6xLKVTU Im3LedboVFu/t7tu7KC8IgPQq0CKYdqWMHr7vlj9lt658rkXddeTG1hTbliqF1tvpGABBd10b+83 gAL5O4ACPQAosH8BUKD/FKB8BxFsGIugEOA/jyiwg4gCAkJAfwIpd7UU7adkqGo/XXwRkSf+fHxR xO5GIJjkGHX0THicbzvG7KQ3o5F58aelihzyW4Hepjdfl49iai8aFHpCC3hpYAEfcoPBp8b4ju7c P36YW+YufswlYHxzbyZDObOHnDTGrObQ07trH6Bak8+vEAevHEn+RMZwzdtQr4mbiALivtNmFHcy NRZ/UaiE/m76Vf6T8RdyEdfZEDrgTvBtaHG2n+9ydzbQho5COrObc0nsSleen82d9ZVAUfNEUkId b3jxgOnym89L/rnvLoKfRPreYXHptuxtA1kqO8+DwsWLobd3HB8F9JyYpKQtqb7iI13x+hVvJrH1 IB9DjWlHoNdIXEahQoKFambfFDCextSpsiI0VNjvYmWCWcqEnSvptNWaXlSqjZU7kdGpaOGYPivr 6ittNrKPoRHiA7zmar7rnJAzcoG9nBJBWuCSrnZdv4DT6mKyfZKfHIGkXZoiXDnFYlVFZC4P9YUR uTl5hbfi4w7rXe0SuZP9FCVuInRCxtDJoW4uMsSoo4tN40lP0c2aglzjKIQRcULv666ax1dUw/UM yV0/51S83ywpSLsjzin3BM3PKmbEmk+c1px16ZZLmO9U0LOrqLn5uHvct/H9FXs3GmThNBxj+FzU 8W+4g9wv007SZ6EjRAf43yZOvToX2zlIO0u8aWEZ8UyeK1ZU2Trcdq34WkE5eXeFpvqJl9tv7332 LGNtUEUd5Wpn3SS45e9Iqoo4++wYdYYveR1p3sXZs6q654aZykt3TawdR98LKlq5BAic5KaF5Dzf 01+X1maX9fcDH73aPzQZQTWZYFXigKi/dcWDPJVTu15qpVIRlqZizVXwYJXjlD69Rs4DTOjqjTP+ au1NDUrRHJY+qtm2oXkubMyUmsNwStkLCp3HN3tKdxj7XzojdSkfsLyxiyOaja04F2fxXka9Jnsv id2JCjIvyFIS41LCtVrFjFdpGQJ5uMdYMLi3kiHcYXjFibo/d9zoE3+3+FrJwlumCIRhDZIltAs1 NXdv5f3YhwfYtfEbQc7BLSCLxV2aNcL56BzLE9VWWsrmgclM2WpV8LnkSaBWtE/oHRI3fovoiG5Z GrOXnGuPZNk2jNT42NdW24lbJdnauA9RyNrE2GlcZgeQN3eceqeUPc4MGFFFxW1FnGAPISgIuVrk trsaDr+lN1724Q3zGEvPzPORsfC2ajkbz8c1cHcLA4xgqMRAukVGmxqC4MjV+Ak2NrFj7QH01h21 JRqE00WX09Xsr0wMt1n7NuZsnCEL2wz6bHh2KWuIs7vcIt2V/L2DlU1X7/rV9k9UWe0sxZ8sPO8H FYXkOy3REmyQNY3b5Ho9oruJeDh7NGvnAr+D9GnJe9wZATx8Bsy6H5Rzr1dVv7iOR3ZIAeCs8Btg hv8dYEYcAGbkvwDMiP8NmKVBAMhXLJYG4/469xWK//VFMAh5EJWR2Kx/uIMygtzfQamjIS5Kk1ow fmBfe9ab7q2Udw7dvUFCrTTG8sj7kRi96+3leyPMbF1K9Pw+lwHakWxP4pxv+UNKzNl9Ow9t+D+o MnTdiGwaPkpz9qgjwZqQLzQQkDh7zOJYnk82Gsgtf2s8Jhfgg2Q+5utQKakCFPduvVt0tBMesKMe mQFKDkZuoZaN/MK6OsdVjw4TmAe/OXE33s2MDaqHQaSp1iL5RStNH4uc8rn1IfhGFueMLIl4O3Sl poHMcmaNxqZjWt19vZCCE8+NjIykTW1HXUTU+Ph7e9DEGWarIhLPfDtT3hsSmcNaLr2dSuU1h1l5 7p/osMvEdOW3XPzwMZw946zZcbiw4Tmm6jeMBqRF6ZemHRJ3WPMO+2cRvbEAx1NFiyUfi75Sex/c dac2fgnzzIcG1bbdRaPEKldsGnLGhPDy/GKru1v5nFUfqZDLZTQvvQcrNLplRY+ky9oOJeS09FS9 iSJ3gNt28qaWlmYOaq9i5210yFHLPb8Q5p3SEHd+E23Ju5NHO16+V3a/7eJqvU40AbM35V20YxfZ Ultq6NRCMu85uo/fX2B9dX1FoOd4ZHJZ+qBq1+vz0ZDIXSbCLJGJ28/OoCsI7LqzFrcIRk4eto+5 Ph2U1xuwpc2WFZG+ng5jalYeiFXSOmUBbiDRzx1uIFhMc0zAECBCNuHXhGYC/BlWYlmZ3nVEPnCX CuUPGAHEijxRcnQBtBM5ij37JMMUhILGnCt6WbMUkTzH9SpB0Xddz1awvrcMGBW9qwpbolJyHmi/ dms5YNmhSXqdITjgqdeemAbtFf5yEtMlixFrR9Glx0mOqjtqbmaEbrQiE3Lceku8njTu6fiFbgWx xbls5V3km+2tzuM1/PN1bsoUikUh2v2EAhhX1O14QS1Gx/clC95rOvkfO289kS4Tshm5HaHJMeJS Od6fevKC4kkpt+wn3o70d9b3tl4ELkKlk18pDb0oXtV1vhCsfNqI52mSko3RI+3LlUlofdHy6suH lEjsjzhCOcNO9ZBGila2jT9nalKO3rTIeEJYD3ca8xDXsmCIyFF9y+hZuXrVmnuxDPEucybfIeuR ycBd1cie4Cm3TXUGuVqw9tib1ZddrZD7BY+kiwH5FnsOhnToZcUbhw8pyIg//Q3Kof7ObjDwV5QD g/6F/WDg/09QDgz6DcpBwX/2rk/RPuE81a2lnSDUsFqDF8/J0I9Od3Oic27d98/yh+Ut2nq7uMVo v8/M/uz3efwpH9wuEakY1VEMCojziPWYRWMKqDlojm6mB7Wd0h87WqSidIghkcPbMf68gpdD+wPK SJTzLI+btAfT1O7H0RVmluQzPiOMXh3ilOpoztdl0yPyTIGsO0/SXtA2BNedkbiMLNgNtux/ajis FU+nYdnBZvtCTob8TEZvGtVL4J4VV6R+a/iNYIMzPsj1NuLwblKZi/z05tpcSjaNPO9I4i/V5a+O ZKw2egnc5SEzEXrMvwkULGiRHk28dkMNiH+7VwWSJcZ/Sk+5sIhuXJdP5wl9vs3wueDqEXq7Cbbp QRrPU6FSARSWSqlG1vcUiW3T457l+b0slwXGpLVBIxeMifUmGcm5Y9U07K7Vhi/VH24WNrQ5IkL8 8TaC9J5c2Yacc99JGt7z+dqNlq3XgR+QT8YefxrZKZZnip1itzyZzRQKU6wpUqc0ZuccenlN8oQp U2f3IsVV94npO+G2Xj211jOhnoteTPdq3nsEpmdqorMF0oPogPYJTTdY815N+DYkXiST01r5lCpf 49Dw2uwD2/WtQ8LkBjdf3TwjRem5bhvz6HLaZy4l81GV5Inl+SaOCPrV4xzRNNlhY6+SIfruhGOh O69hHSPL2eFj/osUNtWEZugsheeRVkEkdkfLh/goaUq9Tx0RUL/0rMkinn5jlbrCWpB47qRKRuqT iiiD4pjxQdoHV+iGKJ+EdElvlR9ji7vwrOLhbYnQbgI9Wa8ap9tdN6YiQ6I5zo76Zb2+X0mbMrvd FD98dtBj+Bqfxb3H8jOrJV29n5Ynb1QJXYCh4wgzM5wXtfLvP9Ad4F0Yf7PRlD/yMshy4Jx//4hJ JGBjypwzjCibVKjg9DNr4YV+DEuQ1mR0WlQs22KmbTTodG9qGLflbenufP63n3cdKzP9/PYMrymt 6K87LhfR1Sg6sfvBfS57F4kE2FPdeibNLZlP5x7az6rjURR1Vvayr0V6SkVE/cCb0qnggtz4x/GI NOpg8vt2bw1t9dowGBbLJyGxlJscmyb2DOih03bP0ulI4tflOGwYnuqzsDk8sao8rZBdgRiYZfWK GSVXfNo1+pG14RANCew3szcw+O/gGuQArkH/BVyD/FPLahDuz/b/PJxBf7N18Wcr6dLo71sXR2g4 XpOCWKTeOgxl6AzgJ9Jb40v1rftEzEvedtFWlZuok65eqpZQEzlvzXbYlbT5Ia/M3g5k7QmQ7iKX n8JhGH9U1NNWG6lJMRSNk4MPVRrSj3OrMdj4DP28TWLXi0cy6re2sk+3+984nuJtLuolczKVyrkJ mXFzOiHYT/nITsLRh8TedFdrEs1CK/a2pyrXWsnsuoSO59zUdCssZq+PWWYd1bCtG2oUNwtL69YE ye71r8w3HpJeXV48kiR9VGLZr1fEnYrtpBt9/BxxSZ+L4bjfzqj1Su3dazr+xCbqOxGfR6+EdB+p z5in7o/SUNHipVEr7xWR6+0//fFB12mdjmJNA50M9eX7/ekPH57092ttY6EnNamjvPLqhKIMdfqN j0gLlZTI8C2W2hsbcoq3Wrw8HD9jrg/XBYy1TJ/FvGxpztYr5BKTzVzN0dCeqhq2W1s9DIF4PFCw YRt9JHq+zFvpsfR4CW3+DeUkjpGasTFF9uuZ9aGvOyxkllfdQ9PfnDk7TFp7ru/Bk3XpTlgAdRX9 olySQp1Y2qXu49Xow8U3OeqUJhqOkV6l3lNmwJ/xHs+dkaXT43h5ouxhDLcFdyWdHN7nS09iHHZD eHR2PjG0PTIOfLijqLdBP9tpm+ffHvjmShE9Z7+gOw2JVkVMbm7YWiBdeEttTRtf3uRMBebzJOUg Bp21GMybdqQw/Pi9qOUr4c9Jb985/u7xfExPXk5/eOrs6I2SB/HOZLcHRCdAgZdz96qTdFMvxl3A QuBq2qV1nniXz2F+3tV+AM/uYnOTPcEAxUp79wHEHDNY34XXVT5COJAQ1Usm29I0p7FWn2p2srWP eBmKVDuubYVxnA0mllAyMzckshH2qWM6dk6V6O5KM5Cd6EG/xFs/peYK7rw3SmU+fgoXBgJdbHMT g84RnxHVM7qofdQjEJ9OR8tFO0XwYtj9VxyU1AtZnQ4JU1oM+H6fDhPsuorkPZ0Lcco3nT/pbjR4 ytVG35XAHyCr5LB83HnA5SNPhabw2cMjx6Teabznpc6r2GXvAxiiSPWNrnrRFp+YCdDpsv2c54aZ 6jTzRxgOrfC+r1hV1EbKdy97UWpvXjIpWj7CE3JG+tk7h5cvXV6WNhNIVuo1PycIIX8jSxrabKKM pMs1scrYE8zpycsg+ihw3HQwYVqnPX2C0Twp//nI7HDxgwU5Zi/kSUXu0x26OhN5PLQVuR9f4od2 O12DlDg7JQkYHD15yHbYb/U3OAn7OzgJP4CTiH8BJ+H/x3EScRAnoaA/8ocsjeizGgHS4HByDy3/ kPVxscmSkyXxTTYarg5Fe2pWxCsbThk58RSTEd935Oc4FSuiVdsMiXSfTSbuferpM53hKqXg4R2w AseNQ4QEmnp9aU5kudxUUzF9Ht/E9SwiLFIh4zWzgatfGhXqTYfSaanmNYBmlAc+ijre5xFH8LJ9 kACzePgzvGK2oY/uZ+nkXVo6B/krN6wwcyGtVqFDrra1xTGrzn5BkLukppPphrAeeYq+1wpnAVNB d++4RpVeJBG0dm3jLD3XeFm0yV6zgcwX1TYCKv7U8XlZwWSWac14+OgeOqrK4sMDUlMe/i5LYg9G vtTT8drj457Cp0kyE2MmqdcMwm68fLDuCvIvtV4UQKeui5GbZaeNpjCa9gQtfXD357vW95H06sMz XuMFSe1l9Nu+xcqVJW0J/WTuldrWtptVmunPRCigrWf49mKax2dYLzO8irv8qTvBho6yctxez/rT 7apL9ONuytr3l5uq3KYNKrmc2j5ftbmb6VOY+zH7VPTMvTZFdziT+jVgiPSnxQoOV9bHyocJDlUl Dqf+ZoQg/xkXRTDoVxdF4AFv7W8u1gdTf+us/JPz9/6M55sT+F8Mvnkb/uzZ/R/98r76Of7iWfjN te+rY/Zfjt9/4lH4vzpV7zvzadpZ4saNovpBrz4I9IBXHxj1z+gIhPhXdQT8jTMn8ptX/fcU+P5G 7n9g8Jcf6o+ek991tH/HMfh2YRngfOW/6QdH+h81wSNub2P6Gy3ADmgBAvybWoDCftQCDPajEiBQ 1O/MFAn7H9qhZG9taaRuZOeM5Yr+TVPgB5vyJ37J2F/QH8sggX12WmKfCj/VAv6XauH9orMfq4L8 Td2AoIifhghWHT9oBwoEfblg/4s+NIws7G2NfqMIxEFFQP/cpx0EhCP/i1M7AvifndpBQOzAwGZB YcENjvNxRkB/59X+Iyr9iXs7BPb/iUc+GHfaAwKOO0cJipUdivyd7N/G8e/lBkF+PoAJAv9f+h30 X0WH/pd+RyFwObA9DkZCvzD6WfRfh+4f9Trif5Ed5yT/H2UH/pdDNuDYktgcSFzf7R+E8KvJfDfz PxL6p2mGOoBf8ufkn55wSi62zvtzZ8iX3aWfJ87Q//AfJWdsTN7SFFcS9uUZ+mWG/CX8ZeyBvsz2 QV+my6AvyAj6snkP/jJLBn9F/v15vL3Lfif+XP9P4CmJAXBICoCBQCjulC8gHISAQjhxZzYpYumW zhhLGxu0E+dP5b/BIr+GhaXzX+SfIExC5afiWMQCQMEH4AP6E3yoYVsOwkry5eeXTvtpqMppSO9r SlH8N4sXbI99ey10cT8Z9SuvnwYPVjIsUEK+KYpfBReF/U5vP9mtpC0237dqf79Cgv5kM4poAPQg gEJ/MhxJXN3w76JggQz6bX/yi53I2RtrWJpYozHfl3Y/+Rr8ZFliOGag78wk7HBx1Pc4FlT4gCjs 52cWPxmHBHamjbG0t5PErcZ+ZybYZZ+piwn2uckhZuJkb2yEAXxXOgDKh4VMM+xoxq7WnEwA6vY2 Rk6WzthCYi4YCyyZw8nNyMbZgvNrNTiKivo+AsD4TG1sAFpoJ2ds3QAYHxibR8MSgx2eHIqW2Hqc 7c0wABV7N7STir0lDggAsooXeBUVNdVlJXhlpTSkeWEo7DODz8EBgy2paG/6W/lhP1n1l0POADDw X8fSYY0QDoNhHxJm32hwIOrA0W37p+X9SoNgjeEXGgKKmwb/QoMhDxwth0AcPPoO+Zsj45BI+IF6 UUDQgXqxGv71WDockAMP0CDgX2UBgUDAA/lAYNgBfiDoAZmx2XCTml9ocCTyAA0JO1AWgkAepKGg v7YNBAWBDsgMAx6UBQZCHigLgxzkBz94TCAIjmV4gAaHH6AhcHOvX2kw+EEaCnaAhgQd5IcEw6EH aJADRxGCkLCD+kAioAdpuJfEv9BQINABWVCQgzpHQX5TFnLguEMQCgaEHKQdOGYRS0MdrAN+UB8o OPJAH6AQ8INlkaCDsiAP9h8K9Zu2oRC/yoeDCeh/OY4RBv63TlkEISBfz1n8fwBQSwECFAAUAAIA CABcbWMwKKqGb8A0AADVUwAAFgAAAAAAAAAAACAAtoEAAAAASU1HLU1NVVNJQy1JRVRGLTU5LnBk ZlBLBQYAAAAAAQABAEQAAAD0NAAAAAA= ------_=_NextPart_001_01C400DB.96466308-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Mar 3 00:34:38 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 AAA02840 for ; Wed, 3 Mar 2004 00:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyP1H-0007ZA-NE for mmusic-archive@odin.ietf.org; Wed, 03 Mar 2004 00:34:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i235YBJX029078 for mmusic-archive@odin.ietf.org; Wed, 3 Mar 2004 00: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 1AyP1H-0007Yv-IP for mmusic-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00: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 AAA02800 for ; Wed, 3 Mar 2004 00:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyP1E-0006E8-00 for mmusic-web-archive@ietf.org; Wed, 03 Mar 2004 00:34:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP0A-00062j-00 for mmusic-web-archive@ietf.org; Wed, 03 Mar 2004 00:33:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyOzA-0005qy-00 for mmusic-web-archive@ietf.org; Wed, 03 Mar 2004 00:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOzC-0007GQ-3C; Wed, 03 Mar 2004 00:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOyN-00076U-Al for mmusic@optimus.ietf.org; Wed, 03 Mar 2004 00:31: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 AAA02728 for ; Wed, 3 Mar 2004 00:31:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOyK-0005fn-00 for mmusic@ietf.org; Wed, 03 Mar 2004 00:31:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOxQ-0005WJ-00 for mmusic@ietf.org; Wed, 03 Mar 2004 00:30:12 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AyOwX-0005HF-00 for mmusic@ietf.org; Wed, 03 Mar 2004 00:29:17 -0500 Received: from [210.93.162.110] (port=1041 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AyOvx-0008GV-00; Wed, 03 Mar 2004 05:28:41 +0000 Date: Wed, 3 Mar 2004 14:28:25 +0900 From: Colin Perkins To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de Message-Id: <20040303142825.07bc28aa.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is to announce a working group last call on the SDP Security Descriptions for Media Streams . Please send any final comments on this draft to the MMUSIC mailing list by 19th March 2004. If no substantive technical comments are received by that time, we will request that this draft be published as a proposed standard RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Mar 6 16:13: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 QAA05251 for ; Sat, 6 Mar 2004 16:13: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 1Azj6S-0004Rp-IA for mmusic-archive@odin.ietf.org; Sat, 06 Mar 2004 16:13:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26LD01b017093 for mmusic-archive@odin.ietf.org; Sat, 6 Mar 2004 16: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 1Azj6S-0004Rc-Bv for mmusic-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 16:13:00 -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 QAA05241 for ; Sat, 6 Mar 2004 16:12:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azj6Q-000185-00 for mmusic-web-archive@ietf.org; Sat, 06 Mar 2004 16:12:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azj5P-0000za-00 for mmusic-web-archive@ietf.org; Sat, 06 Mar 2004 16:11:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azj4f-0000r8-00 for mmusic-web-archive@ietf.org; Sat, 06 Mar 2004 16:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azj4Y-0004Jo-Lt; Sat, 06 Mar 2004 16:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azj4K-0004ES-V2 for mmusic@optimus.ietf.org; Sat, 06 Mar 2004 16:10: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 QAA05164 for ; Sat, 6 Mar 2004 16:10:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azj4J-0000pR-00 for mmusic@ietf.org; Sat, 06 Mar 2004 16:10:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azj3K-0000gL-00 for mmusic@ietf.org; Sat, 06 Mar 2004 16:09:47 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1Azj2M-0000QF-00 for mmusic@ietf.org; Sat, 06 Mar 2004 16:08:46 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61185 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1Azj1m-0007HD-00; Sat, 06 Mar 2004 21:08:11 +0000 Date: Sat, 6 Mar 2004 17:43:15 +0900 From: Colin Perkins To: mmusic@ietf.org Cc: jo@informatik.uni-bremen.de Subject: Re: [MMUSIC] WG last call: draft-ietf-mmusic-anat-00.txt Message-Id: <20040306174315.60d10a09.csp@csperkins.org> In-Reply-To: <20040129110731.67218e25.csp@csperkins.org> References: <20040129110731.67218e25.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.10 (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 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,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Colin Perkins writes: > From: Colin Perkins > To: mmusic@ietf.org > Cc: Joerg Ott > Subject: [MMUSIC] WG last call: draft-ietf-mmusic-anat-00.txt > Date: Thu, 29 Jan 2004 11:07:31 +0000 > > We have received a request to consider draft-ietf-mmusic-anat-00.txt "The > Alternative Network Address Types Semantics for the SDP Grouping > Framework" for publication as a proposed standard RFC. Accordingly, this > message is to announce the start of a working group last call for > comments on this draft. Please send any comments to the mailing list by > 13th February 2004. This working group last call period has ended, with no objections received. Accordingly, we will ask the IESG to publish draft-ietf-mmusic-anat-00.txt as a proposed standard RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Mar 6 18:22: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 SAA10184 for ; Sat, 6 Mar 2004 18:22: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 1Azl7J-0001RS-Ih for mmusic-archive@odin.ietf.org; Sat, 06 Mar 2004 18:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26NM1ml005536 for mmusic-archive@odin.ietf.org; Sat, 6 Mar 2004 18:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azl7J-0001RC-DQ for mmusic-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 18:22: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 SAA10140 for ; Sat, 6 Mar 2004 18:21:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azl7G-0004FY-00 for mmusic-web-archive@ietf.org; Sat, 06 Mar 2004 18:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azl6J-00047g-00 for mmusic-web-archive@ietf.org; Sat, 06 Mar 2004 18:20:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azl5e-0003zm-00 for mmusic-web-archive@ietf.org; Sat, 06 Mar 2004 18:20:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azl5P-0001KC-SS; Sat, 06 Mar 2004 18: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 1Azl4O-00012F-Kd for mmusic@optimus.ietf.org; Sat, 06 Mar 2004 18:19:00 -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 SAA09994 for ; Sat, 6 Mar 2004 18:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azl4L-0003oF-00 for mmusic@ietf.org; Sat, 06 Mar 2004 18:18:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azl3O-0003fj-00 for mmusic@ietf.org; Sat, 06 Mar 2004 18:17:58 -0500 Received: from white.eboundhost.com ([65.209.155.130]) by ietf-mx with smtp (Exim 4.12) id 1Azl2Q-0003WW-00 for mmusic@ietf.org; Sat, 06 Mar 2004 18:16:58 -0500 Received: (qmail 5260 invoked from network); 6 Mar 2004 23:16:52 -0000 Received: from c-24-6-179-241.client.comcast.net (HELO vaio) (BertQ40@24.6.179.241) by uk.eboundhost.com with SMTP; 6 Mar 2004 23:16:52 -0000 From: "Bert Q. Vlaanderen" Organization: V&V Design To: mmusic@ietf.org Date: Sat, 06 Mar 2004 15:29:27 +0800 MIME-Version: 1.0 Message-ID: <4049EE57.20278.DC382F2@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Subject: [MMUSIC] Seamless stream switching proof of concept 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=DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Can anyone help me with a proof of concept of a seamless stream switching application, either for a WinCE (preferrred) or Linux client ? If not available from public domain, I'm willing to pay for custom development or adaptation. Best Regards, Albertus. Q. Vlaanderen email: RTSP at AQV dot NET _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Mar 8 03:41:11 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 DAA16720 for ; Mon, 8 Mar 2004 03:41:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0GJU-0007cn-9I for mmusic-archive@odin.ietf.org; Mon, 08 Mar 2004 03:40:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i288eej9029306 for mmusic-archive@odin.ietf.org; Mon, 8 Mar 2004 03:40:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0GJT-0007cZ-Pz for mmusic-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 03:40: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 DAA16712 for ; Mon, 8 Mar 2004 03:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0GJR-0007dV-00 for mmusic-web-archive@ietf.org; Mon, 08 Mar 2004 03:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0GIU-0007T3-00 for mmusic-web-archive@ietf.org; Mon, 08 Mar 2004 03:39:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0GHx-0007IJ-00 for mmusic-web-archive@ietf.org; Mon, 08 Mar 2004 03:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0GHt-0007Kh-RE; Mon, 08 Mar 2004 03: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 1B0GHG-0007B6-Kd for mmusic@optimus.ietf.org; Mon, 08 Mar 2004 03:38: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 DAA16626 for ; Mon, 8 Mar 2004 03:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0GHE-0007GU-00 for mmusic@ietf.org; Mon, 08 Mar 2004 03:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0GGH-00077t-00 for mmusic@ietf.org; Mon, 08 Mar 2004 03:37:22 -0500 Received: from [220.117.193.250] (helo=mail.nextreaming.com) by ietf-mx with esmtp (Exim 4.12) id 1B0GFb-0006zu-00 for mmusic@ietf.org; Mon, 08 Mar 2004 03:36:40 -0500 Content-Class: urn:content-classes:message Subject: [MMUSIC] ETag Definition in draft-rfc2326bis-06 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Mar 2004 17:36:30 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [MMUSIC] ETag Definition in draft-rfc2326bis-06 thread-index: AcP/LK/7GRidVVYwTkOwUkgknE0hhgFt4HdQ From: "Jae-Hwan Kim" To: "mmusic (E-mail)" 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 Dear MMUSICers, Please look at the page 60 mentioning ETag header field.=20 Basically, "304 Not modified" response is always supposed to have this header field. However, where is ETag definition in this spec.? In addition, when ETag is used in DESCRIBE response, should a client ignore this field? I found a commercial RTSP server had this field in the DESCRIBE response. TIA/BR,=20 Jae-Hwan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 9 03:23: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 DAA14063 for ; Tue, 9 Mar 2004 03:23: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 1B0cWD-0000Fs-LT for mmusic-archive@odin.ietf.org; Tue, 09 Mar 2004 03:23:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i298NH0A000974 for mmusic-archive@odin.ietf.org; Tue, 9 Mar 2004 03:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cWD-0000Fd-EN for mmusic-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 03:23:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14008 for ; Tue, 9 Mar 2004 03:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0cWB-0002Ra-00 for mmusic-web-archive@ietf.org; Tue, 09 Mar 2004 03:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0cVD-0002GV-00 for mmusic-web-archive@ietf.org; Tue, 09 Mar 2004 03:22:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0cUB-00020M-00 for mmusic-web-archive@ietf.org; Tue, 09 Mar 2004 03:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cU2-00087P-4O; Tue, 09 Mar 2004 03:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cTU-00082P-KM for mmusic@optimus.ietf.org; Tue, 09 Mar 2004 03:20:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13869 for ; Tue, 9 Mar 2004 03:20:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0cTS-0001xC-00 for mmusic@ietf.org; Tue, 09 Mar 2004 03:20:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0cST-0001nJ-00 for mmusic@ietf.org; Tue, 09 Mar 2004 03:19:25 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B0cRh-0001dh-00 for mmusic@ietf.org; Tue, 09 Mar 2004 03:18:37 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i298IbYG027924 for ; Tue, 9 Mar 2004 09:18:37 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 09:18:36 +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 FYF9TVN8; Tue, 9 Mar 2004 09:18:36 +0100 Message-ID: <404C03EF.4010404@ericsson.com> Date: Mon, 08 Mar 2004 06:26:07 +0100 X-Sybari-Trust: 34c7ca80 2c4885b5 39802fef 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: 09 Mar 2004 08:18:36.0957 (UTC) FILETIME=[1EEE5CD0:01C405AF] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I a have some comments to this document that currently are in WG last call. 1. Section 2: The capitalized words MUST SHOULD, etc. used in this specification may not always be appropriate. This is due to that the definitions are more intended for technical specifications and putting requirements on implementations. It might be consider better if the document defines the words. 2. Section 5.2.1: Req DEL-1: I see some problems with writing a MUST in this context. I agree that scalability is desirable and is a clear design goal of any solution. The problem lays in the measuring of scalability. Absolute measurements of scalability is hard to establish. Also in certain environments one might not be able to create good scalability due to other factors in the system, for example extremely limited bandwidth. Thus I would suggest that this is reformulated into something that is more a statement of intention. 3. Section 5.4.1: Last paragraph: I think that the intermittent connectivity actually should be formulated into a requirement: REQ: "The IMG system SHOULD allow for low cost uptodate/consistency checks." 4. Section 5.5, Req DES-4: "IMG metadata MUST be structured such that it is possible to deliver only part of an IMG sender's (and the global) complete IMG metadata knowledge." I think this is SHOULD rather than a MUST. The reason is for example that some may want to use already established metadata formats that does not fulfil the requirements. Should they not be allowed to use IMG due to that facT? 5. The security requirements: Have you had any review of these, and there possibility to be fulfilled? I think it would be stupid to require security that is not possible to fulfil, how much it still is desirable. And if a piece of security is required lacks solution, should we then shelf IMG? 6. IPR and Copyright statement. Needs to be updated using RFC 3667 and 3668. Also please provide a heading for the IPR section. 7. Also as this document is intended for informative, you can't have normative references. Cheers Magnus -- 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 Mar 19 10:16:00 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 KAA07502 for ; Fri, 19 Mar 2004 10:15: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 1B4LiZ-0004gx-DA for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 10:15:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JFFRHh018029 for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 10:15:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LiZ-0004gh-7I for mmusic-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 10:15: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 KAA07425 for ; Fri, 19 Mar 2004 10:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LiW-0000kb-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 10:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Lgu-0000bv-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 10:13:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4LgB-0000WM-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 10:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LgD-000419-DK; Fri, 19 Mar 2004 10: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 1B4LfQ-0003jS-CL for mmusic@optimus.ietf.org; Fri, 19 Mar 2004 10:12: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 KAA07046 for ; Fri, 19 Mar 2004 10:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LfO-0000Tv-00 for mmusic@ietf.org; Fri, 19 Mar 2004 10:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4LeM-0000PU-00 for mmusic@ietf.org; Fri, 19 Mar 2004 10:11:09 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B4LdR-0000Lw-00 for mmusic@ietf.org; Fri, 19 Mar 2004 10:10:09 -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 i2JFA7qY015899 for ; Fri, 19 Mar 2004 16:10:08 +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); Fri, 19 Mar 2004 16:10:07 +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 GX1231YW; Fri, 19 Mar 2004 16:10:07 +0100 Message-ID: <405B0C81.4030400@ericsson.com> Date: Fri, 19 Mar 2004 16:06:41 +0100 X-Sybari-Trust: 210132b6 2c4885b5 27dccadc 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: Rod.Walsh@nokia.com CC: mmusic@ietf.org, schulzrinne@cs.columbia.edu, Hitoshi.Asaeda@sophia.inria.fr, nom@flab.fujitsu.co.jp, jo@tzi.uni-bremen.de, juha-pekka.luoma@nokia.com Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2004 15:10:07.0783 (UTC) FILETIME=[43F0EB70:01C40DC4] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rod, Comments inline. Rod.Walsh@nokia.com wrote: > Hi Magnus > > Thanks for the review comments. Responses below... > > (BTW, sorry if I missed some other responses - I'm on vacation and > suffering badly intermittent connectivity) > > ----- > > >>1. Section 2: The capitalized words MUST SHOULD, etc. used in this >>specification may not always be appropriate. This is due to that the >>definitions are more intended for technical specifications >>and putting >>requirements on implementations. It might be consider better if the >>document defines the words. > > > Yes, this is a valid point. This is in the same vein as the Seoul > plenary discussion on the applicability of RFC2119 ("should, shall, > must..."). The RFC is intended for protocol implementation > specifications, but since we don't have an RFC to give the power words > for requirements we're aiming to use RFC2119 "in the spirit" of > requirements. In this sense we didn't see any fundamental problem with > capitalisations to emphasise the requirement in question. Anyhow, I'll > have another look through to see if I spot any obvious inappropriate > capitalization - if you saw some specific offending instances (or all > instances :) please direct us to the paragraphs. Okay, I haven't really found an inappropriate usage. However it has been to long since I read the exact statement of RFC 2119. > > ----- > > The text in question is (for everyone else's benefit): > REQ DEL-1: The system MUST be scalable to large numbers of messages, > so that it does not fail to deliver up-to-date information under huge > numbers of transactions and massive quantities of IMG metadata. > >>2. Section 5.2.1: Req DEL-1: I see some problems with writing >>a MUST in >>this context. I agree that scalability is desirable and is a clear >>design goal of any solution. The problem lays in the measuring of >>scalability. Absolute measurements of scalability is hard to >>establish. >>Also in certain environments one might not be able to create good >>scalability due to other factors in the system, for example extremely >>limited bandwidth. Thus I would suggest that this is >>reformulated into >>something that is more a statement of intention. > > > I think this is a matter of wording - the meaning was correct but not > expressed clearly enough. It was important for us to state a hard > requirement, but clearly the "IMG solutions" may be useful outside the > massively scalable context. How about this re-write... > > REQ DEL-1: The IMG system MUST be scalable to large numbers of > messages, so as to allow design and use of delivery mechanisms > that will not fail in delivering up-to-date information under > huge numbers of transactions and massive quantities of IMG > metadata. > > ...which gives the requirement but makes it's applicability clearer: the > IMG system design must be scalable even if it's deployment (and used > delivery protocols) are not scalable (e.g. if massive scalability is not > feasible in a certain scenario). On the other hand, it ensures that the > design and use of scalable delivery protocols is not hindered. > This sounds better. > ----- > > The text in question is: > By contrast, intermittent connectivity make immediate distribution of > changes infeasible and so managing data consistency should be focused > on the timely delivery of data. > >>3. Section 5.4.1: Last paragraph: I think that the intermittent >>connectivity actually should be formulated into a requirement: >> >>REQ: "The IMG system SHOULD allow for low cost >>uptodate/consistency checks." > > > Good suggestion. For the mobile/cellular type cases "allowing > intermittent connectivity" is somehow bound to "enabling low cost > consistency messaging". For other cases intermittent connectivity is not > related to cost of communications (e.g. limited HW-accelerated header > filtering resources, or power-reduction by sending a connection idle, in > broadcast receivers; or shutting down background Internet activity when > a user is not active - for security). So how about this rewrite of the > last paragraph... > > REQ REL-3: The IMG system SHOULD allow for hosts with intermittent > connectivity. > > The implication of intermittent connectivity is that immediate > distribution of changes becomes infeasible and so managing data > consistency should be focused on the timely delivery of data. > > This would also require "REL-3" -> "REL-4" number re-alignment. > Okay, if one knows enough one understand that intermittent connectivity will result in follow up claims. And this requirement is probably wider than what I thought of, which is good. I am a bit worried that different persons will have significant different interpretation of what derivative requirements these open requirements results in. > ----- > > >>4. Section 5.5, Req DES-4: "IMG metadata MUST be structured >>such that it >>is possible to deliver only part of an IMG sender's (and the global) >>complete IMG metadata knowledge." >> >>I think this is SHOULD rather than a MUST. The reason is for example >>that some may want to use already established metadata >>formats that does >>not fulfil the requirements. Should they not be allowed to >>use IMG due >>to that facT? > > > The intention is that the whole body IMG metadata is structured such. > So, although we aren't proposing redesign of SDP, we are proposing that > different SDP descriptions (e.g. delivered as files) are part of a > larger structured body of IMG metadata (and the same applies to "foo" > metadata syntax). IOW, the requirement states less about the internal > structuring of metadata and more about the ability of it to be mapped > onto efficient delivery. > > This wording should mean the same thing but read clearer. Sound good? > > REQ DES-4: IMG metadata MUST be structured to enable fragmentation > for efficient delivery. > > This it is intended to ensure that and IMG sender with more than a > trivial knowledge of metadata is able to deliver only part of its > (and the global) complete IMG metadata knowledge. (For instance, a > trivial quantity of knowledge could be a single SDP description). > In general, the resolution of this fragmentation will be very much > dependent on the optimal delivery of a deployment, although some > metadata syntaxes will inherently effect the sensible lower limit > for a single element/fragment. > Much better. > ----- > > >>5. The security requirements: Have you had any review of these, and >>there possibility to be fulfilled? I think it would be stupid >>to require >>security that is not possible to fulfil, how much it still is >>desirable. > > > True. Please pinpoint any requirements which are infeasible. Although we > have been through these security requirements many time, a fresh set of > eyes could easily spot things aren't clear enough. (And bear in mind - > like the massive scalability requirement - these are requirements > intended for the design of the IMG system and not a firewall to other > uses of IMGs) > When I meant review of the security requirements I meant having them reviewed by the security area directorate. > >>And if a piece of security is required lacks solution, should we then >>shelf IMG? > > > The aim is to publish these requirements as Informational RFC. So > ultimately these requirements provide security considerations (since > standards track normative requirements referenced from subsequent > protocol specifications would be an untested idea in the IETF - I guess > someone can prove me wrong :). > As far as I am aware, an Informational RFC is in no position to shelve a > protocol, no matter a framework. However, they will provide a strong > metric in evaluating protocol proposals, so those which offer security > solutions which are appropriate for there use would be the strongest > candidates. > > So the short answer would have been "no". Okay, as long as one takes the security requirement serious. Therefore I think it is important to get security expert review already now. Thus one can get an impression on the feasibility of the solution. > [snip] > ----- > > Basically, all the changes I'm proposing are clarifications (including > the 5.4.1 "commentary" -> "requirement + commentary") or NITs. So > Magnus, would you agree with me that these changes would be enough > without a new last call? > I don't know, I would like to see a diff of the updated document before saying that. Also I would be much more confident about this WG last call if the security directorate has signed off it as being okay. 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 Fri Mar 19 12:59: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 MAA12961 for ; Fri, 19 Mar 2004 12:59: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 1B4OHM-0002Q3-FA for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 12:59:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JHxWmA009293 for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 12:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OHM-0002Pl-8a for mmusic-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 12:59:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12924 for ; Fri, 19 Mar 2004 12:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OHK-0007Co-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 12:59:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OGM-000777-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 12:58:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4OFw-000717-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 12:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OFu-0002GB-1G; Fri, 19 Mar 2004 12: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 1B4OFD-0002A2-Vz for mmusic@optimus.ietf.org; Fri, 19 Mar 2004 12: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 MAA12880 for ; Fri, 19 Mar 2004 12:57:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OFC-0006zy-00 for mmusic@ietf.org; Fri, 19 Mar 2004 12:57:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OEJ-0006vL-00 for mmusic@ietf.org; Fri, 19 Mar 2004 12:56:24 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B4ODu-0006qh-00 for mmusic@ietf.org; Fri, 19 Mar 2004 12:55:58 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2JHtwp9014383 for ; Fri, 19 Mar 2004 10:55:58 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HUU00K484H9L4@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 19 Mar 2004 09:55:57 -0800 (PST) Date: Fri, 19 Mar 2004 09:57:15 -0800 From: Geetha Srikantan To: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <405B347B.3060602@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-rfc2326-06 comments wrt live streaming 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 This draft addresses the on-demand streaming case very well, however I believe there are some issues in live streaming that need clarification. The issues are in the use of the RTP-Info header, the Range header and ssrc parameter in the Transport header. The points are related, so I will cover them in a single message. Section 11.3, page 44: 4th paragragh: '...SHOULD also include the RTP-Info header..' This requirement is fine for on-demand content, however it creates complications for live media. There are many reasons why the RTP-Info cannot be populated accurately by the server for live content: (a) Arbitrary delays between live source and server - If there are several relay nodes between source and server, there maybe a skew in system clocks of each node that tries to correlate NPT <-> RTP timestamp (i.e. Range header <-> RTP-Info's rtptime). (b) Lost packets between live source and server, imply that the server cannot accurately predict the next packet's sequence number. For these reasons, the RTP-Info header is not very useful for live streaming, and RTCP-based stream synchronization is preferred for live streams. In any case RTP-Info is only useful for initial stream synchronization. During a long-running live session the client has to rely on RTCP for ongoing stream synchronization. This is a motivation to drop RTP-Info entirely for live streams. Section 11.4, page 45: 2nd last paragraph: Range header for live streams: There is a subtle difference in the semantics of the Range header for live streams versus on-demand streams. For on-demand streams, the Range header's start value refers to the presentation time, i.e. NPT of the presentation. For live streams, the Range header's start value indicates either (a) the duration of time between the start of the live session and the time when this Range header was created, or, (b) the wall-clock time at the server responding to PLAY requests. Also the main purpose of the Range header is to map the NPT to the RTP timestamp. As discussed above this mapping is not terribly accurate in several live streaming scenarios. If the live streams are part of a multicast session then there would be an indication of the time when the session is active in the SDP, however, with clock skews etc, it is diffcult to accurately pinpoint the instantaneous time in the session. If the start time of the live session is not known, then 'npt=now-' is the only reasonable value for the Range header in a PLAYresponse. For this reason, it would be good to *not* require a Range header other than 'Range: npt=now-' for live streams. Perhaps this could also be the mechanism to signal to the client that this is a live stream and that it needs to perform stream synchronization strictly via RTCP sender reports. Section 14.40, page 91: ssrc: The transport header in the server's response cannot populate the ssrc for each stream, accurately in certain scenarios. The source of the live stream may not be RTSP-aware, and the server has to rely on RTP/RTCP to determine ssrc for each stream. The server may have joined a multicast live session and receives, say, one of the streams. It also receives SETUP request from a client and needs to respond to SETUP from a client, before it sees the first packet of each stream. Dropping the ssrc parameter from the Transport header in the SETUP response would simplify this case. thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Mar 19 13:08: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 NAA13362 for ; Fri, 19 Mar 2004 13:08: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 1B4OPz-0003Ee-Hn for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:08:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JI8Rhi012428 for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OPz-0003EK-4m for mmusic-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 13:08: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 NAA13354 for ; Fri, 19 Mar 2004 13:08:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OPx-0000OH-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:08:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OP3-0000Io-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:07:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4OOa-0000DI-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OOb-0002ml-4I; Fri, 19 Mar 2004 13:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OO3-0002k5-7a for mmusic@optimus.ietf.org; Fri, 19 Mar 2004 13:06: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 NAA13314 for ; Fri, 19 Mar 2004 13:06:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OO1-0000Ay-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:06:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ON7-00005V-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:05:30 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B4OMo-0007nq-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:05:10 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2JI59p9021380 for ; Fri, 19 Mar 2004 11:05:09 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HUU006YO4WLCX@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 19 Mar 2004 10:05:09 -0800 (PST) Date: Fri, 19 Mar 2004 10:06:27 -0800 From: Geetha Srikantan To: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <405B36A3.6060000@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-rfc2326-06 minor comments 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 Here are some minor - at least, I think they're minor :-) - comments on draft-ietf-mmusic-rfc2326bis-06.txt. Section 3.7, page 24: It would be helpful to provide a forward reference to the feature tag discussion in section 19. Section 6, page 26, last paragraph before 6.1: Length of the message body is sent in the Content-Length header only right? The last sentence says 'headers', which has me confused. Section 6.1, page 26: 'Please note: The request...' This line seems to contradict what was in bullet #3 of 1.6 on page 17. Which is correct - this line here or 1.6? Section 6.2, page 27: Refers to table 6.2, it should be table 3. Section 7.1.2, page 30: Refers to table 7.1.2, it should be table 5. Also tables 4 and 5 are not in order - 5 is before 4. Section 11.3, page 43: 1st paragraph, 2nd sentence: it should be 'three' not 'two' different cases, right? Section 11.3, page 44: 1st paragraph: An example of the timeout parameter with session id would be helpful. Section 11.3, page 44: SSRC: If the SSRC of the media stream changes mid-stream due to SSRC collision in a multicast say, there is no way to signal it via RTSP. Should we add a note about that? (This is the same as in RFC 2326.) Section 11.4, page 47: An example of live streaming would be very helpful. BTW, the examples in section 11.5 are excellent. Section 11.10, page 57: 1st paragraph, 2nd sentence: PING does have the side effect of updating the session liveness, even though it doesn't cause any state change. Section 13.3.5, page 60: Refers to section 12.23 it should be 14.23 Etags are mentioned - it would be helpful to provide a reference to more details on Etags. Section 13.5.1, page 63: Status code 551 is not mentioned in table 4, perhaps a typo? Section 14, page 63: It would be good to have table 9 and 10 earlier in this section before they are discussed. Section 14.29, page 78: 1st paragraph: 10.08 is before 10.1, the text seems to indicate otherwise.. Section 14.40, page 92: An example with src_addr and dest_addr would be very helpful. An example with non-contiguous RTP/RTCP ports would be helpful too. Section 16.2 page 99 and section 16.3 page 101: On page 99 the url in the PLAY request has a trailing '/' although on page 101 the url in the PLAY request, there is no trailing '/'. In both cases the SDP has 'a=control: *. This seems to contradict the last paragraph in C.1.1. Section B.1.2, page 127: 1st bullet, last line: Not sure what it means. Section B.1.4, page 129: 1st paragraph, Last sentence: There is a possibility of RTP timestamps in consecutive RTP packets not being monotonic, according to the RTP spec. I can see that sequence numbers should be monotonically increasing, however, can we really mandate the same for the RTP timestamps? thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Mar 19 13:11:56 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 NAA13513 for ; Fri, 19 Mar 2004 13:11: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 1B4OSv-0003bH-7N for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:11:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JIBTUS013828 for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OSu-0003ax-Ad for mmusic-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 13:11:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13504 for ; Fri, 19 Mar 2004 13:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OSs-0000j9-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:11:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ORw-0000dr-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:10:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4ORU-0000Ya-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13: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 1B4ORV-0003Qm-Cx; Fri, 19 Mar 2004 13: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 1B4OQr-0003L8-C4 for mmusic@optimus.ietf.org; Fri, 19 Mar 2004 13:09: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 NAA13409 for ; Fri, 19 Mar 2004 13:09:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OQp-0000VC-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:09:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OPv-0000Nx-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:08:23 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B4OP1-0000IL-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:07:27 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2JI7Rp9022918 for ; Fri, 19 Mar 2004 11:07:27 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HUU006XG50ECX@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 19 Mar 2004 10:07:26 -0800 (PST) Date: Fri, 19 Mar 2004 10:08:43 -0800 From: Geetha Srikantan To: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <405B372B.2030807@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-rfc2326-06 Supported header 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Section 10, page 38: If a server receives a Supported header with multiple values in the request, and the server supports at least one of the options supported by the client, should the server respond with status code 200? thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Mar 19 13:13:51 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 NAA13590 for ; Fri, 19 Mar 2004 13:13: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 1B4OUm-0003pP-Fw for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JIDO7e014709 for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OUm-0003pA-Br for mmusic-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 13:13: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 NAA13584 for ; Fri, 19 Mar 2004 13:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OUk-0000vD-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:13:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OTs-0000qS-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:12:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4OTQ-0000lG-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OTR-0003df-9D; Fri, 19 Mar 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OSg-0003Zc-IG for mmusic@optimus.ietf.org; Fri, 19 Mar 2004 13:11: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 NAA13481 for ; Fri, 19 Mar 2004 13:11:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OSe-0000hC-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:11:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ORg-0000bN-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:10:12 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B4OQl-0000Qs-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:09:15 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2JI8jng009477 for ; Fri, 19 Mar 2004 10:08:45 -0800 (PST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HUU006BN52LCX@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 19 Mar 2004 10:08:45 -0800 (PST) Date: Fri, 19 Mar 2004 10:10:02 -0800 From: Geetha Srikantan To: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <405B377A.5030909@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-rfc2326-06 question about Scale and Speed headers 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 14.34, 14.35, page 82: Are the Scale and Speed headers restricted to on-demand streaming? thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Mar 19 13:50: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 NAA15071 for ; Fri, 19 Mar 2004 13:50:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4P41-0005oi-7j for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:49:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JInniR022354 for mmusic-archive@odin.ietf.org; Fri, 19 Mar 2004 13:49:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4P40-0005oT-CF for mmusic-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 13:49: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 NAA15013 for ; Fri, 19 Mar 2004 13:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4P3y-0003tl-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:49:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4P2x-0003j6-00 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:48:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4P2J-0003aq-02 for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:48:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4Osf-0005LA-Bk for mmusic-web-archive@ietf.org; Fri, 19 Mar 2004 13:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Osb-0005J3-CS; Fri, 19 Mar 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Orx-00059W-8H for mmusic@optimus.ietf.org; Fri, 19 Mar 2004 13:37: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 NAA14593 for ; Fri, 19 Mar 2004 13:37:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Oru-0002tG-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:37:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Oqz-0002oU-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:36:22 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B4OqJ-0002k2-00 for mmusic@ietf.org; Fri, 19 Mar 2004 13:35:39 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2JIZbp9014558 for ; Fri, 19 Mar 2004 11:35:38 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HUU006RK6BDCX@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 19 Mar 2004 10:35:37 -0800 (PST) Date: Fri, 19 Mar 2004 10:36:54 -0800 From: Geetha Srikantan To: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <405B3DC6.5050001@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-rfc2326-06 question on trn-param-ext 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 page 112: What is the intended use of 'trn-param-ext'? thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 23 10:24:00 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 KAA02940 for ; Tue, 23 Mar 2004 10:24:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nkb-0004zb-08 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 10:23:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NFNWH8019185 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 10:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nkZ-0004zM-S8 for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 10:23: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 KAA02931 for ; Tue, 23 Mar 2004 10:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nkX-0001Qn-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 10:23:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5njd-0001IQ-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 10:22:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5njD-0001Ao-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 10:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nj7-0004lR-Q3; Tue, 23 Mar 2004 10:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nil-0004h7-H3 for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 10:21: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 KAA02832 for ; Tue, 23 Mar 2004 10:21:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nij-00017h-00 for mmusic@ietf.org; Tue, 23 Mar 2004 10:21:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nhs-0000vs-00 for mmusic@ietf.org; Tue, 23 Mar 2004 10:20:45 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B5ngv-0000mZ-00 for mmusic@ietf.org; Tue, 23 Mar 2004 10:19:45 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2NFJhqY000611 for ; Tue, 23 Mar 2004 16:19:43 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 16:19:42 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS57MD1; Tue, 23 Mar 2004 16:19:51 +0100 Message-ID: <4060558E.4020202@ericsson.com> Date: Tue, 23 Mar 2004 16:19:42 +0100 X-Sybari-Trust: e1c3ba6e 2c4885b5 26315a68 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: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 Supported header question References: <405B372B.2030807@sun.com> In-Reply-To: <405B372B.2030807@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2004 15:19:42.0697 (UTC) FILETIME=[4444D590:01C410EA] 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 Geetha, Thanks for the comments. Geetha Srikantan wrote: > Section 10, page 38: > If a server receives a Supported header with multiple values in the > request, and the server supports at least one of the options supported > by the client, should the server respond with status code 200? > The supported header usage does not effect what the response code will be. The response code is directly related to the request itself. So a supported header in the response shall be include even if the response is 400 or 500. The supported header may be included in any request. This supported header will include all feature-tags supported by the requester. The receiver of the request must simply respond with its own supported header. I think it is obvious that we need a bit more text on the supported header. The current section is very short, but there are also text in the capability handling section. I will add a reminder bug to extend this section. Cheers Magnus -- 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 Mar 23 11:17:23 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 LAA06816 for ; Tue, 23 Mar 2004 11:17: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 1B5oaE-0003wz-QW for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 11:16:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NGGsoP015184 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 11:16:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oaE-0003wp-Ju for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 11:16: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 LAA06799 for ; Tue, 23 Mar 2004 11:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oaD-00027m-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:16:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oX9-0001Wu-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:13:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5oW1-0001IU-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:12:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5oQ5-0002kt-OX for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:06:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oPx-0002ZN-2F; Tue, 23 Mar 2004 11:06:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oP4-0002VK-CE for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 11:05: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 LAA06340 for ; Tue, 23 Mar 2004 11:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oP1-0000Wq-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:05:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oO1-0000Pl-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:04:17 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B5oNH-0000IG-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:03:31 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2NG3UYG018223 for ; Tue, 23 Mar 2004 17:03:30 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 17:03:30 +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 HJS1X8KH; Tue, 23 Mar 2004 17:03:30 +0100 Message-ID: <40605FC5.8070109@ericsson.com> Date: Tue, 23 Mar 2004 17:03:17 +0100 X-Sybari-Trust: f763bc20 272a6e05 2d53b1d8 00000139 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: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 question about Scale and Speed headers References: <405B377A.5030909@sun.com> In-Reply-To: <405B377A.5030909@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2004 16:03:30.0043 (UTC) FILETIME=[624A04B0:01C410F0] 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 Geetha, Thanks for the comments. Geetha Srikantan wrote: > Section 14.34, 14.35, page 82: > Are the Scale and Speed headers restricted to on-demand streaming? > No, but in most other cases the server will not be able to perform the necessary operations. In these cases the server will have to reject the request. 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 Tue Mar 23 11:18: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 LAA06965 for ; Tue, 23 Mar 2004 11:18: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 1B5obg-0004Ah-M6 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 11:18:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NGIOul016029 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 11:18:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5obg-0004AS-GV for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 11:18: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 LAA06872 for ; Tue, 23 Mar 2004 11:18:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5obf-0002QW-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:18:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oXs-0001hO-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:14:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5oWK-0001L1-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:12:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5oNp-0002aO-Lg for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:04:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oNl-0002NP-9F; Tue, 23 Mar 2004 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oN4-0002K5-VP for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 11:03: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 LAA06187 for ; Tue, 23 Mar 2004 11:03:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oN2-0000Gm-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:03:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oM5-00007U-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:02:18 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B5oL8-0007fE-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:01:18 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2NG1DYG017806 for ; Tue, 23 Mar 2004 17:01:17 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 17:01:13 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS57ZZ2; Tue, 23 Mar 2004 17:01:22 +0100 Message-ID: <40605F48.9030001@ericsson.com> Date: Tue, 23 Mar 2004 17:01:12 +0100 X-Sybari-Trust: bceb66f2 2c4885b5 26315a68 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: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming References: <405B347B.3060602@sun.com> In-Reply-To: <405B347B.3060602@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2004 16:01:13.0248 (UTC) FILETIME=[10C0C200:01C410F0] 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 Geetha, Thanks for the comments. See comments inline. Geetha Srikantan wrote: > This draft addresses the on-demand streaming case very well, however > I believe there are some issues in live streaming that need > clarification. > The issues are in the use of the RTP-Info header, the Range header and > ssrc parameter in the Transport header. The points are related, so I > will cover > them in a single message. > > > Section 11.3, page 44: 4th paragragh: > '...SHOULD also include the RTP-Info header..' > > This requirement is fine for on-demand content, however it creates > complications > for live media. There are many reasons why the RTP-Info cannot be > populated > accurately by the server for live content: > (a) Arbitrary delays between live source and server - If there are > several relay nodes between source and server, there maybe a skew > in system clocks of each node that tries to correlate > NPT <-> RTP timestamp (i.e. Range header <-> RTP-Info's rtptime). I don't see how this clock skew effects anything. The binding in a PLAY response of RTP-Info and Range header is not dependent on at what time you receive the play response or the media stream. The synchronization mechanism in both RTCP and in RTSP are not dependent on any synchronization of the receiver clock to any other clock. One binds all present media streams to a common clock reference. In most case for RTSP the NPT time. In RTSP this is accomplished by giving the corresponding RTP TS for a given NPT time. In fact any media streams properly timestamped can be synchronized as long as any data point for synchronization against the common time scale exist. I don't see any reason why there would be skew even in a multi-tire distribution system. When the first host has established the synchronization information he can forward it, without any dependency of its local clock. > (b) Lost packets between live source and server, imply that the server > cannot accurately predict the next packet's sequence number. Also here I can't see the problem. The RTP sequence number indicates the first sequence number for a stream that the given synchronization information and time range applies for. Thus if one receives a RTP packet with a higher sequence number one knows that it is for the new range. A relay server that has received at least one packet can give this information that is valid even if a several RTP packets is lost before one gets forward. The client can't determine if the loss is between the relay or before. And if the server really has not received either the information from a upstream source or any RTP packet when responding, this value can be excluded. The RTP-Info header only requires either of the values to be present. Also if one really can't establish the information one is allowed to excluded. It is after all a SHOULD not a MUST. However in general it seems reasonable that a server will be able to provide this information. > > For these reasons, the RTP-Info header is not very useful for live > streaming, and RTCP-based stream synchronization is preferred for live > streams. In any case RTP-Info is only useful for initial stream > synchronization. During a long-running live session the client has to > rely on RTCP for ongoing stream synchronization. > This is a motivation to drop RTP-Info entirely for live streams. What is the problem with long run session? If the original data source does not have a problem with its clock their should not be any clock skew entered into the RTP timestamp. And if that occur this can be corrected by RTCP sender reports. Any local clock skew between media will need to be detected and dealt by the client locally. > > Section 11.4, page 45: > 2nd last paragraph: > > Range header for live streams: > There is a subtle difference in the semantics of the Range header for > live > streams versus on-demand streams. For on-demand streams, the Range > header's start value refers to the presentation time, i.e. NPT of the > presentation. > For live streams, the Range header's start value indicates either > (a) the duration of time between the start of the live session and the > time when this Range header was created, or, > (b) the wall-clock time at the server responding to PLAY requests. > In both these cases the time is as viewed by the origin server. In a relay structure, it is not the local time of each relay. Using RTSP for relay will provide all relay servers also with the correct view of the NPT or wall clock time of the origin server. > Also the main purpose of the Range header is to map the NPT to > the RTP timestamp. As discussed above this mapping is not terribly > accurate in several live streaming scenarios. As I don't think it is any less accurate then for on-demand media I don't understand what the problem is. > > If the live streams are part of a multicast session then there would > be an indication of the time when the session is active in the SDP, > however, with clock skews etc, it is diffcult to accurately pinpoint > the instantaneous time in the session. The instantaneous time is calculated based of the RTP timestamp for a given media and the mapping received by Range and RTP-Info between RTP timestamp and NPT at any point Example: Sync point -----|------------------------------------x------> t TS A B When one started the session one received by Range and RTP-Info the following information for RTP TS A. PLAY response: Range: npt=56.97- RTP-Info: url=; rtptime=164400 Thus A = 1644000 The media timestamp rate is 90kHz. The NPT time for B=465357 is: (465357-164400)/90000 + 56.97 = 60,3139666 s > > If the start time of the live session is not known, then 'npt=now-' > is the only reasonable value for the Range header in a PLAYresponse. > I agree that if one truly does not know the time since session start it is a viable operation. However all functionality exist to know the time. > For this reason, it would be good to *not* require a Range header > other than 'Range: npt=now-' for live streams. > No, I think there are a lot of application that can benefit from presenting the original wall clock or time since session start. > Perhaps this could also be the mechanism to signal to the client that > this is a live stream and that it needs to perform stream > synchronization strictly via RTCP sender reports. > There are already text in there to indicate that the session has live qualities. There are already reasons why a client must support synchronization by RTCP. For example sender side clock skew corrections, multiple sources using different SSRCs, the possibility to exclude RTP-Info header. However the RTP-Info+Range header is a reliable transferred information. Although not guaranteed to be timely, it has a rather high probability to reach the client prior to any RTCP message. Also in most case it should reach the client prior to it finishing initial buffering, thus providing it with good initial synchronization for all media streams. > > Section 14.40, page 91: > ssrc: > The transport header in the server's response cannot populate the ssrc > for each stream, accurately in certain scenarios. > The source of the live stream may not be RTSP-aware, and the server has > to rely on RTP/RTCP to determine ssrc for each stream. > The server may have joined a multicast live session and receives, say, > one of the streams. > It also receives SETUP request from a client and needs to respond to > SETUP from a client, > before it sees the first packet of each stream. > Dropping the ssrc parameter from the Transport header in the SETUP > response would > simplify this case. It is possible to skip the SSRC, however not recommend as it indicates for which SSRC the synchronization information in RTP-Info applies to. Thus I would recommend that server awaits at least the first RTP packet to determine what SSRC is used for media distribution. 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 Tue Mar 23 11:19: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 LAA07046 for ; Tue, 23 Mar 2004 11:19: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 1B5ocE-0004Fd-5P for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 11:18:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NGIwM7016335 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 11:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ocE-0004FO-1d for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 11: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 LAA06983 for ; Tue, 23 Mar 2004 11:18:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ocD-0002Yn-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:18:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oYj-0001rp-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:15:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5oWi-0001SO-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 11:13:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oWd-0003OC-4n; Tue, 23 Mar 2004 11:13:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oR9-0002lZ-Fn for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 11:07: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 LAA06463 for ; Tue, 23 Mar 2004 11:07:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oQw-0000kR-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:07:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oQH-0000ey-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:06:38 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B5oPK-0000Z2-00 for mmusic@ietf.org; Tue, 23 Mar 2004 11:05:38 -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 i2NG5cYG018650 for ; Tue, 23 Mar 2004 17:05:38 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 17:05:37 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS576QH; Tue, 23 Mar 2004 17:05:46 +0100 Message-ID: <40606051.8090504@ericsson.com> Date: Tue, 23 Mar 2004 17:05:37 +0100 X-Sybari-Trust: 9eede7c6 2c4885b5 26315a68 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: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 question on trn-param-ext References: <405B3DC6.5050001@sun.com> In-Reply-To: <405B3DC6.5050001@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2004 16:05:37.0696 (UTC) FILETIME=[AE605200:01C410F0] 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 Geetha, Geetha Srikantan wrote: > Section 17.2.3 page 112: > What is the intended use of 'trn-param-ext'? > To have a clear indication that the transport header can be extended. Reasons for extending this will for example be new transport protocols that needs further parameters than currently is present. With the feature tag system one can ensure that the receiver of a request can correctly understand the request, and not skip necessary parameters. 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 Tue Mar 23 12:36: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 MAA14020 for ; Tue, 23 Mar 2004 12:36: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 1B5por-00060s-SH for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 12:36:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NHa52t023110 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 12:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5por-00060f-OE for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 12:36: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 MAA14007 for ; Tue, 23 Mar 2004 12:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5pon-0003rO-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:36:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pnD-0003bT-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:34:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5pm6-0003L9-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:33:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5pfO-0005h1-Rf for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:26:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pfF-0004nF-M4; Tue, 23 Mar 2004 12:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5peW-0004YA-Qu for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 12:25: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 MAA13424 for ; Tue, 23 Mar 2004 12:25:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5peV-00031C-00 for mmusic@ietf.org; Tue, 23 Mar 2004 12:25:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pdY-00030K-00 for mmusic@ietf.org; Tue, 23 Mar 2004 12:24:25 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B5pcl-0002yZ-00 for mmusic@ietf.org; Tue, 23 Mar 2004 12:23:35 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2NHNNAh009278 for ; Tue, 23 Mar 2004 18:23:32 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 18:23:22 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS58VX2; Tue, 23 Mar 2004 18:23:32 +0100 Message-ID: <4060728A.2010606@ericsson.com> Date: Tue, 23 Mar 2004 18:23:22 +0100 X-Sybari-Trust: 687c93ed 2c4885b5 26315a68 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: Jae-Hwan Kim CC: "mmusic (E-mail)" Subject: Re: [MMUSIC] ETag Definition in draft-rfc2326bis-06 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2004 17:23:22.0948 (UTC) FILETIME=[8B154840:01C410FB] 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 Jae-Hwan, Thanks for spotting this. I need some help with this as I have not a complete understanding of how ETag is supposed to work. I understand that they are server defined entities that only needs to follow the syntax. So what I understand there is need for a RTSP header "ETag:" that can be included in DESCRIBE and SETUP messages to be used to determine what content the client actually wants to SETUP or question if the description is up-to-date. Having a ETag header in the describe response seem to have some possibilities to clash with the SDP usage. In session descriptions it seems much better to have the ETag in the description so one does not have to add it if one for example saves the SDP. Any comments on this is greatly appreciated. Cheers Magnus Jae-Hwan Kim wrote: > Dear MMUSICers, > > Please look at the page 60 mentioning ETag header field. > Basically, "304 Not modified" response is always supposed to have this > header field. > However, where is ETag definition in this spec.? > > In addition, when ETag is used in DESCRIBE response, should a client > ignore this field? > I found a commercial RTSP server had this field in the DESCRIBE > response. > > TIA/BR, > Jae-Hwan > > > _______________________________________________ > 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 Tue Mar 23 12:37:38 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 MAA14145 for ; Tue, 23 Mar 2004 12:37:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ppv-00068n-6D for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 12:37:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NHbBql023594 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 12: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 1B5ppu-00068T-SD for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 12:37: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 MAA14092 for ; Tue, 23 Mar 2004 12:37:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ppt-00041n-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:37:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5poB-0003ka-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:35:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5pmn-0003L9-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:33:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5paX-0005Y7-Sp for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 12:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5paI-0004Ci-AT; Tue, 23 Mar 2004 12:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pZc-00048k-SC for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 12:20: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 MAA13280 for ; Tue, 23 Mar 2004 12:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5pZb-0002p2-00 for mmusic@ietf.org; Tue, 23 Mar 2004 12:20:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pYg-0002nt-00 for mmusic@ietf.org; Tue, 23 Mar 2004 12:19:23 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B5pXl-0002kp-00 for mmusic@ietf.org; Tue, 23 Mar 2004 12:18:25 -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 i2NHIFYG012554 for ; Tue, 23 Mar 2004 18:18:15 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 18:18:15 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS584J8; Tue, 23 Mar 2004 18:18:24 +0100 Message-ID: <40607157.3060509@ericsson.com> Date: Tue, 23 Mar 2004 18:18:15 +0100 X-Sybari-Trust: dda8ce11 2c4885b5 26315a68 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: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 minor comments References: <405B36A3.6060000@sun.com> In-Reply-To: <405B36A3.6060000@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2004 17:18:15.0596 (UTC) FILETIME=[D3E316C0:01C410FA] 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 Geetha, Thanks for the comments. Comments inline. Geetha Srikantan wrote: > Here are some minor - at least, I think they're minor :-) > - comments on draft-ietf-mmusic-rfc2326bis-06.txt. > > Section 3.7, page 24: It would be helpful to provide a forward > reference to the feature tag discussion in section 19. I guess that you mean section 10 capability handling. > > Section 6, page 26, last paragraph before 6.1: > Length of the message body is sent in the Content-Length header only > right? The last sentence says 'headers', which has me confused. Yes, I will change this to "Content-Length entity header" > > Section 6.1, page 26: > 'Please note: The request...' > This line seems to contradict what was in bullet #3 of 1.6 on page 17. > Which is correct - this line here or 1.6? No, they are not really contradicting, slightly differently interpreted. Section 1.6 says: " A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change." Section 6.1: "Please note: The request line's syntax can't be changed in future versions of RTSP, as this line indicates the version of the messages and need to be parsable also by older versions." If one changes the syntax of the request line on does in fact change the position of the protocol version. The text in 6.1 is simply stricter of what in fact must be required by an updated version. I could soften the language in section 6.1 to the following: Please note: The request line's syntax can't be freely changed in future versions of RTSP, as this line indicates the version of the messages and need to be parsable also by older versions. > > Section 6.2, page 27: > Refers to table 6.2, it should be table 3. Fixed, a bit of latex error. > > Section 7.1.2, page 30: > Refers to table 7.1.2, it should be table 5. > Also tables 4 and 5 are not in order - 5 is before 4. Fixed. > > Section 11.3, page 43: > 1st paragraph, 2nd sentence: it should be 'three' not 'two' different > cases, right? > I was meaning two, but the rest of the sentence does not get the case across, so I use three instead. > Section 11.3, page 44: > 1st paragraph: An example of the timeout parameter with session id > would be helpful. > Now included. > Section 11.3, page 44: > SSRC: If the SSRC of the media stream changes mid-stream due to SSRC > collision in a multicast say, there is no way to signal it via RTSP. > Should we add a note about that? (This is the same as in RFC 2326.) I agree that there is no way to signal it. However this does not belong in this section. Instead it belongs to the appendix B deciding RTP usage. New proposed text for that section is: An SSRC collision with the SSRC that transmits media does also has consequences, as it will force it to change its SSRC in accordance with the RTP specification ~\cite{rfc3550}. This will result in a loss of synchronization context, and require any receiver to wait for RTCP sender reports for all media requiring synchronization before being able to play out synchronized. Due to these reasons a client joining a session should take care to not select the same SSRC as the server. Any SSRC signalled in the \header{Transport} header {\SHOULD} be avoided. Also a client detecting a collision prior to sending any RTP or RTCP messages can also select a new SSRC. > > Section 11.4, page 47: > An example of live streaming would be very helpful. > BTW, the examples in section 11.5 are excellent. Isn't section 16.4 enough? What aspects do you desire an example to cover. Could you please present the example you would like to be included? > > Section 11.10, page 57: > 1st paragraph, 2nd sentence: > PING does have the side effect of updating the session > liveness, even though it doesn't cause any state change. No, not in my version the first paragraph says: "This method is a bi-directional mechanism for server or client liveness checking. It has no side effects. The issuer of the request MUST include a session header with the session ID of the session that is being checked for liveness." > > Section 13.3.5, page 60: > Refers to section 12.23 it should be 14.23 > Etags are mentioned - it would be helpful to provide a reference to > more details on Etags. There is some problem with ETag. As Jae-Hwan Kim pointed out there is a missing header. > > Section 13.5.1, page 63: > Status code 551 is not mentioned in table 4, perhaps a typo? Well it is in my table. However it might have been lost in the post processing. > > Section 14, page 63: > It would be good to have table 9 and 10 earlier in this section before > they are discussed. I am having problem controlling exactly where they are put. Maybe my lack of LaTeX knowledge. They should be after the explanation of the text. However now they float a bit to far. > > Section 14.29, page 78: > 1st paragraph: 10.08 is before 10.1, the text seems to indicate > otherwise.. "Ranges are half-open intervals, including the first point, but excluding the second point. In other words, a range of A-B starts exactly at time A, but stops just before B. Only the start time of a media unit such as a video or audio frame is relevant. As an example, assume that video frames are generated every 40 ms. A range of 10.0-10.1 would include a video frame starting at 10.0 or later time and would include a video frame starting at 10.08, even though it lasted beyond the interval. A range of 10.0-10.08, on the other hand, would exclude the frame at 10.08." What is the problem with the section? I don't understand what you interpret as indicating that 10.08 is after 10.1? > > Section 14.40, page 92: > An example with src_addr and dest_addr would be very helpful. > An example with non-contiguous RTP/RTCP ports would be helpful too. See example 16.2. It doesn't have non-contiguous ports, but as all ports are given explicitly I don't think this is a problem. > > Section 16.2 page 99 and section 16.3 page 101: > On page 99 the url in the PLAY request has a trailing '/' > although on page 101 the url in the PLAY request, there is no trailing > '/'. In both cases the SDP has 'a=control: *. > This seems to contradict the last paragraph in C.1.1. > A bug, fixed. > Section B.1.2, page 127: > 1st bullet, last line: Not sure what it means. > o RTP/UDP packet from the server to the client SHALL be sent to the address specified in the "destination" parameter and first even port number given in client_port range. If there is only a single port number given that MUST be given. I think the intent is to clarify that if no range is given, the RTP port must be explicitly given. For a range the first even number is used. Thus there is certain differences. I propose to change the last sentence to: If only a RTP port is to be specified, then only that even port number {\SHALL} be given, i.e. no range starting at a odd number {\SHALL} be used. Better? > Section B.1.4, page 129: > 1st paragraph, Last sentence: > There is a possibility of RTP timestamps in consecutive RTP packets > not being monotonic, according to the RTP spec. I can see that > sequence numbers should be monotonically increasing, however, can we > really mandate the same for the RTP timestamps? > In respect to: "Thus, both RTP sequence numbers and RTP timestamps MUST be | continuous and monotonic across jumps of NPT." This is not a general rule that always apply, it only is given for jumps in NPT. It could not possibly work correctly if the timestamp do not increase between a media packet belonging to another NPT than after the NPT jump. So even when jumping backwards in NPT one must increase the TS to make the client present the packet correctly after the previous range. 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 Tue Mar 23 23:27:13 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 XAA24315 for ; Tue, 23 Mar 2004 23:27:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zyY-0003Jf-4u for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 23:26:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O4QkgJ012747 for mmusic-archive@odin.ietf.org; Tue, 23 Mar 2004 23:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zyX-0003JU-W5 for mmusic-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 23:26:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24308 for ; Tue, 23 Mar 2004 23:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5zyW-00059l-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 23:26:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zxb-00055O-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 23:25:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5zws-00051K-00 for mmusic-web-archive@ietf.org; Tue, 23 Mar 2004 23:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zwr-00037D-Il; Tue, 23 Mar 2004 23:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zvr-000356-Jn for mmusic@optimus.ietf.org; Tue, 23 Mar 2004 23:23: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 XAA24279 for ; Tue, 23 Mar 2004 23:23:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5zvp-0004w4-00 for mmusic@ietf.org; Tue, 23 Mar 2004 23:23:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zv5-0004qy-00 for mmusic@ietf.org; Tue, 23 Mar 2004 23:23:11 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1B5zuO-0004iX-00 for mmusic@ietf.org; Tue, 23 Mar 2004 23:22:28 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 23 Mar 2004 20:21:50 -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 capefear.real.com with esmtp; Tue, 23 Mar 2004 20:18:00 -0800 Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1B5zq9-0003KC-6V for robla@real.com; Tue, 23 Mar 2004 20:18:05 -0800 Date: Tue, 23 Mar 2004 20:05:48 -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 Message-ID: To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #122 - 2 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-921857 ] ETag is missing header? (SourceForge.net) 2. [ rtspspec-Bugs-921829 ] Supported header needs more text (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 23 Mar 2004 08:53:38 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-921857 ] ETag is missing header? Bugs item #921857, was opened at 2004-03-23 17:53 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=921857&group_id=23194 Category: General Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: ETag is missing header? Initial Comment: As pointed out in the following mail to mmusic: https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg02358.html The ETag is missing a header to enable it to be carried there. However more information on how this works would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=921857&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 23 Mar 2004 08:11:16 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-921829 ] Supported header needs more text Bugs item #921829, was opened at 2004-03-23 17:11 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=921829&group_id=23194 Category: Editorial Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Supported header needs more text Initial Comment: The supported header needs more text that explains that it can be used all methods and that it doesn't effect the processing of the request itself in anyway. A clarification that it is expected also in 4xx and 5xx responses would also be good. Reference to usage section 10 would also be good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=921829&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 Mar 24 11:16:14 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 LAA03784 for ; Wed, 24 Mar 2004 11:16: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 1B6B2f-0001F3-KE for mmusic-archive@odin.ietf.org; Wed, 24 Mar 2004 11:15:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGFj9W004769 for mmusic-archive@odin.ietf.org; Wed, 24 Mar 2004 11:15:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B2f-0001Eq-FS for mmusic-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:15: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 LAA03748 for ; Wed, 24 Mar 2004 11:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6B2e-00002l-00 for mmusic-web-archive@ietf.org; Wed, 24 Mar 2004 11:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6B1A-0007lb-00 for mmusic-web-archive@ietf.org; Wed, 24 Mar 2004 11:14:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6B0D-0007fb-00 for mmusic-web-archive@ietf.org; Wed, 24 Mar 2004 11:13:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B07-0000eM-CM; Wed, 24 Mar 2004 11:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Azd-0000ZG-W4 for mmusic@optimus.ietf.org; Wed, 24 Mar 2004 11:12:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03530 for ; Wed, 24 Mar 2004 11:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Azd-0007bx-00 for mmusic@ietf.org; Wed, 24 Mar 2004 11:12:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ayk-0007X0-00 for mmusic@ietf.org; Wed, 24 Mar 2004 11:11:43 -0500 Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Ay3-0007Nb-00; Wed, 24 Mar 2004 11:10:59 -0500 Received: from dlep91.itg.ti.com ([157.170.152.55]) by dragon.ti.com (8.12.11/8.12.11) with ESMTP id i2OGAT3p017927; Wed, 24 Mar 2004 10:10:29 -0600 (CST) Received: from tnint11.telogy.design.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.10/8.12.10) with ESMTP id i2OGASpi000022; Wed, 24 Mar 2004 10:10:28 -0600 (CST) Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Mar 2004 11:10:25 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C0303C206@tnint11.telogy.design.ti.com> From: "Yadavalli, Satya" To: "'mmusic@ietf.org'" , "'Sipping@Ietf. Org'" Date: Wed, 24 Mar 2004 11:10:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C411BA.843372D0" Subject: [MMUSIC] SIP - SRTP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,SUBJ_ALL_CAPS 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_01C411BA.843372D0 Content-Type: text/plain Hi, I am trying to find a specification (for SIP applications) that describes specifying the SRTP media related needs (key exchanges etc.,) in the SDP and found the following two drafts: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-10.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-03.txt Could some one help me which of these is the draft that would help (or is it both...havenot really looked into them) or are there any other recommendations to follow. Are there any SIP implementations currently supporting SRTP? If so, what is followed for specifying the SDP. Thanks, Satya ------_=_NextPart_001_01C411BA.843372D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable SIP - SRTP

Hi,
I am trying to find a specification = (for SIP applications) that describes specifying the SRTP media related = needs (key exchanges etc.,) in the SDP and found the following two = drafts:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmg= mt-ext-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptio= ns-03.txt

Could some one help me which of these = is the draft that would help (or is it both...havenot really looked = into them) or are there any other recommendations to follow.

Are there any SIP implementations = currently supporting SRTP? If so, what is followed for specifying the = SDP.

Thanks,
Satya

------_=_NextPart_001_01C411BA.843372D0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Mar 24 18:01:02 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 SAA27286 for ; Wed, 24 Mar 2004 18:01:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HMR-00015C-Rr for mmusic-archive@odin.ietf.org; Wed, 24 Mar 2004 18:00:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ON0Zpr004156 for mmusic-archive@odin.ietf.org; Wed, 24 Mar 2004 18:00:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HMR-00014w-Oc for mmusic-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 18:00: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 SAA27256 for ; Wed, 24 Mar 2004 18:00:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6HMO-0001bW-00 for mmusic-web-archive@ietf.org; Wed, 24 Mar 2004 18:00:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6HLT-0001YW-00 for mmusic-web-archive@ietf.org; Wed, 24 Mar 2004 17:59:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6HKw-0001VQ-00 for mmusic-web-archive@ietf.org; Wed, 24 Mar 2004 17:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HKw-0000YC-4K; Wed, 24 Mar 2004 17: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 1B6HKP-0000WP-9w for mmusic@optimus.ietf.org; Wed, 24 Mar 2004 17:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27138 for ; Wed, 24 Mar 2004 17:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6HKM-0001U5-00 for mmusic@ietf.org; Wed, 24 Mar 2004 17:58:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6HJS-0001RR-00 for mmusic@ietf.org; Wed, 24 Mar 2004 17:57:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6HIv-0001Oo-00; Wed, 24 Mar 2004 17:56:57 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2004 14:56:28 -0800 Received: from cisco.com (sjc-vpn2-220.cisco.com [10.21.112.220]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2OMuOew009638; Wed, 24 Mar 2004 14:56:25 -0800 (PST) Message-ID: <40621218.1820B9B9@cisco.com> Date: Wed, 24 Mar 2004 17:56:24 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yadavalli, Satya" CC: "'mmusic@ietf.org'" , "'Sipping@Ietf. Org'" References: <37A3C2F21006D611995100B0D0F9B73C0303C206@tnint11.telogy.design.ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [Sipping] SIP - SRTP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Both of these drafts are relevant. - MIKEY provides you with full control of all SRTP parameters (I believe) as well as native end-to-end security for the security parameters and key exchange. - sdescriptions defines a limited set of SRTP parameters to be negotiated (incl. fixed ciphersuites) and assumes that security is either provided hop-by-hop or end-to-end by means outside of sdescriptions itself (e.g. IPSec, TLS, or S/MIME). -- Flemming "Yadavalli, Satya" wrote: > > > Hi, > I am trying to find a specification (for SIP applications) that > describes specifying the SRTP media related needs (key exchanges > etc.,) in the SDP and found the following two drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-10.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-03.txt > > Could some one help me which of these is the draft that would help (or > is it both...havenot really looked into them) or are there any other > recommendations to follow. > > Are there any SIP implementations currently supporting SRTP? If so, > what is followed for specifying the SDP. > > Thanks, > Satya _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Mar 25 05:19: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 FAA13001 for ; Thu, 25 Mar 2004 05:19: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 1B6Rwo-0008GL-Ck for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 05:18:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PAIoRR031756 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 05:18:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rwm-0008Fx-E9 for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 05:18: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 FAA12762 for ; Thu, 25 Mar 2004 05:18:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Rwi-0006eC-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 05:18:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Rua-00068i-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 05:16:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6RtL-0005wi-03 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 05:15:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RhR-0006HN-74; Thu, 25 Mar 2004 05:02:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RdR-0005kn-9e for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 04:58:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11757 for ; Thu, 25 Mar 2004 04:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6RdN-0004YW-00 for mmusic@ietf.org; Thu, 25 Mar 2004 04:58:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6RcO-0004QK-00 for mmusic@ietf.org; Thu, 25 Mar 2004 04:57:45 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B6RbS-0004IF-00 for mmusic@ietf.org; Thu, 25 Mar 2004 04:56:46 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2P9ukqY026430 for ; Thu, 25 Mar 2004 10:56:46 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 10:56:45 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS6S6D9; Thu, 25 Mar 2004 10:57:00 +0100 Message-ID: <4062ACDD.6050006@ericsson.com> Date: Thu, 25 Mar 2004 10:56:45 +0100 X-Sybari-Trust: 2e7565e6 2c4885b5 215009a1 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)" CC: Stephan Wenger , Thomas Stockhammer , Dave Singer , "Miska Hannuksela" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2004 09:56:45.0785 (UTC) FILETIME=[7B8E3490:01C4124F] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Offer/Answer model does not work for H.264 parameters 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, In the effort to finalize H.264 we authors very trying to fine tune the Offer/Answer section the RTP payload format for H.264. Latest published version is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-04.txt When doing this we have found a serious problem with the H.264 parameters and the negotiation model in offer/answer (O/A). The problem is that H.264 has 5 parameters that are declarative and set by the media sender. These parameters are: - max-don-diff - init-buf-time - parameter-sets - interleaving-depth - deint-buf-size More information on them can be found in the last version of the RTP payload format. Some of them can also be used for capability declaration, but for that functionality there is no problem. The problem is when they are used to describe a media stream that will be sent to the receiver. For example parameter-sets is parameter carrying decoder configuration information. This information is determined by the encoder implementation and configuration, prior or during encoding (in case of pre-encoded material). The whole H.264 coder is built on giving the encoder the freedom to set the parameter-sets, and it can freely determine these parameters within the limitation set by the profile and level in use. This clashes with the O/A model that is based on that the receiver declares what it can receive. For a media encoder and its payload format it means that all media parameters that one specifies are either a fixed configuration on how the information I will receive must look like, or a capability declaration. An example of the first case is the AMR payload format, where a receiver would specify that the payload format configuration used are octet-aligned mode with interleaving. A case of the second is the H.264 "max-br" parameter which defines the maximum bit-rate that a receiver is capable of handling, thus puts restriction on what the sender is allowed to use. In the case of the 5 parameters above they all work in the opposite direction. The sender determines and declares the configuration that it will use. As a complication the possible values for these parameters are restricted through receiver declared capabilities. In the case of the parameter-sets the limitation is based on video codec profile and level as declared by the receivers "profile-level-id" parameter. In the case of the other parameters they are restricted by the capability version of the two parameters "interleaving-depth", and "deint-buf-size". To get this two work in a full fledged way, the negotiation taking place between a H.264 sender and receiver would be the following. 1. Receiver declares its capabilities to sender. 2. Sender declares its configuration that fits within the receivers capabilities. However I don't see how this would be possible to get to work in O/A. Any suggestion how to get this to work is greatly appreciated. One possible solution that will give partial functionality would be the following. Offerer declares its own capabilities on what it will receive. At the same time it assumes symmetric configuration and declares the parameters it will use to send that falls within its own receiver capabilities. This will require splitting the "interleaving-depth", and "deint-buf-size" two different parameters, one for capabilities and one for declaration. The offerer will have to make a leap of faith as it must construct the sender configuration prior to knowing the receivers capabilities. The answerer receiver the offer. If its capabilities matches those of the sender it can declare its receiving capabilities equal to those capabilities. Then it also declares its sending parameters that fits within the offerer's capabilities. If the sender does not have matching capabilities it must remove that media alternative. To avoid total rejection of a stream the offerer can include multiple payload types with different levels of capabilities. When the offerer receives the answer it checks which of its offers the answerer accepted and what parameters the answerer will use to send. This will put certain restriction on how to handle the payload types and their numbers. Also the risk of rejection will be high if the offerer and answerer are not well matched, or the offerer goes to considerable effort of constructing multiple well structured payload types. Any more problems with the above proposal? 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 Thu Mar 25 09:55: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 JAA26036 for ; Thu, 25 Mar 2004 09:55: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 1B6WGG-0007JI-Ld for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 09:55:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEtCLG028099 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 09:55:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WGG-0007J8-GE for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:55: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 JAA25975 for ; Thu, 25 Mar 2004 09:55:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WGE-0003rd-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 09:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WF8-0003jQ-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 09:54:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6WEK-0003eG-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 09:53:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WEK-00071P-IS; Thu, 25 Mar 2004 09:53:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WDQ-0006yv-Ou for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 09:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25781 for ; Thu, 25 Mar 2004 09:52:13 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WDO-0003X7-00 for mmusic@ietf.org; Thu, 25 Mar 2004 09:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WCN-0003S8-00 for mmusic@ietf.org; Thu, 25 Mar 2004 09:51:12 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B6WBT-0003NL-00 for mmusic@ietf.org; Thu, 25 Mar 2004 09:50:16 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2PEnWI22707; Thu, 25 Mar 2004 16:49:32 +0200 (EET) X-Scanned: Thu, 25 Mar 2004 16:47:36 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2PEla31010799; Thu, 25 Mar 2004 16:47:36 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 003tMXYl; Thu, 25 Mar 2004 16:47:33 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 i2PEjjs04077; Thu, 25 Mar 2004 16:45:45 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 16:45:40 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 16:45:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt Date: Thu, 25 Mar 2004 16:45:39 +0200 Message-ID: Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt Thread-Index: AcQNxVEvjwnD50OqQuyrgvFWE4nViAEr+Xzg To: Cc: , , , , , X-OriginalArrivalTime: 25 Mar 2004 14:45:40.0432 (UTC) FILETIME=[D7CF6D00:01C41277] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus Thanks for the additional comments. On the subject of intermittent = connectivity you are "a bit worried that different persons will have = significant different interpretation of what derivative requirements = these open requirements results in". Can you explain the problem a little please? (I assume it is associated = with "The IMG system SHOULD allow for hosts with intermittent = connectivity"). As a guess at the derivative requirements you mention, my understanding = of the base requirement is: permanent connectivity should not be assumed = for all terminals of all IMG deployments, the IMG system should not = break if some delivery protocols enable intermitted delivery (for = intermittent connectivity), it is up to the appropriate delivery = protocols and data model to provide service for hosts with intermittent = connectivity when a deployment needs this feature. On one hand I would be happy changing SHOULD to MUST, although on the = other hand I am happy with the implied requirements I would understand = from the base requirement (and just stating the base requirement is a = lot less verbose). If I'm, having a woods and trees lack of vision, = please give me an idea of some problematic implied requirements. Ultimately, I need an idea of whether... REQ REL-3: The IMG system SHOULD allow for hosts with intermittent=20 connectivity. The implication of intermittent connectivity is that immediate=20 distribution of changes becomes infeasible and so managing data=20 consistency should be focused on the timely delivery of data. ...is sufficient within the scope of an Informational Requirements = document in you opinion, and if there are specific improvements that are = necessary. Alternatively an extended version could be: REQ REL-3: The IMG system SHOULD allow for hosts with intermittent=20 connectivity. The implication of intermittent connectivity is that immediate=20 distribution of changes becomes infeasible and so managing data=20 consistency should be focused on the timely delivery of data. Please note, these are some anticipated implications of this=20 requirement: permanent connectivity is not assumed for all=20 terminals of all IMG deployments, the IMG system will not break=20 if some delivery protocols enable intermitted delivery (for=20 intermittent connectivity), it is the task of an appropriate=20 delivery protocol(s) and metadata fragmentation to provide=20 consistent service for hosts with intermittent connectivity=20 when a deployment needs this feature. (The related thread text is copied below). Cheers, Rod. > >>3. Section 5.4.1: Last paragraph: I think that the intermittent=20 > >>connectivity actually should be formulated into a requirement: > >> > >>REQ: "The IMG system SHOULD allow for low cost=20 > >>uptodate/consistency checks." > >=20 > >=20 > > Good suggestion. For the mobile/cellular type cases "allowing > > intermittent connectivity" is somehow bound to "enabling low cost > > consistency messaging". For other cases intermittent=20 > connectivity is not > > related to cost of communications (e.g. limited=20 > HW-accelerated header > > filtering resources, or power-reduction by sending a=20 > connection idle, in > > broadcast receivers; or shutting down background Internet=20 > activity when > > a user is not active - for security). So how about this =20 > rewrite of the > > last paragraph... > >=20 > > REQ REL-3: The IMG system SHOULD allow for hosts with=20 > intermittent=20 > > connectivity. > >=20 > > The implication of intermittent connectivity is that immediate=20 > > distribution of changes becomes infeasible and so managing data=20 > > consistency should be focused on the timely delivery of data. > >=20 > > This would also require "REL-3" -> "REL-4" number re-alignment. > >=20 >=20 > Okay, if one knows enough one understand that intermittent=20 > connectivity=20 > will result in follow up claims. And this requirement is=20 > probably wider=20 > than what I thought of, which is good. >=20 > I am a bit worried that different persons will have significant=20 > different interpretation of what derivative requirements these open=20 > requirements results in. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Mar 25 12:26:58 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 MAA09184 for ; Thu, 25 Mar 2004 12:26: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 1B6Ycg-0007Br-VR for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 12:26:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PHQUdh027638 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 12:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ycg-0007Bh-Rk for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 12:26: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 MAA09166 for ; Thu, 25 Mar 2004 12:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ycf-0002D8-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 12:26:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ybn-0002Ah-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 12:25:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6YbE-00027j-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 12:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YbE-00073D-Eh; Thu, 25 Mar 2004 12:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YaG-0006wJ-UL for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 12:24:00 -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 MAA08947 for ; Thu, 25 Mar 2004 12:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6YaC-00022r-00 for mmusic@ietf.org; Thu, 25 Mar 2004 12:23:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6YZM-0001vd-00 for mmusic@ietf.org; Thu, 25 Mar 2004 12:23:04 -0500 Received: from [220.117.193.250] (helo=lapis.nextreaming.com) by ietf-mx with esmtp (Exim 4.12) id 1B6YYU-0001lv-00 for mmusic@ietf.org; Thu, 25 Mar 2004 12:22:10 -0500 Content-class: urn:content-classes:message Subject: RE: [MMUSIC] Offer/Answer model does not work for H.264 parameters MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Mar 2004 02:22:05 +0900 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [MMUSIC] Offer/Answer model does not work for H.264 parameters Thread-Index: AcQSUIsqYe7LalOhQ++btvcahsMxmgAOmtJQ From: "Jae-Hwan Kim" To: "Magnus Westerlund" Cc: "mmusic (E-mail)" 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.1 required=5.0 tests=AWL,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus, Question for you. How to provide multiple capability list?=20 One possible choice we can use is to make multiple 'm=3D'line in the = SDP. The second is something like RTSP transport headerfield. Or... do you have any idea you already considering? Thanks in advance and Best Regards, Jae-Hwan > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Thursday, March 25, 2004 6:57 PM > To: mmusic (E-mail) > Cc: Stephan Wenger; Thomas Stockhammer; Dave Singer; Miska Hannuksela > Subject: [MMUSIC] Offer/Answer model does not work for H.264=20 > parameters >=20 >=20 > Hi, >=20 > In the effort to finalize H.264 we authors very trying to=20 > fine tune the=20 > Offer/Answer section the RTP payload format for H.264. Latest=20 > published=20 > version is: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-04.txt >=20 > When doing this we have found a serious problem with the H.264=20 > parameters and the negotiation model in offer/answer (O/A).=20 > The problem=20 > is that H.264 has 5 parameters that are declarative and set=20 > by the media=20 > sender. These parameters are: > - max-don-diff > - init-buf-time > - parameter-sets > - interleaving-depth > - deint-buf-size >=20 > More information on them can be found in the last version of the RTP=20 > payload format. Some of them can also be used for capability=20 > declaration, but for that functionality there is no problem.=20 > The problem=20 > is when they are used to describe a media stream that will be sent to=20 > the receiver. For example parameter-sets is parameter=20 > carrying decoder=20 > configuration information. This information is determined by=20 > the encoder=20 > implementation and configuration, prior or during encoding=20 > (in case of=20 > pre-encoded material). The whole H.264 coder is built on giving the=20 > encoder the freedom to set the parameter-sets, and it can freely=20 > determine these parameters within the limitation set by the=20 > profile and=20 > level in use. >=20 > This clashes with the O/A model that is based on that the receiver=20 > declares what it can receive. For a media encoder and its=20 > payload format=20 > it means that all media parameters that one specifies are=20 > either a fixed=20 > configuration on how the information I will receive must look=20 > like, or a=20 > capability declaration. An example of the first case is the=20 > AMR payload=20 > format, where a receiver would specify that the payload format=20 > configuration used are octet-aligned mode with interleaving.=20 > A case of=20 > the second is the H.264 "max-br" parameter which defines the maximum=20 > bit-rate that a receiver is capable of handling, thus puts=20 > restriction=20 > on what the sender is allowed to use. >=20 > In the case of the 5 parameters above they all work in the opposite=20 > direction. The sender determines and declares the=20 > configuration that it=20 > will use. As a complication the possible values for these=20 > parameters are=20 > restricted through receiver declared capabilities. In the case of the=20 > parameter-sets the limitation is based on video codec profile=20 > and level=20 > as declared by the receivers "profile-level-id" parameter. In=20 > the case=20 > of the other parameters they are restricted by the capability=20 > version of=20 > the two parameters "interleaving-depth", and "deint-buf-size". >=20 > To get this two work in a full fledged way, the negotiation=20 > taking place=20 > between a H.264 sender and receiver would be the following. > 1. Receiver declares its capabilities to sender. > 2. Sender declares its configuration that fits within the receivers=20 > capabilities. >=20 > However I don't see how this would be possible to get to work in O/A.=20 > Any suggestion how to get this to work is greatly appreciated. >=20 > One possible solution that will give partial functionality=20 > would be the=20 > following. >=20 > Offerer declares its own capabilities on what it will receive. At the=20 > same time it assumes symmetric configuration and declares the=20 > parameters=20 > it will use to send that falls within its own receiver capabilities.=20 > This will require splitting the "interleaving-depth", and=20 > "deint-buf-size" two different parameters, one for=20 > capabilities and one=20 > for declaration. The offerer will have to make a leap of faith as it=20 > must construct the sender configuration prior to knowing the=20 > receivers=20 > capabilities. >=20 > The answerer receiver the offer. If its capabilities matches those of=20 > the sender it can declare its receiving capabilities equal to those=20 > capabilities. Then it also declares its sending parameters that fits=20 > within the offerer's capabilities. If the sender does not=20 > have matching=20 > capabilities it must remove that media alternative. To avoid total=20 > rejection of a stream the offerer can include multiple payload types=20 > with different levels of capabilities. >=20 > When the offerer receives the answer it checks which of its=20 > offers the=20 > answerer accepted and what parameters the answerer will use to send. >=20 > This will put certain restriction on how to handle the=20 > payload types and=20 > their numbers. Also the risk of rejection will be high if the offerer=20 > and answerer are not well matched, or the offerer goes to=20 > considerable=20 > effort of constructing multiple well structured payload types. >=20 > Any more problems with the above proposal? >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > 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 >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Mar 25 13:46: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 NAA13419 for ; Thu, 25 Mar 2004 13:46: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 1B6Zs3-0000g8-MN for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 13:46:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PIkRvo002607 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 13:46:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zs3-0000fy-Fv for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 13:46: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 NAA13394 for ; Thu, 25 Mar 2004 13:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zs1-0007Py-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:46:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zr9-0007NF-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:45:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZqB-0007Kd-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:44:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZqB-0000Pd-Ks; Thu, 25 Mar 2004 13:44:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZoJ-0000LC-Nw for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 13:42: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 NAA13317 for ; Thu, 25 Mar 2004 13:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZoH-0007Fv-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ZnF-0007Di-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:41:30 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zmi-0007BW-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:40:56 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2PIespB006792 for ; Thu, 25 Mar 2004 11:40:55 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HV50086PAK62X@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 25 Mar 2004 10:40:54 -0800 (PST) Date: Thu, 25 Mar 2004 10:41:32 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 question about Scale and Speed headers In-reply-to: <40605FC5.8070109@ericsson.com> To: Magnus Westerlund Cc: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <406327DC.50109@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B377A.5030909@sun.com> <40605FC5.8070109@ericsson.com> 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 Thanks for clarifying this one too. geetha Magnus Westerlund wrote: > Hi Geetha, > > Thanks for the comments. > > Geetha Srikantan wrote: > >> Section 14.34, 14.35, page 82: >> Are the Scale and Speed headers restricted to on-demand streaming? >> > > No, but in most other cases the server will not be able to perform the > necessary operations. In these cases the server will have to reject > the request. > > 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 Thu Mar 25 13:47:01 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 NAA13436 for ; Thu, 25 Mar 2004 13:47:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zs9-0000gg-B6 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 13:46:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PIkX0D002636 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 13:46:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zs9-0000gR-7W for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 13:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13404 for ; Thu, 25 Mar 2004 13:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zs6-0007Ql-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ZrC-0007Nr-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:45:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZqW-0007Kp-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:44:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZqX-0000T9-Lw; Thu, 25 Mar 2004 13:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zo8-0000L2-Sk for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 13:42: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 NAA13304 for ; Thu, 25 Mar 2004 13:42:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zo6-0007F3-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ZnA-0007Cr-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:41:25 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZmU-00079N-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:40:42 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2PIeBni013927 for ; Thu, 25 Mar 2004 10:40:12 -0800 (PST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HV5008U6AIY2X@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 25 Mar 2004 10:40:11 -0800 (PST) Date: Thu, 25 Mar 2004 10:40:48 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 Supported header question In-reply-to: <4060558E.4020202@ericsson.com> To: Magnus Westerlund Cc: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <406327B0.8010107@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B372B.2030807@sun.com> <4060558E.4020202@ericsson.com> 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 Magnus, Thanks for clarifying this one. geetha Magnus Westerlund wrote: > Hi Geetha, > > Thanks for the comments. > > Geetha Srikantan wrote: > >> Section 10, page 38: >> If a server receives a Supported header with multiple values in the >> request, and the server supports at least one of the options supported >> by the client, should the server respond with status code 200? >> > > The supported header usage does not effect what the response code will > be. The response code is directly related to the request itself. So a > supported header in the response shall be include even if the response > is 400 or 500. > > The supported header may be included in any request. This supported > header will include all feature-tags supported by the requester. The > receiver of the request must simply respond with its own supported > header. > > I think it is obvious that we need a bit more text on the supported > header. The current section is very short, but there are also text in > the capability handling section. I will add a reminder bug to extend > this section. > > Cheers > > Magnus > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Mar 25 13:48:56 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 NAA13527 for ; Thu, 25 Mar 2004 13:48:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zu1-00012X-1g for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 13:48:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PImTwo003991 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 13:48:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zu0-00012I-UR for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 13:48:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13501 for ; Thu, 25 Mar 2004 13:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zty-0007WP-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:48:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zt5-0007UL-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:47:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZsT-0007S6-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 13:46:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZsU-0000nC-Nn; Thu, 25 Mar 2004 13:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zq2-0000PJ-Ci for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 13:44: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 NAA13335 for ; Thu, 25 Mar 2004 13:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zq0-0007Ik-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:44:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zp2-0007HD-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:43:21 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZoE-0007Ff-00 for mmusic@ietf.org; Thu, 25 Mar 2004 13:42:30 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2PIgTpD007775 for ; Thu, 25 Mar 2004 11:42:30 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HV5008QBAMT2X@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 25 Mar 2004 10:42:29 -0800 (PST) Date: Thu, 25 Mar 2004 10:43:07 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 question on trn-param-ext In-reply-to: <40606051.8090504@ericsson.com> To: Magnus Westerlund , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <4063283B.9040501@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B3DC6.5050001@sun.com> <40606051.8090504@ericsson.com> 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 Magnus, Thanks for the explanation. It would be good to provide such an explanation in the draft too. geetha Magnus Westerlund wrote: > Hi Geetha, > > Geetha Srikantan wrote: > >> Section 17.2.3 page 112: >> What is the intended use of 'trn-param-ext'? >> > > To have a clear indication that the transport header can be extended. > Reasons for extending this will for example be new transport protocols > that needs further parameters than currently is present. With the > feature tag system one can ensure that the receiver of a request can > correctly understand the request, and not skip necessary parameters. > > > 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 Thu Mar 25 14:14:06 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 OAA14392 for ; Thu, 25 Mar 2004 14:14:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aIM-0003SH-HR for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 14:13:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJDclr013275 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 14:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aIM-0003S2-C6 for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 14:13:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14369 for ; Thu, 25 Mar 2004 14:13:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aIJ-000132-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 14:13:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aHO-0000yG-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 14:12:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6aGf-0000un-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 14:11:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aGg-0003EQ-B7; Thu, 25 Mar 2004 14:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aFL-00039o-Ow for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 14:10: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 OAA14256 for ; Thu, 25 Mar 2004 14:10:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aFJ-0000o6-00 for mmusic@ietf.org; Thu, 25 Mar 2004 14:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aET-0000kr-00 for mmusic@ietf.org; Thu, 25 Mar 2004 14:09:38 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6aDb-0000hf-00 for mmusic@ietf.org; Thu, 25 Mar 2004 14:08:43 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2PJ8gpB026076 for ; Thu, 25 Mar 2004 12:08:43 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HV500FQXBUHYG@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 25 Mar 2004 11:08:42 -0800 (PST) Date: Thu, 25 Mar 2004 11:09:19 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 minor comments In-reply-to: <40607157.3060509@ericsson.com> To: Magnus Westerlund Cc: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <40632E5F.5010405@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B36A3.6060000@sun.com> <40607157.3060509@ericsson.com> 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 Magnus, Thanks for the response. I'll skip over the obvious typo and editorial issues. Thanks for addressing them right away. Comments inline for the rest of the items. geetha Magnus Westerlund wrote: > Hi Geetha, > > Thanks for the comments. Comments inline. > > Geetha Srikantan wrote: > >> Here are some minor - at least, I think they're minor :-) >> - comments on draft-ietf-mmusic-rfc2326bis-06.txt. >> >> Section 3.7, page 24: It would be helpful to provide a forward >> reference to the feature tag discussion in section 19. > > > I guess that you mean section 10 capability handling. Actually I meant section 19, where feature tags are explained in some detail. In addition, a reference to section 10 would be good too. >> >> Section 6.1, page 26: >> 'Please note: The request...' >> This line seems to contradict what was in bullet #3 of 1.6 on page 17. >> Which is correct - this line here or 1.6? > > > No, they are not really contradicting, slightly differently interpreted. > Section 1.6 says: " > A new version of the protocol can be defined, allowing almost > all aspects (except the position of the protocol version > number) to change." > > Section 6.1: > "Please note: The request line's syntax can't be changed in future > versions of RTSP, as this line indicates the version of the messages > and need to be parsable also by older versions." > > If one changes the syntax of the request line on does in fact change > the position of the protocol version. The text in 6.1 is simply > stricter of what in fact must be required by an updated version. > > I could soften the language in section 6.1 to the following: > Please note: The request line's syntax can't be freely changed in > future versions of RTSP, as this line indicates the version of the > messages and need to be parsable also by older versions. Sounds good.. > Section 11.3, page 44: > >> SSRC: If the SSRC of the media stream changes mid-stream due to SSRC >> collision in a multicast say, there is no way to signal it via RTSP. >> Should we add a note about that? (This is the same as in RFC 2326.) > > > I agree that there is no way to signal it. However this does not > belong in this section. Instead it belongs to the appendix B deciding > RTP usage. > > New proposed text for that section is: > An SSRC collision with the SSRC that transmits media does also has > consequences, as it will force it to change its SSRC in accordance > with the RTP specification ~\cite{rfc3550}. This will result in a > loss of synchronization context, and require any receiver to wait > for RTCP sender reports for all media requiring synchronization > before being able to play out synchronized. Due to these reasons a > client joining a session should take care to not select the same > SSRC as the server. Any SSRC signalled in the \header{Transport} > header {\SHOULD} be avoided. Also a client detecting a collision > prior to sending any RTP or RTCP messages can also select a new > SSRC. This is fine with minor suggestions on wording: 1st sentence: ...does also has -> has 2nd sentence: ...able to play out synchronized -> able to synchronize media play out >> Section 11.4, page 47: >> An example of live streaming would be very helpful. >> BTW, the examples in section 11.5 are excellent. > > > Isn't section 16.4 enough? What aspects do you desire an example to > cover. Could you please present the example you would like to be > included? The example in 16.4 talks about multicast live streams. It would be helpful to have a unicast live example similar to the one in 16.4. Either location for such an example, i.e. 11.4 or 16.4, would be fine. I can provide the example in a separate message. >> Section 11.10, page 57: >> 1st paragraph, 2nd sentence: >> PING does have the side effect of updating the session >> liveness, even though it doesn't cause any state change. > > > No, not in my version the first paragraph says: > "This method is a bi-directional mechanism for server or client > liveness checking. It has no side effects. The issuer of the request > MUST include a session header with the session ID of the session that > is being checked for liveness." I should clarify what I meant. The text you quote above says there is no side effect of the PING method, however in Section 11.3 on page 44 there is a discussion about liveness signs. Here it says any RTSP method with a session id can be used to 'update' liveness of a session - and presumably the timeout value of the session. This is a side effect, is it not? I agree that there is no state change - a session continues to remain in whatever state it was, after the PING request is processed. >> >> Section 14.29, page 78: >> 1st paragraph: 10.08 is before 10.1, the text seems to indicate >> otherwise.. > > > > "Ranges are half-open intervals, including the first point, but > excluding the second point. In other words, a range of A-B starts > exactly at time A, but stops just before B. Only the start time of a > media unit such as a video or audio frame is relevant. As an example, > assume that video frames are generated every 40 ms. A range of > 10.0-10.1 would include a video frame starting at 10.0 or later time > and would include a video frame starting at 10.08, even though it > lasted beyond the interval. A range of 10.0-10.08, on the other hand, > would exclude the frame at 10.08." > > What is the problem with the section? I don't understand what you > interpret as indicating that 10.08 is after 10.1? The 4th sentence: 'A range of 10.0-10.1 would include...., even though it lasted beyond the interval.' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This was confusing..it might help to skip that phrase from the sentence? >> Section 14.40, page 92: >> An example with src_addr and dest_addr would be very helpful. >> An example with non-contiguous RTP/RTCP ports would be helpful too. > > > See example 16.2. It doesn't have non-contiguous ports, but as all > ports are given explicitly I don't think this is a problem. Yes I did see the example in 16.2 also. Providing a forward reference to 16.2 in this section would help since two new parameters 'src_addr' and 'dest_addr' are being introduced in this draft. Some guidance on usage would help. > Section B.1.2, page 127: > >> 1st bullet, last line: Not sure what it means. >> > o RTP/UDP packet from the server to the client SHALL be sent to > the address specified in the "destination" parameter and first > even port number given in client_port range. If there is only > a single port number given that MUST be given. > > I think the intent is to clarify that if no range is given, the RTP > port must be explicitly given. For a range the first even number is > used. Thus there is certain differences. > > I propose to change the last sentence to: > If only a RTP > port is to be specified, then only that even port number {\SHALL} > be given, i.e. no range starting at a odd number {\SHALL} be used. > > Better? Yes..thanks! >> Section B.1.4, page 129: >> 1st paragraph, Last sentence: >> There is a possibility of RTP timestamps in consecutive RTP packets >> not being monotonic, according to the RTP spec. I can see that >> sequence numbers should be monotonically increasing, however, can we >> really mandate the same for the RTP timestamps? >> > > In respect to: > "Thus, both RTP sequence numbers and RTP timestamps MUST be | > continuous and monotonic across jumps of NPT." > > This is not a general rule that always apply, it only is given for > jumps in NPT. It could not possibly work correctly if the timestamp do > not increase between a media packet belonging to another NPT than > after the NPT jump. So even when jumping backwards in NPT one must > increase the TS to make the client present the packet correctly after > the previous range. I understand that this section only applies to cases where NPT jumps happen. This is probably ok. geetha > > 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 Thu Mar 25 14:29: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 OAA15154 for ; Thu, 25 Mar 2004 14:29: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 1B6aXg-00059Q-7y for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 14:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJTS77019794 for mmusic-archive@odin.ietf.org; Thu, 25 Mar 2004 14:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aXg-00059B-34 for mmusic-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 14:29:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15118 for ; Thu, 25 Mar 2004 14:29:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aXd-0001wB-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 14:29:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aWl-0001tz-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 14:28:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6aVy-0001rd-00 for mmusic-web-archive@ietf.org; Thu, 25 Mar 2004 14:27:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aVz-0004vT-DR; Thu, 25 Mar 2004 14:27:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aTo-0004k0-Av for mmusic@optimus.ietf.org; Thu, 25 Mar 2004 14:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14907 for ; Thu, 25 Mar 2004 14:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aTl-0001je-00 for mmusic@ietf.org; Thu, 25 Mar 2004 14:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aSq-0001gX-00 for mmusic@ietf.org; Thu, 25 Mar 2004 14:24:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6aRy-0001eh-00 for mmusic@ietf.org; Thu, 25 Mar 2004 14:23:34 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2PJNYpB005294 for ; Thu, 25 Mar 2004 12:23:34 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HV500FLQCJ9YG@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 25 Mar 2004 11:23:34 -0800 (PST) Date: Thu, 25 Mar 2004 11:24:12 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <40605F48.9030001@ericsson.com> To: Magnus Westerlund Cc: mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <406331DC.2080203@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> 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 Magnus, I'm still reviewing your response. A couple of questions about your response.. Are you assuming : (a) That all live sources are RTSP-aware? (b) The server could maintain it's own RTP clock for each stream by observing the RTP timestamps of packets on each stream? (c) The live source's transmission schedule for packets follows the RTP timestamp clock? That is, each succeeding packet's RTP timestamp will be equal to or greater than all previous packets, for that stream (modulo rollover)? thanks geetha Magnus Westerlund wrote: > Hi Geetha, > > Thanks for the comments. See comments inline. > > Geetha Srikantan wrote: > >> This draft addresses the on-demand streaming case very well, however >> I believe there are some issues in live streaming that need >> clarification. >> The issues are in the use of the RTP-Info header, the Range header and >> ssrc parameter in the Transport header. The points are related, so I >> will cover >> them in a single message. >> >> >> Section 11.3, page 44: 4th paragragh: >> '...SHOULD also include the RTP-Info header..' >> >> This requirement is fine for on-demand content, however it creates >> complications >> for live media. There are many reasons why the RTP-Info cannot be >> populated >> accurately by the server for live content: >> (a) Arbitrary delays between live source and server - If there are >> several relay nodes between source and server, there maybe a skew >> in system clocks of each node that tries to correlate >> NPT <-> RTP timestamp (i.e. Range header <-> RTP-Info's rtptime). > > > I don't see how this clock skew effects anything. The binding in a > PLAY response of RTP-Info and Range header is not dependent on at what > time you receive the play response or the media stream. The > synchronization mechanism in both RTCP and in RTSP are not dependent > on any synchronization of the receiver clock to any other clock. One > binds all present media streams to a common clock reference. In most > case for RTSP the NPT time. In RTSP this is accomplished by giving the > corresponding RTP TS for a given NPT time. > > In fact any media streams properly timestamped can be synchronized as > long as any data point for synchronization against the common time > scale exist. > > I don't see any reason why there would be skew even in a multi-tire > distribution system. When the first host has established the > synchronization information he can forward it, without any dependency > of its local clock. > >> (b) Lost packets between live source and server, imply that the server >> cannot accurately predict the next packet's sequence number. > > > Also here I can't see the problem. The RTP sequence number indicates > the first sequence number for a stream that the given synchronization > information and time range applies for. Thus if one receives a RTP > packet with a higher sequence number one knows that it is for the new > range. > > A relay server that has received at least one packet can give this > information that is valid even if a several RTP packets is lost before > one gets forward. The client can't determine if the loss is between > the relay or before. > > And if the server really has not received either the information from > a upstream source or any RTP packet when responding, this value can be > excluded. The RTP-Info header only requires either of the values to be > present. > > Also if one really can't establish the information one is allowed to > excluded. It is after all a SHOULD not a MUST. However in general it > seems reasonable that a server will be able to provide this information. > >> >> For these reasons, the RTP-Info header is not very useful for live >> streaming, and RTCP-based stream synchronization is preferred for live >> streams. In any case RTP-Info is only useful for initial stream >> synchronization. During a long-running live session the client has to >> rely on RTCP for ongoing stream synchronization. >> This is a motivation to drop RTP-Info entirely for live streams. > > > What is the problem with long run session? If the original data source > does not have a problem with its clock their should not be any clock > skew entered into the RTP timestamp. And if that occur this can be > corrected by RTCP sender reports. Any local clock skew between media > will need to be detected and dealt by the client locally. > >> >> Section 11.4, page 45: >> 2nd last paragraph: >> >> Range header for live streams: >> There is a subtle difference in the semantics of the Range header for >> live >> streams versus on-demand streams. For on-demand streams, the Range >> header's start value refers to the presentation time, i.e. NPT of the >> presentation. >> For live streams, the Range header's start value indicates either >> (a) the duration of time between the start of the live session and the >> time when this Range header was created, or, >> (b) the wall-clock time at the server responding to PLAY requests. >> > > In both these cases the time is as viewed by the origin server. In a > relay structure, it is not the local time of each relay. Using RTSP > for relay will provide all relay servers also with the correct view of > the NPT or wall clock time of the origin server. > >> Also the main purpose of the Range header is to map the NPT to >> the RTP timestamp. As discussed above this mapping is not terribly >> accurate in several live streaming scenarios. > > > As I don't think it is any less accurate then for on-demand media I > don't understand what the problem is. > >> >> If the live streams are part of a multicast session then there would >> be an indication of the time when the session is active in the SDP, >> however, with clock skews etc, it is diffcult to accurately pinpoint >> the instantaneous time in the session. > > > The instantaneous time is calculated based of the RTP timestamp for a > given media and the mapping received by Range and RTP-Info between RTP > timestamp and NPT at any point > > Example: > > Sync point > -----|------------------------------------x------> t > TS A B > > > When one started the session one received by Range and RTP-Info the > following information for RTP TS A. > > PLAY response: > Range: npt=56.97- > RTP-Info: url=; rtptime=164400 > > Thus A = 1644000 > The media timestamp rate is 90kHz. > > The NPT time for B=465357 is: > > (465357-164400)/90000 + 56.97 = 60,3139666 s > > >> >> If the start time of the live session is not known, then 'npt=now-' >> is the only reasonable value for the Range header in a PLAYresponse. >> > > I agree that if one truly does not know the time since session start > it is a viable operation. However all functionality exist to know the > time. > >> For this reason, it would be good to *not* require a Range header >> other than 'Range: npt=now-' for live streams. >> > > No, I think there are a lot of application that can benefit from > presenting the original wall clock or time since session start. > >> Perhaps this could also be the mechanism to signal to the client that >> this is a live stream and that it needs to perform stream >> synchronization strictly via RTCP sender reports. >> > > There are already text in there to indicate that the session has live > qualities. There are already reasons why a client must support > synchronization by RTCP. For example sender side clock skew > corrections, multiple sources using different SSRCs, the possibility > to exclude RTP-Info header. However the RTP-Info+Range header is a > reliable transferred information. Although not guaranteed to be > timely, it has a rather high probability to reach the client prior to > any RTCP message. Also in most case it should reach the client prior > to it finishing initial buffering, thus providing it with good initial > synchronization for all media streams. > >> >> Section 14.40, page 91: >> ssrc: >> The transport header in the server's response cannot populate the ssrc >> for each stream, accurately in certain scenarios. >> The source of the live stream may not be RTSP-aware, and the server >> has to rely on RTP/RTCP to determine ssrc for each stream. >> The server may have joined a multicast live session and receives, >> say, one of the streams. >> It also receives SETUP request from a client and needs to respond to >> SETUP from a client, >> before it sees the first packet of each stream. >> Dropping the ssrc parameter from the Transport header in the SETUP >> response would >> simplify this case. > > > It is possible to skip the SSRC, however not recommend as it indicates > for which SSRC the synchronization information in RTP-Info applies to. > Thus I would recommend that server awaits at least the first RTP > packet to determine what SSRC is used for media distribution. > > > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Mar 26 05:15: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 FAA10991 for ; Fri, 26 Mar 2004 05:15: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 1B6oMZ-0001No-Gd for mmusic-archive@odin.ietf.org; Fri, 26 Mar 2004 05:14:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QAEt8H005316 for mmusic-archive@odin.ietf.org; Fri, 26 Mar 2004 05:14:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oMZ-0001Nf-C7 for mmusic-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 05:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10973 for ; Fri, 26 Mar 2004 05:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oMW-0006pD-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 05:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oLd-0006k1-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 05:13:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6oKj-0006eH-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 05:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oKj-0001H5-OF; Fri, 26 Mar 2004 05: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 1B6oJn-0001GQ-ES for mmusic@optimus.ietf.org; Fri, 26 Mar 2004 05:12: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 FAA10877 for ; Fri, 26 Mar 2004 05:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oJk-0006YA-00 for mmusic@ietf.org; Fri, 26 Mar 2004 05:12:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oIs-0006TC-00 for mmusic@ietf.org; Fri, 26 Mar 2004 05:11:07 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B6oIC-0006Nj-00 for mmusic@ietf.org; Fri, 26 Mar 2004 05:10:24 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QAAPAh032692 for ; Fri, 26 Mar 2004 11:10:25 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 11:10:24 +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 HV8KZLHG; Fri, 26 Mar 2004 11:10:24 +0100 Message-ID: <40640190.5050905@ericsson.com> Date: Fri, 26 Mar 2004 11:10:24 +0100 X-Sybari-Trust: 47990d9b 2c4885b5 ae329ef6 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: Jae-Hwan Kim CC: "mmusic (E-mail)" Subject: Re: [MMUSIC] Offer/Answer model does not work for H.264 parameters References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2004 10:10:24.0854 (UTC) FILETIME=[8E2BF760:01C4131A] 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 Jae-Hwan, Multiple capability lists are accomplished easiest to my knowledge by including multiple RTP payload types. For example on payload type is a base-line with single-nalu mode payload format that will be possible to use by any receiver that implements H.264 with RTP transport. Then one can create another payload type which has higher requirements on receiver and senders and uses other modes of the payload format. Having multiple "m=" lines is a bad idea in my perspective for this. Cheers Magnus Jae-Hwan Kim wrote: > Hi Magnus, > Question for you. How to provide multiple capability list? > One possible choice we can use is to make multiple 'm='line in the SDP. > The second is something like RTSP transport headerfield. > Or... do you have any idea you already considering? > > Thanks in advance and Best Regards, > Jae-Hwan > > -- 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 Mar 26 08: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 IAA17760 for ; Fri, 26 Mar 2004 08: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 1B6qwP-00026L-ST for mmusic-archive@odin.ietf.org; Fri, 26 Mar 2004 08:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QD050k008077 for mmusic-archive@odin.ietf.org; Fri, 26 Mar 2004 08: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 1B6qwP-00026C-J4 for mmusic-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 08:00: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 IAA17740 for ; Fri, 26 Mar 2004 08:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6qwO-00078o-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 08:00:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6qvN-00071I-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 07:59:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6quR-0006uD-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 07:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6quQ-0001xn-61; Fri, 26 Mar 2004 07: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 1B6quL-0001wq-LN for mmusic@optimus.ietf.org; Fri, 26 Mar 2004 07:57: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 HAA17639 for ; Fri, 26 Mar 2004 07:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6quK-0006tA-00 for mmusic@ietf.org; Fri, 26 Mar 2004 07:57:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6qtM-0006lf-00 for mmusic@ietf.org; Fri, 26 Mar 2004 07:56:56 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B6qsM-0006b7-00 for mmusic@ietf.org; Fri, 26 Mar 2004 07:55:55 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QCtrqY011838 for ; Fri, 26 Mar 2004 13:55:53 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 13:55:53 +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 HV8K6HY0; Fri, 26 Mar 2004 13:55:53 +0100 Message-ID: <40642858.4050008@ericsson.com> Date: Fri, 26 Mar 2004 13:55:52 +0100 X-Sybari-Trust: a3a9d123 2c4885b5 ae329ef6 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)" CC: Jae-Hwan Kim Subject: Re: [MMUSIC] Offer/Answer model does not work for H.264 parameters References: <40640190.5050905@ericsson.com> In-Reply-To: <40640190.5050905@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2004 12:55:53.0038 (UTC) FILETIME=[ABD49EE0:01C41331] 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, I thought about the issue and there is a reason why one could need to have multiple media lines: to be able to declare asymmetric sending and receiving capabilities. This is best illustrated by the following example. It also clarifies a bit about what restrictions will need to be applied to make the negotiation mechanism work. Example: Below the offerer gives two sets of configurations. The parameter-sets are based on the offered profile and level. Notice that I am not very strict with parameter names or if levels exist. it is simply an example. Offer: PT: parameters m= 97 98 97: profile-level:extended, level=3; interleaved-mode; parameter-sets=O-1 98: profile-level:baseline,level=1; single-nalu-mode; parameter-sets=O-2 Parameter set O-2 would be used by the offerer to send a stream in accordance with the declared PT 98 from the offerer to the answerer. If the answerer would return something like this: PT: parameters m= 100 101 101: profile-level:extended, level=5; interleaved-mode; parameter-set=A-1 100: profile-level:baseline,level=1; single-nalu-mode; parameter-set=A-2 Then we have a problem: How to know if A-1, is a sender declaration belonging to payload type 97 or 98. This could be resolved in two ways: 1. Restrict payload type numbers to be the same, and use these to match. 2. Restrict the payload type declaration to be exactly the same, so one can use the parameters string to match that it belongs to the corresponding declaration. 3. Encode the senders parameter with what payload type is belongs to. There is a warning in RFC 3264 that due to H.323 there is certain cases where the PTs must change. This would make 1 in that case impossible. 2. will probably work better, as it would allow the answerer to add additional payload types for further capabilities. Please note that there is a requirement in O/A that at least one PT in a answer is from the offer. This solution will require more difficult comparisons. 3. This will make it impossible to have only a single round of offer and answer, as the initial offerer would need to update his offer to match the PTs that the answerer declares. Therefore I don't see this a viable solution. If one applies alternative 2 above an answer would need to look like this. The answerer would return something like this: PT: parameters m= 101 102 100 101: profile-level:extended, level=5; interleaved-mode; parameter-set=A-1 100: profile-level:baseline,level=1; single-nalu-mode; parameter-set=A-2 102: profile-level:extended, level=3; interleaved-mode; parameter-set=A-3 The problem with this is that the offerer would need to update its offer and include a configuration in accordance with the Answers PT 101 in its offer. Thus requiring it to do another round of O/A. It also has the problem with that the Offer can't declare its sending parameters without also accepting to receive them, unless there is a send only stream. For send and receive streams it will not be possible to have non-symmetric receiving capabilities between the end-points. The solution as I see to this problem would require the offerer and answer to use at least two media streams. Otherwise an offerer would need to declare the video stream as two separate media sessions, one with sendonly, another with recvonly. Feedback is greatly appreciated. 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 Fri Mar 26 08:27: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 IAA18808 for ; Fri, 26 Mar 2004 08:27: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 1B6rMS-0003oN-8r for mmusic-archive@odin.ietf.org; Fri, 26 Mar 2004 08:27:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QDR0A4014650 for mmusic-archive@odin.ietf.org; Fri, 26 Mar 2004 08:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rMS-0003oD-5S for mmusic-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 08:27:00 -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 IAA18742 for ; Fri, 26 Mar 2004 08:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6rMQ-00028h-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 08:26:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6rLS-00023A-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 08:25:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6rKX-0001xx-00 for mmusic-web-archive@ietf.org; Fri, 26 Mar 2004 08:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rKX-0003gw-Gs; Fri, 26 Mar 2004 08:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rKV-0003gP-GP for mmusic@optimus.ietf.org; Fri, 26 Mar 2004 08:24: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 IAA18709 for ; Fri, 26 Mar 2004 08:24:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6rKU-0001xW-00 for mmusic@ietf.org; Fri, 26 Mar 2004 08:24:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6rJb-0001s8-00 for mmusic@ietf.org; Fri, 26 Mar 2004 08:24:03 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B6rIh-0001mS-00 for mmusic@ietf.org; Fri, 26 Mar 2004 08:23:07 -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 i2QDN3YG012728 for ; Fri, 26 Mar 2004 14:23:07 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 14:23:02 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HV9RC6YH; Fri, 26 Mar 2004 14:23:20 +0100 Message-ID: <40642EB6.8030100@ericsson.com> Date: Fri, 26 Mar 2004 14:23:02 +0100 X-Sybari-Trust: c5793904 2c4885b5 043b567d 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: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> <406331DC.2080203@sun.com> In-Reply-To: <406331DC.2080203@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2004 13:23:02.0965 (UTC) FILETIME=[7757BE50:01C41335] 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 Geetha, Answers below to what I assume. Geetha Srikantan wrote: > hi Magnus, > > I'm still reviewing your response. A couple of questions about your > response.. > > Are you assuming : > > (a) That all live sources are RTSP-aware? No, but that the there is a root-distributor that is a RTSP server. The root RTSP server can be synchronized using either standard RTP means or any proprietary solution as this interface is not standardized. However it will be this RTSP root server that will be responsible giving the stream a NPT time, unless that is also provided through the interface between RTSP and the live source. > > (b) The server could maintain it's own RTP clock for each stream by > observing > the RTP timestamps of packets on each stream? > I don't see how that this would be necessary. If one has a RTSP server that receives a RTP + RTCP media stream. It will after listened to this for a few seconds received all necessary synchronization information. If this is not the root server and is only a relay it can use RTSP to receive the synchronization information for the media streams it is forwarding directly in RTSP. > (c) The live source's transmission schedule for packets follows the RTP > timestamp clock? > That is, each succeeding packet's RTP timestamp will be equal to or > greater than all previous > packets, for that stream (modulo rollover)? > I am only assuming that this is a normal RTP media stream. Thus it can have backwards jump and other non-monotonic behaviour in the timestamp field. However I do expect that the RTP packets are sent in order, but not received by any relay in order. Thus a relay will be required to take certain care against reordering in the RTP-Info sequence number field. I am however relying on that RTCP stream contains SRs for all media streams sent to allow the server to make inter media synchronization, and to be able to correctly provide the NPT to TS mapping. 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 Mar 29 09:22:07 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 JAA03863 for ; Mon, 29 Mar 2004 09:22:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xdz-0004Id-KF for mmusic-archive@odin.ietf.org; Mon, 29 Mar 2004 09:21:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TELd1o016526 for mmusic-archive@odin.ietf.org; Mon, 29 Mar 2004 09:21:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xdz-0004IT-Cg for mmusic-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 09:21: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 JAA03853 for ; Mon, 29 Mar 2004 09:21:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7xdx-0001Tz-00 for mmusic-web-archive@ietf.org; Mon, 29 Mar 2004 09:21:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7xdE-0001MO-00 for mmusic-web-archive@ietf.org; Mon, 29 Mar 2004 09:20:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7xcZ-0001Ca-00 for mmusic-web-archive@ietf.org; Mon, 29 Mar 2004 09:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xcR-00042L-58; Mon, 29 Mar 2004 09: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 1B7xcE-00040p-Km for mmusic@optimus.ietf.org; Mon, 29 Mar 2004 09:19: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 JAA03756 for ; Mon, 29 Mar 2004 09:19:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7xcC-0001Bj-00 for mmusic@ietf.org; Mon, 29 Mar 2004 09:19:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7xbH-00012E-00 for mmusic@ietf.org; Mon, 29 Mar 2004 09:18:52 -0500 Received: from smtp4.clb.oleane.net ([213.56.31.20]) by ietf-mx with esmtp (Exim 4.12) id 1B7xaj-0000rk-00 for mmusic@ietf.org; Mon, 29 Mar 2004 09:18:17 -0500 Received: from paviliondeux ([194.206.151.59]) by smtp4.clb.oleane.net with ESMTP id i2TEHQ09001928 for ; Mon, 29 Mar 2004 16:17:46 +0200 Message-Id: <200403291417.i2TEHQ09001928@smtp4.clb.oleane.net> From: "peter lewis" To: Date: Mon, 29 Mar 2004 16:17:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01C415A9.6108CEC0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQVmJ0lgKMVRX4lTVSv6g50oVCi/w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [MMUSIC] TVoDSL 2005: call for proposals Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C415A9.6108CEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit TVoDSL 2005: Broadcasting TV content over ADSL Home network, middleware, access networks, compression tools: all the TVoDSL technical issues will be addressed in detail by the major manufacturing, economic and regulatory players in this promising new market at the TVoDSL Conference, to take place in Paris on January 25 to 28, 2005. The organizers expect more than 600 participants and 40 exhibitors at the Triple Play Showcase. A call for proposals is online at: http://www.upperside.fr/tvodsl2005/tvodsl2005cfp.htm ------=_NextPart_000_0082_01C415A9.6108CEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TVoDSL 2005: Broadcasting TV content over ADSL

Home network, middleware, access networks, compression tools: all the = TVoDSL technical issues will be addressed in detail by the major manufacturing, economic and regulatory = players in this promising new market at the TVoDSL Conference, to take place in = Paris on = January 25 to 28, 2005.

The organizers expect more than 600 = participants and 40 exhibitors at the Triple Play Showcase.

 

A call for proposals is online = at:

 

http://www.upperside.fr/tvodsl2005/tvodsl2005cfp.htm<= /a>

 

------=_NextPart_000_0082_01C415A9.6108CEC0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Mar 29 11:08:05 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 LAA10306 for ; Mon, 29 Mar 2004 11:08:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zIY-0002bY-Ge for mmusic-archive@odin.ietf.org; Mon, 29 Mar 2004 11:07:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TG7cae010004 for mmusic-archive@odin.ietf.org; Mon, 29 Mar 2004 11:07:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zIY-0002b0-53 for mmusic-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 11:07:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10299 for ; Mon, 29 Mar 2004 11:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7zIV-0001Zw-00 for mmusic-web-archive@ietf.org; Mon, 29 Mar 2004 11:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7zHe-0001RP-00 for mmusic-web-archive@ietf.org; Mon, 29 Mar 2004 11:06:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7zH2-0001JN-00 for mmusic-web-archive@ietf.org; Mon, 29 Mar 2004 11:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zH0-0002KR-6R; Mon, 29 Mar 2004 11:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zGV-0002HV-9x for mmusic@optimus.ietf.org; Mon, 29 Mar 2004 11:05: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 LAA10248 for ; Mon, 29 Mar 2004 11:05:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7zGS-0001Gj-00 for mmusic@ietf.org; Mon, 29 Mar 2004 11:05:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7zFY-00016N-00 for mmusic@ietf.org; Mon, 29 Mar 2004 11:04:33 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B7zEc-0000wR-00 for mmusic@ietf.org; Mon, 29 Mar 2004 11:03:37 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2TG3XqY025220 for ; Mon, 29 Mar 2004 18:03:33 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Mar 2004 18:03:32 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Mar 2004 18:03:32 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "Magnus Westerlund (KI/EAB)" , "mmusic (E-mail)" Cc: Jae-Hwan Kim Subject: RE: [MMUSIC] Offer/Answer model does not work for H.264 parameter s Date: Mon, 29 Mar 2004 16:49:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Mar 2004 16:03:32.0252 (UTC) FILETIME=[621595C0:01C415A7] 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,OFFERS_ETC autolearn=no version=2.60 Hi Magnus, I agree with your problems related to options 1 and 3. I need to look into option 2 more in detail later, but just a couple of issues to keep in mind. First, when you assume that at least one PT in the answer must much the offer, please remember that you may include PTs for other, non-H264 codecs, in the same offer. You may still, of course, receive an H.264 PT, but is it possible that you receive one that doesn't "match" any in the offer? Second, when thinking about multiple m= lines the rule that you can't use the same port comes up (even if you don't expect to receive anything on the port indicated in a sendonly stream), which may cause problems. I don't know if these issues are valid for this problem (like I said, I will need to look into it more in detail), but just something to remember :) Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Magnus Westerlund (KI/EAB) > Sent: 26. maaliskuuta 2004 14:56 > To: mmusic (E-mail) > Cc: Jae-Hwan Kim > Subject: Re: [MMUSIC] Offer/Answer model does not work for H.264 > parameters > > > Hi, > > I thought about the issue and there is a reason why one could need to > have multiple media lines: to be able to declare asymmetric > sending and > receiving capabilities. This is best illustrated by the following > example. It also clarifies a bit about what restrictions will > need to be > applied to make the negotiation mechanism work. > > Example: > Below the offerer gives two sets of configurations. The > parameter-sets > are based on the offered profile and level. Notice that I am not very > strict with parameter names or if levels exist. it is simply > an example. > > Offer: > PT: parameters > m= 97 98 > 97: profile-level:extended, level=3; interleaved-mode; > parameter-sets=O-1 > 98: profile-level:baseline,level=1; single-nalu-mode; > parameter-sets=O-2 > > Parameter set O-2 would be used by the offerer to send a stream in > accordance with the declared PT 98 from the offerer to the answerer. > > If the answerer would return something like this: > PT: parameters > m= 100 101 > 101: profile-level:extended, level=5; interleaved-mode; > parameter-set=A-1 > 100: profile-level:baseline,level=1; single-nalu-mode; > parameter-set=A-2 > > Then we have a problem: > How to know if A-1, is a sender declaration belonging to > payload type 97 > or 98. This could be resolved in two ways: > > 1. Restrict payload type numbers to be the same, and use > these to match. > > 2. Restrict the payload type declaration to be exactly the > same, so one > can use the parameters string to match that it belongs to the > corresponding declaration. > > 3. Encode the senders parameter with what payload type is belongs to. > > There is a warning in RFC 3264 that due to H.323 there is > certain cases > where the PTs must change. This would make 1 in that case impossible. > > 2. will probably work better, as it would allow the answerer to add > additional payload types for further capabilities. Please note that > there is a requirement in O/A that at least one PT in a > answer is from > the offer. This solution will require more difficult comparisons. > > 3. This will make it impossible to have only a single round > of offer and > answer, as the initial offerer would need to update his offer > to match > the PTs that the answerer declares. Therefore I don't see > this a viable > solution. > > If one applies alternative 2 above an answer would need to > look like this. > > The answerer would return something like this: > PT: parameters > m= 101 102 100 > 101: profile-level:extended, level=5; interleaved-mode; > parameter-set=A-1 > 100: profile-level:baseline,level=1; single-nalu-mode; > parameter-set=A-2 > 102: profile-level:extended, level=3; interleaved-mode; > parameter-set=A-3 > > The problem with this is that the offerer would need to > update its offer > and include a configuration in accordance with the Answers PT > 101 in its > offer. Thus requiring it to do another round of O/A. > > It also has the problem with that the Offer can't declare its sending > parameters without also accepting to receive them, unless there is a > send only stream. For send and receive streams it will not be > possible > to have non-symmetric receiving capabilities between the end-points. > > The solution as I see to this problem would require the offerer and > answer to use at least two media streams. Otherwise an offerer would > need to declare the video stream as two separate media sessions, one > with sendonly, another with recvonly. > > Feedback is greatly appreciated. > > > 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 > 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 Mar 30 10:47: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 KAA26222 for ; Tue, 30 Mar 2004 10:47: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 1B8LSa-0003aP-56 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 10:47:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UFlSr1013784 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 10:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LSZ-0003aF-8q for mmusic-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 10:47: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 KAA26202 for ; Tue, 30 Mar 2004 10:47:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LSW-0006SF-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 10:47:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8LRh-0006KU-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 10:46:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8LRC-0006Bj-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 10:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LRA-0003Rc-9O; Tue, 30 Mar 2004 10:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LQd-0003Qg-Jz for mmusic@optimus.ietf.org; Tue, 30 Mar 2004 10:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26088 for ; Tue, 30 Mar 2004 10:45:23 -0500 (EST) From: pkdutta@vsnl.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LQb-00069u-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:45:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8LPf-00060P-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:44:28 -0500 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 1B8LOk-0005hd-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:43:30 -0500 Received: from vsnl.net ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HVE0087OBHTJF@smtp2.vsnl.net> for mmusic@ietf.org; Tue, 30 Mar 2004 21:09:35 +0530 (IST) Received: from ([172.16.28.141]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Tue, 30 Mar 2004 21:09:34 +0530 (IST) Received: from [172.16.28.183] by pop2.vsnl.net (mshttpd); Tue, 30 Mar 2004 20:39:29 +0500 Date: Tue, 30 Mar 2004 20:39:29 +0500 To: mmusic@ietf.org Message-id: <4de16b4db8a0.4db8a04de16b@vsnl.net> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7BIT Subject: [MMUSIC] Delay in RTSP responses from Server 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, I have developed a RTSP Client to interact with a VoD Server and it is streaming MPEG-2 Videos quite well. Sometimes I am observing delays in getting response for PLAY,PUASE,TEARDOWN messages from the Server. Assuming that the Server is responding intact under heavy loaded condition the source of the problem goes to the Network congestion. Under heavy video traffic when the network is overloaded there are chances that small RTSP Messages are getting lost(and so TCP retransmission at the Server will try sending again and again) and so there is a delay in getting response. Is there any already existing mechanism to implement End to end QoS mechanism for giving priority to RTSP Messages. Is there any already established method to overcome such problems. I feel RTSP Control messages are very important from a viewers perspective.Just thinking about a viewer who is not able to STOP the video for minutes!!! I will be very obliged with the valuable suggestions/comments. Thanks, Pranjal _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 17:35:38 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 RAA18480 for ; Tue, 30 Mar 2004 17:35:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006YH-Ua for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HHTJQq004733 for mmusic-archive@odin.ietf.org; Wed, 17 Mar 2004 12:29:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3er0-0001Dm-Jg for mmusic-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 12:29: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 MAA23912 for ; Wed, 17 Mar 2004 12:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3eqj-0001Tc-00 for mmusic-web-archive@ietf.org; Wed, 17 Mar 2004 12:29:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3epF-00016y-00 for mmusic-web-archive@ietf.org; Wed, 17 Mar 2004 12:27:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ens-0000q8-00 for mmusic-web-archive@ietf.org; Wed, 17 Mar 2004 12:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3enq-0000la-As; Wed, 17 Mar 2004 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3enR-0000ik-HU for mmusic@optimus.ietf.org; Wed, 17 Mar 2004 12:25:37 -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 MAA23505 for ; Wed, 17 Mar 2004 12:25:33 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3enQ-0000la-00 for mmusic@ietf.org; Wed, 17 Mar 2004 12:25:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3emU-0000bp-00 for mmusic@ietf.org; Wed, 17 Mar 2004 12:24:39 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B3elf-0000Sb-00 for mmusic@ietf.org; Wed, 17 Mar 2004 12:23:47 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2HHNIp17009; Wed, 17 Mar 2004 19:23:19 +0200 (EET) X-Scanned: Wed, 17 Mar 2004 19:21:51 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2HHLpYw002172; Wed, 17 Mar 2004 19:21:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00k0Jdx2; Wed, 17 Mar 2004 19:21:49 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2HHKss02723; Wed, 17 Mar 2004 19:20:54 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Mar 2004 19:20:53 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Mar 2004 19:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt Date: Wed, 17 Mar 2004 19:20:53 +0200 Message-ID: Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt Thread-Index: AcQFsFW0LWOXe/bMTVK+nNb2KbdTegAAMEPw To: , Cc: , , , , , X-OriginalArrivalTime: 17 Mar 2004 17:20:53.0559 (UTC) FILETIME=[338FD470:01C40C44] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus Thanks for the review comments. Responses below... (BTW, sorry if I missed some other responses - I'm on vacation and = suffering badly intermittent connectivity) ----- > 1. Section 2: The capitalized words MUST SHOULD, etc. used in this=20 > specification may not always be appropriate. This is due to that the=20 > definitions are more intended for technical specifications=20 > and putting=20 > requirements on implementations. It might be consider better if the=20 > document defines the words. Yes, this is a valid point. This is in the same vein as the Seoul = plenary discussion on the applicability of RFC2119 ("should, shall, = must..."). The RFC is intended for protocol implementation = specifications, but since we don't have an RFC to give the power words = for requirements we're aiming to use RFC2119 "in the spirit" of = requirements. In this sense we didn't see any fundamental problem with = capitalisations to emphasise the requirement in question. Anyhow, I'll = have another look through to see if I spot any obvious inappropriate = capitalization - if you saw some specific offending instances (or all = instances :) please direct us to the paragraphs. ----- The text in question is (for everyone else's benefit): REQ DEL-1: The system MUST be scalable to large numbers of messages, so that it does not fail to deliver up-to-date information under huge numbers of transactions and massive quantities of IMG metadata. > 2. Section 5.2.1: Req DEL-1: I see some problems with writing=20 > a MUST in=20 > this context. I agree that scalability is desirable and is a clear=20 > design goal of any solution. The problem lays in the measuring of=20 > scalability. Absolute measurements of scalability is hard to=20 > establish.=20 > Also in certain environments one might not be able to create good=20 > scalability due to other factors in the system, for example extremely=20 > limited bandwidth. Thus I would suggest that this is=20 > reformulated into=20 > something that is more a statement of intention. I think this is a matter of wording - the meaning was correct but not = expressed clearly enough. It was important for us to state a hard = requirement, but clearly the "IMG solutions" may be useful outside the = massively scalable context. How about this re-write... REQ DEL-1: The IMG system MUST be scalable to large numbers of=20 messages, so as to allow design and use of delivery mechanisms=20 that will not fail in delivering up-to-date information under=20 huge numbers of transactions and massive quantities of IMG=20 metadata. ...which gives the requirement but makes it's applicability clearer: the = IMG system design must be scalable even if it's deployment (and used = delivery protocols) are not scalable (e.g. if massive scalability is not = feasible in a certain scenario). On the other hand, it ensures that the = design and use of scalable delivery protocols is not hindered. ----- The text in question is: By contrast, intermittent connectivity make immediate distribution of changes infeasible and so managing data consistency should be focused on the timely delivery of data. > 3. Section 5.4.1: Last paragraph: I think that the intermittent=20 > connectivity actually should be formulated into a requirement: >=20 > REQ: "The IMG system SHOULD allow for low cost=20 > uptodate/consistency checks." Good suggestion. For the mobile/cellular type cases "allowing = intermittent connectivity" is somehow bound to "enabling low cost = consistency messaging". For other cases intermittent connectivity is not = related to cost of communications (e.g. limited HW-accelerated header = filtering resources, or power-reduction by sending a connection idle, in = broadcast receivers; or shutting down background Internet activity when = a user is not active - for security). So how about this rewrite of the = last paragraph... REQ REL-3: The IMG system SHOULD allow for hosts with intermittent=20 connectivity. The implication of intermittent connectivity is that immediate=20 distribution of changes becomes infeasible and so managing data=20 consistency should be focused on the timely delivery of data. This would also require "REL-3" -> "REL-4" number re-alignment. ----- > 4. Section 5.5, Req DES-4: "IMG metadata MUST be structured=20 > such that it=20 > is possible to deliver only part of an IMG sender's (and the global)=20 > complete IMG metadata knowledge." >=20 > I think this is SHOULD rather than a MUST. The reason is for example=20 > that some may want to use already established metadata=20 > formats that does=20 > not fulfil the requirements. Should they not be allowed to=20 > use IMG due=20 > to that facT? The intention is that the whole body IMG metadata is structured such. = So, although we aren't proposing redesign of SDP, we are proposing that = different SDP descriptions (e.g. delivered as files) are part of a = larger structured body of IMG metadata (and the same applies to "foo" = metadata syntax). IOW, the requirement states less about the internal = structuring of metadata and more about the ability of it to be mapped = onto efficient delivery. This wording should mean the same thing but read clearer. Sound good? REQ DES-4: IMG metadata MUST be structured to enable fragmentation=20 for efficient delivery. This it is intended to ensure that and IMG sender with more than a=20 trivial knowledge of metadata is able to deliver only part of its=20 (and the global) complete IMG metadata knowledge. (For instance, a=20 trivial quantity of knowledge could be a single SDP description).=20 In general, the resolution of this fragmentation will be very much=20 dependent on the optimal delivery of a deployment, although some=20 metadata syntaxes will inherently effect the sensible lower limit=20 for a single element/fragment. ----- > 5. The security requirements: Have you had any review of these, and=20 > there possibility to be fulfilled? I think it would be stupid=20 > to require=20 > security that is not possible to fulfil, how much it still is=20 > desirable.=20 True. Please pinpoint any requirements which are infeasible. Although we = have been through these security requirements many time, a fresh set of = eyes could easily spot things aren't clear enough. (And bear in mind - = like the massive scalability requirement - these are requirements = intended for the design of the IMG system and not a firewall to other = uses of IMGs) > And if a piece of security is required lacks solution, should we then=20 > shelf IMG? The aim is to publish these requirements as Informational RFC. So = ultimately these requirements provide security considerations (since = standards track normative requirements referenced from subsequent = protocol specifications would be an untested idea in the IETF - I guess = someone can prove me wrong :). As far as I am aware, an Informational RFC is in no position to shelve a = protocol, no matter a framework. However, they will provide a strong = metric in evaluating protocol proposals, so those which offer security = solutions which are appropriate for there use would be the strongest = candidates. So the short answer would have been "no". ----- > 6. IPR and Copyright statement. Needs to be updated using RFC=20 > 3667 and=20 > 3668. Also please provide a heading for the IPR section. A very reasonable suggestion. ----- > 7. Also as this document is intended for informative, you can't have=20 > normative references. Good point, we should revert back to the 02 style (all references as = "References" - none normative). ----- Basically, all the changes I'm proposing are clarifications (including = the 5.4.1 "commentary" -> "requirement + commentary") or NITs. So = Magnus, would you agree with me that these changes would be enough = without a new last call? Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 18:21:05 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 SAA28932 for ; Tue, 30 Mar 2004 18:21:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006a4-I9 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFdiG4003788 for mmusic-archive@odin.ietf.org; Sat, 20 Sep 2003 11:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jpm-0000xl-Gm for mmusic-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:39:42 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13639 for ; Sat, 20 Sep 2003 11:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jpH-0000hB-Sy; Sat, 20 Sep 2003 11:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ibq-0006f7-Sp for mmusic@optimus.ietf.org; Sat, 20 Sep 2003 10:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06533 for ; Fri, 19 Sep 2003 23:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0YUg-0006O1-00 for mmusic@ietf.org; Fri, 19 Sep 2003 23:33:11 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1A0YUW-0006NL-00 for mmusic@ietf.org; Fri, 19 Sep 2003 23:33:00 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 19 Sep 2003 20:32:30 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.218] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Fri, 19 Sep 2003 20:32:30 -0700 (PDT) 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; Fri, 19 Sep 2003 20:27:07 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1A0YPV-00034X-00 for ; Fri, 19 Sep 2003 20:27:49 -0700 Date: Fri, 19 Sep 2003 20:26:40 -0700 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 Message-Id: X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_20,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #92 - 1 msg 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: , 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-804219 ] How to handle sync in re-SETUP (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 19 Sep 2003 03:23:39 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-804219 ] How to handle sync in re-SETUP Bugs item #804219, was opened at 2003-09-11 09:20 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=804219&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: How to handle sync in re-SETUP Initial Comment: When using SETUP to change transport parameters, there seem to be two ways of handling media sync after parameter change. A. Put a requirement on the servers to maintain the timestamp <-> play time from before the change. B. Put in a Range and RTP-Info headers to carry sync information in the SETUP response. B. will require the client to here implement the same mechanism as for PLAY when maintaining buffer information from before a pause. Are there any need for B, like use cases etc? Comments on the two approach are desired. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-09-19 12:23 Message: Logged In: YES user_id=302620 After email discussion it seems evident that there are desirable to include Range and RTP-Info where applicable to give information on when the new transport parameters are used. Text proposal for this has been checked in an needs review by the WG members. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=804219&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 Tue Mar 30 18:25:07 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 SAA29933 for ; Tue, 30 Mar 2004 18:25:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-D8 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K76itX020370 for mmusic-archive@odin.ietf.org; Fri, 20 Feb 2004 02:06:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4kE-0005Dy-6z for mmusic-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 02:06: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 CAA29547 for ; Fri, 20 Feb 2004 02:06:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4jv-0003G2-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 02:06:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4iL-0002xE-00 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 02:04:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Au4gW-0002ig-02 for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 02:02:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Au4UC-0000qJ-MD for mmusic-web-archive@ietf.org; Fri, 20 Feb 2004 01:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4U7-0001nz-PF; Fri, 20 Feb 2004 01:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4Tl-0001hT-Ni for mmusic@optimus.ietf.org; Fri, 20 Feb 2004 01:49: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 BAA21937 for ; Fri, 20 Feb 2004 01:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4Ti-0001wo-00 for mmusic@ietf.org; Fri, 20 Feb 2004 01:49:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4S7-0001cW-00 for mmusic@ietf.org; Fri, 20 Feb 2004 01:48:09 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1Au4PI-0000vf-00 for mmusic@ietf.org; Fri, 20 Feb 2004 01:45:04 -0500 Date: Thu, 19 Feb 2004 22:19:41 -0800 From: rtspspec-bugs-request@lists.sourceforge.net To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_goobox-20752-1077259490-0001-2" Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #119 - 8 msgs 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=2.7 required=5.0 tests=AWL,DEAR_FRIEND, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,MAILTO_TO_SPAM_ADDR, NIGERIAN_BODY1,NO_REAL_NAME,US_DOLLARS_3 autolearn=no version=2.60 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_goobox-20752-1077259490-0001-2 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Comment: The following content can be customized provided that: Comment: 1) These MIME headers are preserved (you may change the charset Comment: or drop format=flowed). Comment: 2) This content is manually quoted-printable encoded, it MUST NOT Comment: contain 8-bit text. Comment: 'goobox' below is replaced by server name. Content-Transfer-Encoding: quoted-printable CORRUPTED MESSAGE This is the Courier Mail Server 0.36.1 on goobox. I received the following message for delivery to your address. Unfortunately, this message apparently fails to comply with Internet mail formatting protocols, and I can only deliver mail which has been properly formatted in accordance with Internet standards. Instead of rejecting that message as undeliverable, I saved it as the following attachment, which you can open with any editor or word processor. Please notify the original sender that their message was not properly formatted by their mail software. The specific mail protocol error is as follows: ----------------------------------------------------------------------------- The following message contains 8-bit content, but does not have the required MIME headers for 8-bit data transport. See for more information. ----------------------------------------------------------------------------- --=_goobox-20752-1077259490-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="message.txt" X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.36.1 Content-Transfer-Encoding: quoted-printable Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 19 Feb 2004 22:44:48 -0800 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TL= S: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Th= u, 19 Feb 2004 22:43:28 -0800 Received: from localhost ([127.0.0.1] helo=3Dprojects.sourceforge.net) b= y sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1Au4TX-0007ww-D= u for robla@real.com; Thu, 19 Feb 2004 22:49:27 -0800 Date: Thu, 19 Feb 2004 22:19:41 -0800 From: rtspspec-bugs-request@lists.sourceforge.net Subject: Rtspspec-bugs digest, Vol 1 #119 - 8 msgs X-Mailer: Mailman v2.0.9-sf.net MIME-version: 1.0 Content-type: text/plain Old-To: rtspspec-bugs@lists.sourceforge.net Sender: rtspspec-bugs-admin@lists.sourceforge.net Errors-To: rtspspec-bugs-admin@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on capefear.real.= com X-Spam-Status: No, hits=3D-2.4 required=3D5.0 tests=3DAWL,BAYES_00,DEAR_= FRIEND, HTML_FONTCOLOR_RED,HTML_MESSAGE,NIGERIAN_BODY1,NO_REAL_NAME, US_= DOLLARS_3 autolearn=3Dno version=3D2.63 X-Spam-Level: To: mmusic@ietf.org Reply-to: mmusic@ietf.org Message-ID: This is an automatic digest of bugs submitted and changed on the RTSP bu= g tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rts= pspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-556061 ] When can REDIRECT be received? (SourceFor= ge.net) 2. [ rtspspec-Bugs-506412 ] RTSP Teardown functionallity (SourceForge= .net) 3. [ rtspspec-Feature Requests-513787 ] Allow capability negotiations= (SourceForge.net) 4. [ rtspspec-Feature Requests-507332 ] RTSPS/TLS support (SourceForg= e.net) 5. [ rtspspec-Bugs-538997 ] Need to flesh out 1.5 (Extending RTSP) (S= ourceForge.net) 6. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP = IP (SourceForge.net) 7. Can You Be Trust? (FAMILY IN NEED) 8. =3D?GB2312?B?uuPL2bTv0OnE4tb3u/q827jxtffV+82o1qqjoQ=3D=3D?=3D (=3D= ?GB2312?B?uuPL2bTv?=3D) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 07:39:44 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-556061 ] When can REDIRECT be r= eceived? 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=3Ddetail&atid=3D377744&aid=3D55606= 1&group_id=3D23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) >Assigned to: Magnus Westerlund (magwes) 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-13 16:39 Message: Logged In: YES user_id=3D302620 With the latest text in the REDIRECT section this is now very clear. Awaiting final review before closing. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-03 14:46 Message: Logged In: YES user_id=3D302620 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=3D302620 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=3Ddetail&atid=3D377744&aid=3D55606= 1&group_id=3D23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 07:35:22 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-506412 ] RTSP Teardown function= allity Bugs item #506412, was opened at 2002-01-21 13:41 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377744&aid=3D50641= 2&group_id=3D23194 Category: None Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: RTSP Teardown functionallity Initial Comment: The usage of TEARDOWN is not clear when doing it on media url in a aggregated session. Example: You have a session with one audio and one video media. These medias have a presentation URL in its description. The specification is clear on that if we do teardown on presentation URL the whole session and all medias will be closed. But what happends if you do teardown on the audio url? My interpretation is that only audio is removed from session. The video and session is still available. When you do teardown on the last media in a session then you remove the session. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-13 16:35 Message: Logged In: YES user_id=3D302620 I think the text on this is rather clear. Please review and look over it. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 15:51 Message: Logged In: YES user_id=3D302620 This has been clarified in the state machine and the description for the TEARDOWN method. Two optional parts has been defined, support of the ready-no_media state and SETUP and TEARDOWN while playing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377744&aid=3D50641= 2&group_id=3D23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 07:36:42 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-513787 ] Allow capa= bility negotiations Feature Requests item #513787, was opened at 2002-02-06 16:32 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377747&aid=3D51378= 7&group_id=3D23194 >Category: None >Group: None Status: Open 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 ide= a 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. T= his description contains multiple alternatives or in the case SDP-NG a complete description of th= e 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-N= G. 5. S->C: Server either accepts or refuses the setup with the given confi= guration. 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=3D302620 This is in fact a feature request. Changing category for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377747&aid=3D51378= 7&group_id=3D23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 07:36:12 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-507332 ] RTSPS/TLS = support Feature Requests item #507332, was opened at 2002-01-23 04:15 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377747&aid=3D50733= 2&group_id=3D23194 Category: None >Group: None Status: Open Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: RTSPS/TLS support Initial Comment: Currently, the version of RTSP that's checked into the repository has TLS support and rtsps:. This is probably just a relic of the fact that we pulled this at the very last minute when going to Proposed Standard, and it never got checked in. It's an interesting feature, but one that probably warrents a separate draft on it's own track. robla: I vote for taking this out. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 14:00 Message: Logged In: YES user_id=3D302620 The current decision from telecon in december 2002 is that we should have it as a seperate extension document. Anyone interested may start writing on such a document. Any more than informative text shall be removed from base spec. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 14:00 Message: Logged In: YES user_id=3D302620 The current decision from telecon in december 2002 is that we should have it as a seperate extension document. Anyone interested may start writing on such a document. Any more than informative text shall be removed from base spec. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:37 Message: Logged In: YES user_id=3D302620 If it is going to be left in the spec it needs further work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377747&aid=3D50733= 2&group_id=3D23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Feb 2004 07:37:56 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-538997 ] Need to flesh out 1.5 = (Extending RTSP) Bugs item #538997, was opened at 2002-04-04 01:26 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377744&aid=3D53899= 7&group_id=3D23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) >Assigned to: Magnus Westerlund (magwes) Summary: Need to flesh out 1.5 (Extending RTSP) Initial Comment: We need to have a larger "Extending RTSP" section in the draft: A first (very rough) cut at this was posted here: http://www.ietf.org/mail-archive/working-groups/mmusic/current/msg00377.= html ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2004-02-13 16:37 Message: Logged In: YES user_id=3D302620 The IANA section is in rather good shape. We need to review if the text in the descriptiv chapter is good enough. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:08 Message: Logged In: YES user_id=3D302620 One part of this is the IANA extensions that has been written up, see bug 513753. However more rules might be needed, for example regarding proxies. Also informational chapters on what to think when doing extension would be good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D377744&aid=3D53899= 7&group_id=3D23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Feb 2004 02:17:42 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indica= tor 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=3Ddetail&atid=3D377744&aid=3D85317= 5&group_id=3D23194 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-16 11:17 Message: Logged In: YES user_id=3D302620 To be clearer this problem is solved through the fact that the "host:port" tuple allows for the host part to be empty. Thus cases where only the port number is needed can be specified as :port A not explicit allowing this has been added to the text. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2004-02-13 17:03 Message: Logged In: YES user_id=3D302620 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=3Ddetail&atid=3D377744&aid=3D85317= 5&group_id=3D23194 --__--__-- Message: 7 From: FAMILY IN NEED To: rtspspec-bugs@lists.sourceforge.net Reply-To: ssssskkkkk111@netscape.net Date: Wed, 18 Feb 2004 03:46:50 +0000 Subject: [rtspspec-bugs] Can You Be Trust? This is a multi-part message in MIME format --f8c3a339-5025-4d2a-9af0-721661a0b72d Content-Type: text/plain; charset=3Diso-8859-1 Content-Transfer-Encoding: quoted-printable Dear friend, I got your contact from an email directory and decided to contact you for assistance. I am the son of Jonas Savimbi the rebel leader in Angola= who =3D was short dead on the 25th of February, 2002, by the opposing Angolan Army. .... PLEASE TAKE A LOOK AT THIS WEB PAGE FOR IT SAYS ALL. http://news.bbc.co.uk/hi/english/world/africa/newsid_1839000/1839252.stm Before the death of my father he had transferred the sum of $16,000,000.00 (Sixteen million dollars) through a security company in S= outh =3D Africa to Europe. All the legal documents for the deposit and transfer of this fund to Europe are with my mother which my father gave to her for safe keeping. After the death of my father I and my family fled to South Africa where we are currently living.And we have been trying to fly to Europe b= ut it has been difficult for us to get visas from Africa. So we want you to he= lp us make claims of this fund ($16m) in Europe as my family beneficiary and transf= er the money to your account or any account of your choice before I and my family can ge= t visas to fly down to your country so that we can share this money. My family have agreed to give you 10%, which would be ($1.6Million dollars) of this Money for your assistance, and 87% would be for us and = the other 3% would be set aside for any expenses that we may incure during t= he course of this transaction. And part of our share of 87% would be invested in y= our country in any profitable business proposed by you. While a large part of our sh= are will also be used to help charity organizations. We have never met, but I want to trust you and please do not let us down when this fund finally gets into your account. Please if you are interested; get to me through my email address to enable me feed you wit= h more details and all necessary documentations. Please treat this as confidential Best regards. --f8c3a339-5025-4d2a-9af0-721661a0b72d-- --__--__-- Message: 8 From: =3D?GB2312?B?uuPL2bTv?=3D To: rtspspec-bugs@lists.sourceforge.net Reply-To: webnetcn@tom.com Date: Fri, 20 Feb 2004 12:58:58 +0800 Subject: [rtspspec-bugs] =3D?GB2312?B?uuPL2bTv0OnE4tb3u/q827jxtffV+82o1q= qjoQ=3D=3D?=3D =BA=E3=CB=D9=B4=EF=D0=E9=C4=E2=D6=F7=BB=FA=BC=DB=B8=F1=B5=F7=D5=FB= =CD=A8=D6=AA=A3=A1
=D7=F0=BE=B4=B5=C4=C0=CF=BF=CD= =BB=A7=A3=BA
=A1=A1=A1=A1=C4=FA=BA=C3=A3=A1
=A1=A1=A1=A12004=C4=EA=CE=D2=CB=BE=D3=EBDE= LL=B9=AB=CB=BE=BA=CF=D7=F7=CD=C6=B3=F6=C6=B7=C5=C6DELL=B7=FE=CE=F1=C6=F7= =BF=D5=BC=E4=A3=AC=B4=D9=CF=FA=D3=C5=BB=DD=C8=E7=CF=C2=A3=BA

A=A1=A2400M=BF=D5=BC=E4=A3=A8200M WEB,=D6=A7=B3=D6ASP\CGI\ACCESS\=C2=DB=CC=B3=A3=A9+ 1=B8=F6100M MAIL=CC=D8=BC=DB200=D4=AA=A3=BB
B=A1=A2600M=BF=D5=BC=E4=A3=A8300M= WEB,=D6=A7=B3=D6ASP\CGI\ACCESS\=C2=DB=CC=B3=A3=A9+ 1=B8=F6100M MAIL=CC=D8=BC=DB250=D4=AA=A3=BB
C=A1=A2800M=BF=D5=BC=E4=A3=A8400M= WEB,=D6=A7=B3=D6ASP\CGI\ACCESS\=C2=DB=CC=B3=A3=A9+ 1=B8=F6100M MAIL=CC=D8=BC=DB350=D4=AA=A3=BB
=CC=D8=BC=DB=BF=D5=BC=E4=BC=D3=A1=A160=D4=AA=CB=CD=B9=FA=BC=CA=B6= =A5=BC=B6=D3=F2=C3=FB=A3=AC=BC=D3=A1=A1180=D4=AA=CB=CD=B9=FA=C4=DA=D3=F2= =C3=FB=A3=BB=A3=BE=A3=BE=C1=A2=BC=B4=C9= =EA=C7=EB=A3=BE

=C1=ED=CD=F8=D5=BE=BD=A8=C9=E8=C8=AB=C3=E6=D3=C5=BB=DD800=D4=AA=C6=F0=D7=F6<= /font>=A3=AC=C6=F3=D2=B5=CD=F8=D5=BE=BF=C9=C3=E2=B7=D1=CF=C8=D7=F6=A3=AC= =D7=F6=BA=C3=D4=D9=CA=D5=B7=D1.=B5=E3=BB=F7=C1=CB=BD=E2
=A1=A1=A1=A1=CD=AC=CA=B1=D2=B2=BB=B6=D3=AD=C4=FA=BC=D3=C8=EB=CE=D2= =C3=C7=B4=FA=C0=ED=C9=CC=D0=D0=C1=D0=C0=B4=A3=AC=CE=D2=C3=C7=BD=AB=B8=F8= =C4=FA=B8=FC=BC=D3=D3=C5=BB=DD=B5=C4=B7=FE=CE=F1=A3=A1=B3=CF=D0=C5=CE=AA= =B1=BE=A3=AC
=CE=D2=C3=C7=B3=D0=C5=B5= 24=D0=A1=CA=B1=CE=AA=C4=FA=B7=FE=CE=F1=A3=A1
24=D0=A1=CA=B1=C8=C8=CF=DF= =A3=BA0592-- 6026652 / 5682852 / 5682825 =A1=A1
=B4=AB=D5=E6=A3=BA0592--5654223
=D3=CA=CF=E4=A3=BA dns88@tom.com= / chn88@tom.com
QQ=D4=DA=CF=DF=A3=BA 57729502

=D7=A3=C4=FA=BA=C3=D4=CB=CC=EC= =CC=EC=D3=D0=A1=A2=D0=D2=D4=CB=B3=A3=B0=E9=CB=E6=A1=A2=BA=EF=C4=EA=CD=F2= =CA=C2=C8=E7=D2=E2!
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=BA=E3=CB=D9=B4=EF=CD=F8=C2=E7
End of Rtspspec-bugs Digest --=_goobox-20752-1077259490-0001-2-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 18:32:49 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 SAA01831 for ; Tue, 30 Mar 2004 18:32: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 1B8RjH-0006a4-6F for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDsg3c013717 for mmusic-archive@odin.ietf.org; Sat, 20 Sep 2003 09:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0iC9-0003T8-EX for mmusic-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:54:41 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04664 for ; Sat, 20 Sep 2003 09:54:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O9x-0007PP-Ii; Fri, 19 Sep 2003 12:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0No7-0002Kb-El for mmusic@optimus.ietf.org; Fri, 19 Sep 2003 12:08:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08385 for ; Fri, 19 Sep 2003 12:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A04vB-0002Mm-00 for mmusic@ietf.org; Thu, 18 Sep 2003 15:58:33 -0400 Received: from smtp1.vsnl.net ([203.200.235.231]) by ietf-mx with esmtp (Exim 4.12) id 1A04hr-00012p-00 for mmusic@ietf.org; Thu, 18 Sep 2003 15:44:47 -0400 Received: from happy ([127.0.0.1]) by smtp1.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HLF00DLDDHETJ@smtp1.vsnl.net> for mmusic@ietf.org; Fri, 19 Sep 2003 01:14:17 +0530 (IST) Received: from ([219.65.46.226]) by smtp1.vsnl.net (InterScan E-Mail VirusWall Unix); Fri, 19 Sep 2003 01:14:17 +0530 (IST) Date: Fri, 19 Sep 2003 01:05:21 +0530 From: Deepak Kotian Subject: Re: [MMUSIC] About the parameter like SMPTE Relative Timestamps/Normal Play Time/Absolute Time To: Magnus Westerlund Cc: IETF MMUSIC WG Reply-to: Deepak Kotian Message-id: <009001c37e1d$319b0460$ba2e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018e01c37bbf$fbc57e60$972e41db@vsnl.net> <3F66B5E7.9000300@ericsson.com> <000801c37c7a$f94af780$1c2e41db@vsnl.net> <3F681B80.4010402@ericsson.com> <007501c37d48$c52724a0$3a2e41db@vsnl.net> <3F69704F.50705@ericsson.com> 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: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, Thanks for inputs. Do you have some kind of use cases for this various timestamp. Basically, I was interested in what can needs to be done in the RTSP server for these timestamp or we need not do anything. We are streaming a RealTime MPEG1 video and audio ES via seperate ports from TV Source/DVD/VHs, we are using hardware encoder to encode this Live data. Can I get some more inputs on this one please. Thanks and Regard Deepak ----- Original Message ----- From: "Magnus Westerlund" To: "Deepak Kotian" Cc: "IETF MMUSIC WG" Sent: Thursday, September 18, 2003 2:13 PM Subject: Re: [MMUSIC] About the parameter like SMPTE Relative Timestamps/Normal Play Time/Absolute Time > Hi, > > What Range format to use depends on what time format things are > interesting to give, but also on the clients capabilities. Not knowing > what your intentions are I can't give any answers. > > NPT is required to be implemented in clients. If no frame exact times > since media start is of interest I would use this format. > > SMPTE is good if one needs to have frame exact access, however how many > clients that support this is a big question. > > Absolute time is good if you are relying things that has interesting > real time clocks. For example a surveillance tape which is stamped with > the time of capture should be using absolute time. > > Best Regards > > Magnus > > > Deepak Kotian wrote: > > > Hi, > > > > Can one please let us know > > What should be the implementation for the parameter like SMPTE Relative > > Timestamps/Normal Play Time/Absolute Time in the our RTSP server. > > > > Our requirement is to implement the minimal RTSP server for a RealTime > > Video data and play it on RealOne player. > > We stream like TV shows or DVDs or Camera, in this case , it is basically > > RealTime video > > > > Can anyone please give any view on this please. > > > > Thanks and Regards > > Deepak > > > > > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 18:38: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 SAA03388 for ; Tue, 30 Mar 2004 18:38: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 1B8RjB-0006Yx-I0 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB19s7aK024926 for mmusic-archive@odin.ietf.org; Mon, 1 Dec 2003 04:54:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQkkp-0006Tx-8l for mmusic-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 04:54: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 EAA03392 for ; Mon, 1 Dec 2003 04:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQkkl-0006Q4-00 for mmusic-web-archive@ietf.org; Mon, 01 Dec 2003 04:54:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQkkl-0006Q1-00 for mmusic-web-archive@ietf.org; Mon, 01 Dec 2003 04:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQkkk-0006TM-QD; Mon, 01 Dec 2003 04:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQkjz-0006Nn-Rp for mmusic@optimus.ietf.org; Mon, 01 Dec 2003 04:53: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 EAA03377 for ; Mon, 1 Dec 2003 04:53:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQkjw-0006Pf-00 for mmusic@ietf.org; Mon, 01 Dec 2003 04:53:12 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AQkjv-0006Pc-00 for mmusic@ietf.org; Mon, 01 Dec 2003 04:53:12 -0500 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hB19qrbE001397; Mon, 1 Dec 2003 10:52:54 +0100 (MET) Message-ID: <3FCB1031.9080301@tzi.uni-bremen.de> Date: Mon, 01 Dec 2003 10:56:01 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org, csp@csperkins.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by imh.informatik.uni-bremen.de id hB19qrbE001397 Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Draft MMUSIC Minutes 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, attached are the draft minutes from the MMUSIC WG meeting at the 58th IETF in MPLS. Please review and post comments to the list. The corresponding slides can be retrieved from http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-ppt.zip http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-pdf.zip http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-ps.zip Thanks, Joerg 58th IETF: MMUSIC Minutes ------------------------- Reported by Tom Taylor and Colin Perkins. MMUSIC met on Friday morning, November 14. The meeting was chaired by J=F6rg Ott and Colin Perkins . The agenda was accepted with two minor changes: a discussion of Source and Sink SDP attributes was added, and the discussion of SDP parameters for H.263 and H.261 options took place in AVT instead. Introduction and Status Update ------------------------------ J=F6rg Ott gave an introduction and status update. The working group has had one RFC published since the last meeting: the RTCP attribute for SDP (RFC 3605 ), and draft-ietf-mmusic-sdpng-trans-04.txt is with the RFC Editor. The IESG has reviewed draft-rajeshkumar-mmusic-gpmd-03.txt and suggested some changes. The authors are considering these, and will produce an update. Colin Perkins has updated the revision to SDP (draft-ietf-mmusic-SDP-new-15.txt) to reflect IESG comments, implementing the changes suggested at the 57th IETF meeting. The working group was urged to review the draft to make sure the latest changes haven't broken anything. Some discussion took place: * There was a question on the time scale for SDP-new approval. The chairs expect an immediate WG review, then off to the IESG. Volunteers were requested for an in-depth review. They were asked to send an E-mail to Joerg to indicate that they were volunteering. * Jon Peterson indicated that he was still worried about the "k=3D" line text. The problem is that the existing text has a normative dependency on informative text: "SHOULD NOT use in absence of ". * There is a problem with the text media type: it's widely used, and referenced in RFC 2327 , but got missed from the original IANA registry for SDP top-level types. We could do it indirectly by putting it into SDP-new. Interested parties are asked to send text to be added to sdp-new for the purpose. Future SDP extensions are strongly discouraged by the WG charter. * Semantics are undefined for multiple "m=3D" lines with the same port and "c=3D" The interpretation should go into the SDP-new draft as a clarification. There are minor implications on the offer-answer examples. Gonzalo Camarillo sent some text, but for a different case (hierarchical encoding). Flemming Andreasen proposed that we simply prohibit this construct. The meeting agreed to the prohibition. The source filter (draft-ietf-mmusic-sdp-srcfilter-05.txt) and comedia (draft-ietf-mmusic-sdp-comedia-05.txt) drafts have been reviewed by the area director, and need to be updated. The new SDP bandwidth parameters (draft-ietf-mmusic-sdp-bwparam-05.txt) are with the area director, and an IETF last call is expected shortly. Internet Media Guides --------------------- Requirements: Yuji Nomura discussed requirements for Internet Media Guides (draft-ietf-mmusic-img-req-00.txt). There are lots of changes in the latest revision of the requirements draft. A new background and motivations section has been added. The editor moved in the problem statement from the old framework draft, but shortened it. Congestion control has been added as a requirement. Security considerations were added. For the next revision: * requirements will be numbered * terminology will be modified for consistency * clarifications have been requested: many more receivers than senders; senders continually connected, not receivers; and the tradeoff between customization and scalability The revised draft is coming out in the next few weeks. The authors expect it to be ready for Last Call shortly after that. Framework: Pekka Luoma discussed the IMG framework (draft-nomura-mmusic-img-framework-02.txt). This is an individual submission, since it missed the cutoff; a working group draft will be submitted shortly after the meeting. Changes from the last version are as follows: * The use cases in the latest version of the draft were extended to include content-oriented use cases. * A section has been added to discuss the applicability of existing protocols. * New section 6.3 summarizes the outstanding needs that existing protocols do not seem to supply: o need for a multicast transport protocol o need to specify how to use specific unicast transport protocols in this application o specification of the "metadata envelope", a new term for an existing concept in the framework that gives independence from transport protocol and metadata format o agreement on the basic metadata models (informative only) Next steps are an editorial cleanup and a new section outlining what pieces of the work are in IETF scope (the transport protocols and transfer envelope) and out of scope (the data models and application specific metadata). It was suggested that an IMG metadata identifier is needed, likely a URI to differentiate between complete specification, delta, and filter. J=F6rg suggested avoiding the term "metadata" altogether, since it causes confusion. Magnus Westerlund remarked that this was not exactly a framework document. Colin suggested an offline discussion on this point. Magnus will comment by E-mail. Rod Walsh indicated that whether changes use the same syntax as the original announcements is still an open question. It is not clear how reusable the syntax may be. Target is to have WG Last Call in December. Other issues Rod Walsh outlined some open technical issues and design choices relating to the IMG work: * There are a number of design choices for transport protocols; for multicast, ALC/FLUTE is a very good candidate. * The Subscribe (unicast) model can be handled by SIP and SIP events. * The Metadata Envelope could be: a. XML file/wrapper, or b. header extension of transport protocols. Both? * Data types and channelization: could correlate data type and transport channel? Or could divide delivery over multiple channels? There is a middlebox authentication and integrity issue, since a middlebox could invalidate the sender signature in some cases (by performing header modification). Various possible solutions exist: trusted middlebox; middlebox could inform the sender of its change and request re-signing; middlebox could sign the data. Jonathan Rosenberg asked whether in this discussion "middlebox" connoted a NAT or firewall, or whether it simply meant some router in the abstract? Rod confirmed that the latter meaning was intended. Jonathan advised him not to call it a middlebox, to avoid confusion. Alternative IP versions for SDP ------------------------------- Gonzalo Camarillo outlined the Alternative IP Versions Semantics for the SDP Grouping Framework (draft-camarillo-mmusic-alt-02.txt). The proposed IPV extension is backward compatible. Dual-stack hosts are strongly encouraged to implement IPV. The question is whether to make it a WG item? Flemming Andreassen suggested that text was needed to clarify the relationship to ICE. He noted that the key point of the extension is to avoid establishing multiple media streams. That said, could the extension be applied to abstract properties, beyond IPv4 vs IPv6? Gonzalo confirmed that it could. Jonathan Rosenberg affirmed that the draft does need text to make the relationship to ICE clear. It was suggested that IPV may not be the appropriate name. The consensus of the group was to make this a WG draft. Source and Sink SDP attributes ------------------------------ Gonzalo Camarillo discussed SDP source and sink attributes (draft-camarillo-sipping-transc-3pcc-00.txt). This draft came from the transcoding design team in SIPPING. It deals with a problem in the routing of media types, which is really a service location problem. J=F6rg suggested that this was really a small subset of the XCON WG topic area. The draft raises a potential problem: signalling by SDP could conflict with other media policy mechanisms. Gonzalo agreed that the team would clarify whether should use the more general mechanism or whether this one is justified. Security Descriptions --------------------- Flemming Andreassen reviewed the changes in the latest revision of the security descriptions draft (draft-ietf-mmusic-sdescriptions-02.txt). The draft has been generalised into a core framework and an SRTP specific part, and numerous editorial changes and clarifications have been included. In detail, the changes are: * offer/answer highlights differences between unicast/multicast and the initial/subsequent offer * rekeying is addressed via offer/answer; everything can be changed * additional rules and considerations for communicating the SRTP SRC parameter * removed the SRTP "use" parameter, which is now inferred from context * added Window-Size Hint and to SRTP profile * more rules for extensions... * updated IANA considerations and grammer There are still four open issues. Issue 1 was with multicast: * Shared vs. per-participant key? * When a key is shared, the streams need unique SSRCs per destination. * If per-participant keys are used, each participant has to convey his/her key separately. * How to support for hierarchical layered encoding schemes is another multicast issue. Flemming was not sure there is a single good solution. The proposal was made that multicast streams should be left for further study, and not included in this draft. Jon Peterson wondered if we had found the logical dividing line between unicast and multicast. Jonathan Rosenberg wanted to be sure the solution is mature before deciding this. J=F6rg indicated that he would like to progress the draft, since it addresses fairly urgent issues. There was agreement that it was reasonable to leave multicast for further study. Issue 2 was several problems with respect to the SRC parameter. Most of them are multicast based, hence can be left aside for now. There are still the questions of: * how many crypto contexts can sdescriptions establish? * handling SSRC collisions. There was a suggestion to remove the SSRC part and support single context only. However, Magnus Westerlund pointed out that you can get multiple SSRC from the same host. The decision was therefore to keep the SSRC part in the document for the moment. Issue 3 (on Flemming's slides) was purely multicast, and so was skipped. Issue 4 was the "Use" parameter which was removed, since it led to complexity and could be inferred from context. Is there any need for it? No feedback from the room - please read and comment. Flemming expects to provide an update by December. There are no other known issues. Should it go to WG Last Call? Need volunteers to give it a thorough review. Magnus volunteered on the spot. Jon Peterson is to organize as Security Area review. Security Preconditions ---------------------- Flemming Andreassen outlined draft-andreasen-mmusic-securityprecondition-00.txt on security preconditions. The problem: an ambiguity in security description selection. There is a need to block sending until the ambiguity is resolved. Should this be a WG work item? Gonzalo Camarillo suggested the WG look at RFC 3329 (Security Mechanism Agreement for the Session Initiation Protocol (SIP)) as a model to ensure not they are not introducing a security risk. Jon Peterson suggested the WG look at the possible use of security associations between hosts. He argued against the presence of security preconditions in RFC 3312 because of bootstrapping concerns. He was trying to recall detailed arguments: we had better look at the archives. Resolution: think about it a bit more. Interactive Connectivity Establishment -------------------------------------- Jonathan Rosenberg discussed ICE (draft-ietf-mmusic-ice-00.txt), which was accepted as an MMUSIC work item in Vienna. Since then, the draft has been rewritten to make it protocol independent: * generic session establishment protocol; * defined semantics in terms of that protocol; * ICE compliance defined in terms of mapping to generic protocol; * showed mapping for SIP (RTSP and H.323 are other possibilities, for future work) Another change is that it is necessary to know, through configuration, which is a public TURN relay (there may be non-public ones; public one is default). ICE now uses the TURN SEND mechanism to tell the relay to send a packet to a particular address-port; this can only be used before lockdown and is needed in inter-enterprise cases. Jonathan walked through a call flow. Magnus was concerned about a packet loss case after lockdown, before return to client. Jonathan will add a case to cover this. A question was asked: can a binding be removed? TURN can, but not ICE. Lockdown cannot be removed: keep things simple. In the rewrite, Jonathan removed the massive call flows section from the draft: SIP usage is not the point. Open issues include getting TCP to work (needs a connect method, and there is the issue: demultiplexing of STUN and data on the connection - perhaps try to avoid it by restricting functionality) and prioritization of addresses, basically pushing routing to endpoints. Is there a better way? Flemming Andreasen, without being specific, suggested that there may be something in the middle that can handle routing better. Issues to be addressed: * RTSP mapping? Jonathan lacks expertise and time... * Sequential send attempts: Magnus suggested to do the semantics only once, but Jonathan warned that we must not make assumptions about topology. * Use of multiple STUN servers? There was discussion on extra round trips. Jonathan indicated he would be pleased to see a better solution. There are tradeoffs: effficiency vs. reliability and safety. We can continue to think about optimizations (such as assuming the RTSP server is on the public network), but with great care. * Is it OK to have username/password in clear? * SDP ALT parameter conflict with 3GPP: Jonathan will fix. Jon Peterson noted that he wouldn't mind more warning from 3GPP. The IESG is working on a liaison process to achieve this. RTSP ---- Magnus Westerlund presented a number of changes incorporated in the latest draft version of RTSP (draft-ietf-mmusic-rfc2326bis-05.txt). Further changes have been agreed, but are not yet documented: * Implicit Redirect using new 3xx code to get SDP for supporting terminals. A feature tag will associated with this for backward compatibility. * Address class in "c=3D" needs to be checked. * Caching of methods is unspecified * Aggregate control URI deriving will be unspecified * Clarify the usage of SDP "a=3Drange" for TiVo type of devices * The server MAY close the TCP connection after receiving the 2xx message for a REDIRECT request * To write something about request to response time limitations. Keep the specification simple, details to be worked out. * ABNF to be collected in a single chapter * Issues with changing transport parameters using SETUP * Should the Location header work as base URI for requests with REDIRECT without SESSION header * Request/response time is not limited; needs clarification There are few open issues, but lots of editorial stuff to clean up. The team will try to edit out all known bugs by the end of year. A clean-up review can be held from January to March, with WG Last Call by March. The teleconferences will continue, starting on 3rd December. RTSP NAT -------- Thomas Zeng discussed RTSP NAT traversal (draft-ietf-mmusic-rtsp-nat-01.txt). There is still lots of work to do on the -01 draft based on Vienna comments, but work on the core RTSP spec took priority. Current focus is to clarify the requirements: * MUST work for all flavors of NAT, including symmetric * MUST work for firewalls, including those with ALGs * SHOULD have minimal impact on clients in the open and not dual hosted * SHOULD be simple to use/implement * SHOULD be secure Jonathan cautioned on the wording of requirements with respect to firewalls: make sure the aim is to support administrative control. There is an issue with dual-hosted clients. Thomas proposed to add a mechanism to support them: many RTSP servers won't allow such clients, to prevent DDOS attacks. Jon Peterson suggested that the most important task at hand is to explain the problem in great detail. Moving forward the next revision will clarify "statement of intention" and provide list of requirements. Will also remove any solutions requiring protocol extensions to a separate draft. Jonathan noted that some mechanisms can be provided on the basis of "required to implement, not required to use" RTSP END-OF-STREAM proposal --------------------------- Thomas Zeng discussed the END-OF-STREAM proposal for RTSP (draft-zeng-mmusic-rtsp-end-of-stream-01.txt). Background: RTCP BYE is awkward; would like to be able to reuse SSRC. Lately the RTSP team has been finding a requirement to push various items to the client: END-OF-STREAM, session descriptions and updates, error events. Some earlier drafts have been written in the area. Strawman proposal: extend RTSP, adding a Server-to-Client method with feature tag. There was a recent suggestion to use ANNOUNCE for the End-of-Stream application. Should this be generalized for other information? Tom Marshall suggested using a SET parameter. J=F6rg didn't think the semantics felt right. Regarding the strawman proposal: J=F6rg would like to avoid having to respecify connection management for the Server-to-Client direction. This was more a matter that the client should keep the connection up to receive notifications. Thomas provided an example of possible syntax. Magnus expressed a concern with the "bytes" specification in Range; this is a conflict. The example will be cleaned up. The next step is expand scope of draft to cover ANNOUNCE as an extension of the core specification. Should this be a WG item? Magnus and Colin both suggested further work before making this decision. We can decide on the mailing list after the next revision. We might consider pulling back this capability into the main specification. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 18:41:44 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 SAA04157 for ; Tue, 30 Mar 2004 18:41:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006ZK-6V for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKM4jr030767 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 15:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1V6-00080A-Og for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:22: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 PAA07188 for ; Wed, 12 Nov 2003 15:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1V4-0005Km-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 15:22:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1V4-0005Ki-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 15:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1V3-0007zL-DN; Wed, 12 Nov 2003 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1UC-0007pw-TM for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 15:21: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 PAA07122 for ; Wed, 12 Nov 2003 15:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1UB-0005JO-00 for mmusic@ietf.org; Wed, 12 Nov 2003 15:21:07 -0500 Received: from db1.ncube.com ([134.242.64.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1UA-0005J4-00 for mmusic@ietf.org; Wed, 12 Nov 2003 15:21:06 -0500 Received: from [192.168.2.4] (yosparc [134.242.67.23]) by db1.ncube.com (8.12.9/8.12.9) with ESMTP id hACKKSip021242; Wed, 12 Nov 2003 12:20:29 -0800 (PST) Subject: Re: [MMUSIC] RTSP: Proposed text for client timeout From: Sean Sheedy To: Tom Marshall Cc: mmusic@ietf.org In-Reply-To: <20031112053737.GE26651@real.com> References: <1068571652.3166.93.camel@laptop.osioda.org> <20031112053737.GE26651@real.com> Content-Type: text/plain Organization: nCube Corporation Message-Id: <1068668428.3172.36.camel@laptop.osioda.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 12 Nov 2003 14:20:28 -0600 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-11-11 at 23:37, Tom Marshall wrote: > > Servers SHOULD respond to requests in a timely manner even when a > > reliable transport such as TCP is used. Similarly, clients SHOULD wait > > for a sufficient time for a response before concluding that the server > > will not be acting upon its request. > > I agree with these statements. Unfortunately, it is very difficult to > define "sufficient" above, as this is affected by both server load and > network conditions. > > > Appropriate server and client time values are based on T1, which is a > > bounded estimate of the round-trip time (RTT). The RTT is estimated as > > in TCP (RFC 1323), with an initial value of 500 ms. The client MAY > > derive a more refined estimate of the RTT using the Timestamp header as > > described in Section 13.39. A client implementation MAY cache the last > > RTT measurement as the initial value for future connections. > > The TCP has access to control packets (ACKs) that the application typically > does not. How can an application distinguish variations in RTT due to > packet loss vs. congestion vs. physical propagation delay? Is it even > possible to have a meaningful RTT measurement in networks that have packet > loss on the physical layer (eg. wireless)? > > As I am sitting here typing this using the wireless signal from the IETF in > a hotel around the block from the conference, I'm getting sporadic packet > loss. If my SSH connection behaved according to this RTSP proposal, I would > not be able to finish writing this email. I don't think comparing SSH connections to RTSP requests and responses is valid. The goal of an SSH connection is to provide reliable data delivery, even in the face of underlying network difficulties. As such, long delays in the face of a lossy network are acceptable since the reliability goal can still be accomplished. The goal of RTSP is to provide an interactive user experience. This implies that network and server response time affects whether the goal can be accomplished. Although you can still play a media stream with a 30-second delay on the control channel, the user experience would likely be unacceptable. In other words, the standard for "sufficient" in RTSP is what human users are willing to accept. Since what constitutes acceptable delays in RTSP is determined by human perception, the source of the delay (packet loss, network congestion, server load, etc.) is irrelevant. The only question that needs to be answered from the client's perspective is: Is the server working on the request, or not? I think it's important that a user interface provides this information to the human waiting for the media stream. > > T1 is equal to the RTT, with the restriction that T1 is never less than > > 500 ms. This restriction is necessary because, while the client may > > adjust its RTT estimate, the server does not know the client's value. > > > > A client SHOULD wait at least 20*T1 before concluding that the server > > will not be responding to its request. > > > > A server SHOULD respond to all requests within 10*(minimum value of T1); > > that is, within 5 seconds. If the server is not ready to send its final > > response within this time, it SHOULD send a 100 response. After > > receiving a 100 response, the client SHOULD wait for further responses. > > The server MAY send additional 100 responses. Eventually, the server > > MUST send a final response indicating the success or failure of the > > request. > > How were the 500ms and the T1 multiples arrived at? 500 ms is the default RTT for both TCP and SIP. The multiples involved a bit of guessing, but were based on deployment experience. The 20* client multiplier for the recommended client wait time was chosen to provide a default time of 10 seconds, which in my experience on low-loss high-bandwidth networks is about the outer limit of what people are willing to tolerate. The 10* server multiplier was simply chosen to be something less than 20*, but not so small as to necessitate a 100 response under normal operation. In our discussions Tuesday, we settled on a slightly different server strategy. As soon as a server believes servicing a request will take longer than a fixed amount of time (2 seconds seemed like a popular value), it should immediately send a 100. It may then issue additional 100 responses as it deems useful until it's ready to send the final response. > Discussion in RFC 1323 characterizes the RTT measurement as a signal > processing problem. I am admittedly not a signal processing expert, but I > think that if we are to speak of RTT, it must be done with this > characteristic in mind. In particular, we cannot assume that the reader > understands the implications of the wide variety of network technologies, > TCP introduced delays, etc. "RTT" needs to be better defined in terms of > how it is measured, how often it is measured, and what unexpected factors > can influence it. I'm very concerned that someone will write an RTSP client > that does an RTT measurement with the first RTSP message and gets some small > result like 3ms, then drops the connection when a response is delayed by > 60ms because the server happens to be a bit busy and/or a couple packets get > dropped due to congestion. This is why I am opposed to acting on negative > feedback. I think that the only sensible option for a protocol that runs on > top of TCP is to use positive feedback exclusively, and let the user decide > when too much time has passed without response (possibly via a configurable > setting with sensible defaults). This is why the floor T1 value is 500 ms. If a client follows the suggested algorithm, it should wait at least 10 seconds before giving up, but may wait longer if it wishes based either on the course-grained RTT measurement possible with the Timestamp header, or on a user-configurable setting. Sean -- Sean Sheedy seans@ncube.com (503) 531-6427 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 18:53:36 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 SAA07239 for ; Tue, 30 Mar 2004 18:53: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 1B8Rix-0006ZK-80 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF4KBt001226 for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFM-0000Jd-8l for mmusic-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:04: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 KAA16775 for ; Wed, 18 Feb 2004 10:04:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTFK-00064R-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:04:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTDt-0005me-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:02:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTCF-0005Sr-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCG-000666-HA; Wed, 18 Feb 2004 10:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTBx-0005xh-BO for mmusic@optimus.ietf.org; Wed, 18 Feb 2004 10:00:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15958; Wed, 18 Feb 2004 10:00:45 -0500 (EST) Message-Id: <200402181500.KAA15958@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: Wed, 18 Feb 2004 10:00:45 -0500 Subject: [MMUSIC] I-D ACTION: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.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 : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne Filename : draft-ietf-mmusic-rfc2326bis-06.txt Pages : 157 Date : 2004-2-18 This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable con- trolled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-06.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-rfc2326bis-06.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-rfc2326bis-06.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-18101406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101406.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 Mar 30 18:53: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 SAA07298 for ; Tue, 30 Mar 2004 18:53: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 1B8Rix-0006WI-9a for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFZlI3022557 for mmusic-archive@odin.ietf.org; Mon, 16 Feb 2004 10:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askmf-0005oA-2F for mmusic-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:35: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 KAA25670 for ; Mon, 16 Feb 2004 10:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Askmb-0004ng-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 10:35:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asklb-0004gc-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 10:34:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Askky-0004av-00 for mmusic-web-archive@ietf.org; Mon, 16 Feb 2004 10:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askky-00051I-Pn; Mon, 16 Feb 2004 10:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskkC-0004ie-Av for mmusic@optimus.ietf.org; Mon, 16 Feb 2004 10:33:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25124; Mon, 16 Feb 2004 10:33:07 -0500 (EST) Message-Id: <200402161533.KAA25124@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: Mon, 16 Feb 2004 10:33:07 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.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 Security Descriptions for Media Streams Author(s) : F. Andreasen, M. Baugher, D. Wing Filename : draft-ietf-mmusic-sdescriptions-03.txt Pages : 36 Date : 2004-2-13 This document defines a Session Description Protocol (SDP) cryptographic attribute for media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This document defines the Secure Real- time Transport Protocol (SRTP) parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-03.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-sdescriptions-03.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-sdescriptions-03.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-16104605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16104605.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 Mar 30 18:54:05 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 SAA07324 for ; Tue, 30 Mar 2004 18:54:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006Yx-AH for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF4DdG000800 for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFF-0000Ci-G7 for mmusic-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:04:13 -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 KAA16742 for ; Wed, 18 Feb 2004 10:04:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTFD-00062z-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTDm-0005l4-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:02:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTCC-0005SF-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCD-000615-BE; Wed, 18 Feb 2004 10:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTBS-0005im-VR for mmusic@optimus.ietf.org; Wed, 18 Feb 2004 10:00:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15843; Wed, 18 Feb 2004 10:00:14 -0500 (EST) Message-Id: <200402181500.KAA15843@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: Wed, 18 Feb 2004 10:00:14 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-framework-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.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 : A Framework for the Usage of Internet Media Guides Author(s) : Y. Nomura Filename : draft-ietf-mmusic-img-framework-03.txt Pages : 23 Date : 2004-2-18 This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document describes several use case scenarios requirering the IMG framework, a generalized model for IMG delivery mechanisms, and the use of existing protocol to create an IMG delivery infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-03.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-img-framework-03.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-img-framework-03.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-18101326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101326.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 Mar 30 18:54:05 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 SAA07328 for ; Tue, 30 Mar 2004 18:54:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006a4-4n for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF4IXN001132 for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFK-0000I8-Rj for mmusic-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:04: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 KAA16772 for ; Wed, 18 Feb 2004 10:04:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTFI-000649-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTDr-0005m3-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:02:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTCE-0005Sg-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCF-00065U-Sr; Wed, 18 Feb 2004 10:01:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTBn-0005so-EO for mmusic@optimus.ietf.org; Wed, 18 Feb 2004 10:00:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15927; Wed, 18 Feb 2004 10:00:35 -0500 (EST) Message-Id: <200402181500.KAA15927@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: Wed, 18 Feb 2004 10:00:35 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-req-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.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 : Protocol Requirements for Internet Media Guides Author(s) : Y. Nomura Filename : draft-ietf-mmusic-img-req-03.txt Pages : 21 Date : 2004-2-18 This memo specifies requirements for a protocol for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide development of an IMG protocol for efficient and scalable delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-03.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-img-req-03.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-img-req-03.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-18101353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101353.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 Mar 30 18:54:06 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 SAA07359 for ; Tue, 30 Mar 2004 18:54:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006Yx-7u for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF4DMI000781 for mmusic-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFF-0000CT-Bo for mmusic-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:04:13 -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 KAA16741 for ; Wed, 18 Feb 2004 10:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTFD-000633-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTDm-0005lC-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:02:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTCC-0005SI-00 for mmusic-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCE-00062G-38; Wed, 18 Feb 2004 10:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTBd-0005pX-Kd for mmusic@optimus.ietf.org; Wed, 18 Feb 2004 10:00:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15892; Wed, 18 Feb 2004 10:00:26 -0500 (EST) Message-Id: <200402181500.KAA15892@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: Wed, 18 Feb 2004 10:00:25 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-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 : How to Enable Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls Author(s) : M. Westerlund, T. Zeng Filename : draft-ietf-mmusic-rtsp-nat-02.txt Pages : 29 Date : 2004-2-18 This document describes six different types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations are given. Further a description on how RTSP relates to firewalls is given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-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-rtsp-nat-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-rtsp-nat-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-18101340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101340.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 Mar 30 18:59: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 SAA08800 for ; Tue, 30 Mar 2004 18:59: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 1B8Ris-0006Yx-NQ for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKUF0r023229 for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 15:30:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYxq-00062R-UV for mmusic-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:30: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 PAA10036 for ; Wed, 19 Nov 2003 15:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYxp-0001YA-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 15:30:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMYxo-0001XU-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 15:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYwg-0005lR-OA; Wed, 19 Nov 2003 15:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYw2-0005TO-PH for mmusic@optimus.ietf.org; Wed, 19 Nov 2003 15:28:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09839; Wed, 19 Nov 2003 15:28:09 -0500 (EST) Message-Id: <200311192028.PAA09839@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: Wed, 19 Nov 2003 15:28:09 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-framework-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Framework for the Usage of Internet Media Guides Author(s) : Y. Nomura Filename : draft-ietf-mmusic-img-framework-00.txt Pages : 26 Date : 2003-11-19 This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document describes several use case scenarios requirering the IMG framework, a generalized model for IMG delivery mechanisms, and the use of existing protocol to create an IMG delivery infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-00.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-img-framework-00.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-img-framework-00.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: <2003-11-19144739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144739.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 Mar 30 21:29: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 VAA18558 for ; Tue, 30 Mar 2004 21:29: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 1B8VTH-0005vD-Ls for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 21:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V2SpXF022764 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 21:28:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8VTH-0005v5-G0 for mmusic-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 21:28: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 VAA18540 for ; Tue, 30 Mar 2004 21:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8VTE-0002fw-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 21:28:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8VSJ-0002cK-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 21:27:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8VRX-0002YU-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 21: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 1B8VRV-0005cZ-44; Tue, 30 Mar 2004 21: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 1B8VQa-0005bT-Is for mmusic@optimus.ietf.org; Tue, 30 Mar 2004 21:26: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 VAA18268 for ; Tue, 30 Mar 2004 21:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8VQX-0002Sf-00 for mmusic@ietf.org; Tue, 30 Mar 2004 21:26:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8VPl-0002Nl-00 for mmusic@ietf.org; Tue, 30 Mar 2004 21:25:14 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B8VP8-0002HO-00 for mmusic@ietf.org; Tue, 30 Mar 2004 21:24:34 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2V2OYpB013956 for ; Tue, 30 Mar 2004 19:24:34 -0700 (MST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HVF00J555CXBS@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 30 Mar 2004 18:24:34 -0800 (PST) Date: Tue, 30 Mar 2004 18:25:14 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <40642EB6.8030100@ericsson.com> To: Magnus Westerlund , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <406A2C0A.4030302@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> <406331DC.2080203@sun.com> <40642EB6.8030100@ericsson.com> 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 Magnus, Thanks for clarifying your assumptions. This is helpful. More inline.. Magnus Westerlund wrote: > Hi Geetha, > > Answers below to what I assume. > > Geetha Srikantan wrote: > >> hi Magnus, >> >> I'm still reviewing your response. A couple of questions about your >> response.. >> >> Are you assuming : >> >> (a) That all live sources are RTSP-aware? > > > No, but that the there is a root-distributor that is a RTSP server. > The root RTSP server can be synchronized using either standard RTP > means or any proprietary solution as this interface is not > standardized. However it will be this RTSP root server that will be > responsible giving the stream a NPT time, unless that is also provided > through the interface between RTSP and the live source. I was assuming the same thing. >> >> (b) The server could maintain it's own RTP clock for each stream by >> observing >> the RTP timestamps of packets on each stream? >> > > I don't see how that this would be necessary. If one has a RTSP server > that receives a RTP + RTCP media stream. It will after listened to > this for a few seconds received all necessary synchronization > information. If this is not the root server and is only a relay it can > use RTSP to receive the synchronization information for the media > streams it is forwarding directly in RTSP. > This is an important point of concern. I agree that an RTSP server, after it has received RTCP SR for each stream, can map TS to NPT. There are some issues though: 1. The server may not see RTCP SRs for all streams in the RTSP session for several seconds, because of (a) staggered transmission of RTCP SRs of each stream, (b) lost SRs. Since RTCP transmission intervals can be 5-10 seconds, this could be 10-20 seconds or so. Now the server could either (a) deny all client requests for the live session until it receives RTCP SRs for all streams - even though the server has RTP packets for all streams. This implies that clients won't have access to the live stream for several seconds after the session was requested. OR (b) respond to client requests without the RTP-Info header in PLAY responses. If (a) and (b) are accepted as likely scenarios, then the clients cannot expect to see a RTP-Info header in PLAY responses, and should be able to handle the absence of the RTP-Info header. 2. The server may not know when the live session started, for example if it joins an ongoing live session. One option is for the server to assume NPT=0 at the time it receives RTP packets from the live source, and use that in synchronization mappings. So, the Range header would have this server-interpreted version of NPT. >> (c) The live source's transmission schedule for packets follows the >> RTP timestamp clock? >> That is, each succeeding packet's RTP timestamp will be equal to >> or greater than all previous >> packets, for that stream (modulo rollover)? >> > > I am only assuming that this is a normal RTP media stream. Thus it can > have backwards jump and other non-monotonic behaviour in the timestamp > field. However I do expect that the RTP packets are sent in order, but > not received by any relay in order. Thus a relay will be required to > take certain care against reordering in the RTP-Info sequence number > field. Reordering and lost packets make it difficult to populate the sequence number field of RTP-Info headers for live streams. This is not the case for stored content. I think this is a point worth noting for live streaming. If the server has to guess about the next packet it is going to send, it can't be a good thing. > I am however relying on that RTCP stream contains SRs for all media > streams sent to allow the server to make inter media synchronization, > and to be able to correctly provide the NPT to TS mapping. > thanks geetha > > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Mar 30 22:05: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 WAA20270 for ; Tue, 30 Mar 2004 22:05: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 1B8W1s-0007wY-F2 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 22:04:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V34aF1030535 for mmusic-archive@odin.ietf.org; Tue, 30 Mar 2004 22:04:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8W1s-0007wQ-9Z for mmusic-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 22:04:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20248 for ; Tue, 30 Mar 2004 22:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8W1p-0005ya-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 22:04:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8W0K-0005hz-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 22:03:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8VzN-0005aL-00 for mmusic-web-archive@ietf.org; Tue, 30 Mar 2004 22:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8VzN-0007ne-4T; Tue, 30 Mar 2004 22:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8VyV-0007mN-Dh for mmusic@optimus.ietf.org; Tue, 30 Mar 2004 22:01: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 WAA20095 for ; Tue, 30 Mar 2004 22:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8VyS-0005Uh-00 for mmusic@ietf.org; Tue, 30 Mar 2004 22:01:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8VxV-0005PV-00 for mmusic@ietf.org; Tue, 30 Mar 2004 22:00:06 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B8Vwc-0005G3-00 for mmusic@ietf.org; Tue, 30 Mar 2004 21:59:10 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2V2wfni009765 for ; Tue, 30 Mar 2004 18:58:41 -0800 (PST) Received: from sun.com (jamba.SFBay.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HVF00BGD6XSNK@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 30 Mar 2004 18:58:41 -0800 (PST) Date: Tue, 30 Mar 2004 18:59:21 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <40605F48.9030001@ericsson.com> To: Magnus Westerlund , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <406A3409.4030705@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> 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 Magnus, I see your point of view on this, since you clarified your assumptions. In previous offline discussions there were discussions about how a RTSP server would maintain timing info for live streams. My confusion was centered around that. I believe RTCP SR-based synchronization is possible, as you pointed out..however it does have some issues, as mentioned previously. Replying inline to some of the points in this mesage... Magnus Westerlund wrote: >> (b) Lost packets between live source and server, imply that the server >> cannot accurately predict the next packet's sequence number. > > > Also here I can't see the problem. The RTP sequence number indicates > the first sequence number for a stream that the given synchronization > information and time range applies for. Thus if one receives a RTP > packet with a higher sequence number one knows that it is for the new > range. > > A relay server that has received at least one packet can give this > information that is valid even if a several RTP packets is lost before > one gets forward. The client can't determine if the loss is between > the relay or before. > > And if the server really has not received either the information from > a upstream source or any RTP packet when responding, this value can be > excluded. The RTP-Info header only requires either of the values to be > present. I did not realize that the RTP-Info header only requires either of the values to be present. I don't see it in section 14.33 of the draft..am I missing something? > Also if one really can't establish the information one is allowed to > excluded. It is after all a SHOULD not a MUST. However in general it > seems reasonable that a server will be able to provide this information. True.. >> Section 11.4, page 45: >> 2nd last paragraph: >> >> Range header for live streams: >> There is a subtle difference in the semantics of the Range header for >> live >> streams versus on-demand streams. For on-demand streams, the Range >> header's start value refers to the presentation time, i.e. NPT of the >> presentation. >> For live streams, the Range header's start value indicates either >> (a) the duration of time between the start of the live session and the >> time when this Range header was created, or, >> (b) the wall-clock time at the server responding to PLAY requests. >> > > In both these cases the time is as viewed by the origin server. In a > relay structure, it is not the local time of each relay. Using RTSP > for relay will provide all relay servers also with the correct view of > the NPT or wall clock time of the origin server. Ok.. > >> Also the main purpose of the Range header is to map the NPT to >> the RTP timestamp. As discussed above this mapping is not terribly >> accurate in several live streaming scenarios. > > > As I don't think it is any less accurate then for on-demand media I > don't understand what the problem is. I agree that RTCP SR-based mapping of NPT to TS is accurate..except that this mapping is not possible until an SR is received for each stream of the RTSP session. >> If the live streams are part of a multicast session then there would >> be an indication of the time when the session is active in the SDP, >> however, with clock skews etc, it is diffcult to accurately pinpoint >> the instantaneous time in the session. > > > The instantaneous time is calculated based of the RTP timestamp for a > given media and the mapping received by Range and RTP-Info between RTP > timestamp and NPT at any point > > Example: > > Sync point > -----|------------------------------------x------> t > TS A B > > > When one started the session one received by Range and RTP-Info the > following information for RTP TS A. > > PLAY response: > Range: npt=56.97- > RTP-Info: url=; rtptime=164400 > > Thus A = 1644000 > The media timestamp rate is 90kHz. > > The NPT time for B=465357 is: > > (465357-164400)/90000 + 56.97 = 60,3139666 s > This is fine as long as a non-zero and numeric Range header value exists. In the case where the live source is not RTSP-aware, there is no Range header available and sync point A is effectively NPT=0, assuming the server started accessing the live session at A. >> If the start time of the live session is not known, then 'npt=now-' >> is the only reasonable value for the Range header in a PLAYresponse. >> > > I agree that if one truly does not know the time since session start > it is a viable operation. You mean that npt=now- is acceptable in the Range header in this case, right? > However all functionality exist to know the time. Did you mean that the timestamp to NPT mapping is possible as you described above? >> For this reason, it would be good to *not* require a Range header >> other than 'Range: npt=now-' for live streams. >> > > No, I think there are a lot of application that can benefit from > presenting the original wall clock or time since session start. As long as there is an understanding that the session start may not be an accurate value, as in cases where it is not known. >> Perhaps this could also be the mechanism to signal to the client that >> this is a live stream and that it needs to perform stream >> synchronization strictly via RTCP sender reports. >> > > There are already text in there to indicate that the session has live > qualities. There are already reasons why a client must support > synchronization by RTCP. For example sender side clock skew > corrections, multiple sources using different SSRCs, the possibility > to exclude RTP-Info header. However the RTP-Info+Range header is a > reliable transferred information. Although not guaranteed to be > timely, it has a rather high probability to reach the client prior to > any RTCP message. Also in most case it should reach the client prior > to it finishing initial buffering, thus providing it with good initial > synchronization for all media streams. Yes, I agree that RTP-Info+Range can be helpful to the client since they are transmitted over RTSP/TCP. My point is that if there are inaccuracies in either RTP-Info or Range because of unknown quantities like session start time, missing packets, these need to be tolerated by clients. >> Section 14.40, page 91: >> ssrc: >> The transport header in the server's response cannot populate the ssrc >> for each stream, accurately in certain scenarios. >> The source of the live stream may not be RTSP-aware, and the server >> has to rely on RTP/RTCP to determine ssrc for each stream. >> The server may have joined a multicast live session and receives, >> say, one of the streams. >> It also receives SETUP request from a client and needs to respond to >> SETUP from a client, >> before it sees the first packet of each stream. >> Dropping the ssrc parameter from the Transport header in the SETUP >> response would >> simplify this case. > > > It is possible to skip the SSRC, however not recommend as it indicates > for which SSRC the synchronization information in RTP-Info applies to. > Thus I would recommend that server awaits at least the first RTP > packet to determine what SSRC is used for media distribution. I am not convinced that the user experience is good when a server refuses clients access to live sessions until it has access to all the stream synchronization information. If the server were to send RTP and RTCP packets, without the RTP-Info or SSRC in RTSP responses, the client has an opportunity to start decoding each stream independently and perform inter-stream synchronization as soon as the client receivess one RTCP SR per stream. There is at least some media being rendered at the client, even if it is not lip-sync'd etc. thanks geetha > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Mar 31 10:45: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 KAA29503 for ; Wed, 31 Mar 2004 10:45: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 1B8hth-0004kI-Uc for mmusic-archive@odin.ietf.org; Wed, 31 Mar 2004 10:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VFivoo018243 for mmusic-archive@odin.ietf.org; Wed, 31 Mar 2004 10:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hth-0004kA-MK for mmusic-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 10:44: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 KAA29485 for ; Wed, 31 Mar 2004 10:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8htf-00008x-00 for mmusic-web-archive@ietf.org; Wed, 31 Mar 2004 10:44:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8hsk-00005J-00 for mmusic-web-archive@ietf.org; Wed, 31 Mar 2004 10:43:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8hsT-00003f-00 for mmusic-web-archive@ietf.org; Wed, 31 Mar 2004 10:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hrp-0004Yy-9p; Wed, 31 Mar 2004 10: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 1B8hrk-0004YN-RP for mmusic@optimus.ietf.org; Wed, 31 Mar 2004 10:42: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 KAA29435 for ; Wed, 31 Mar 2004 10:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8hri-000029-00 for mmusic@ietf.org; Wed, 31 Mar 2004 10:42:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8hqm-000006-00 for mmusic@ietf.org; Wed, 31 Mar 2004 10:41:56 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1B8hpw-0007kn-00 for mmusic@ietf.org; Wed, 31 Mar 2004 10:41:04 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2VFeU5P002582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2004 07:40:30 -0800 (PST) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2VFeRUR016970; Wed, 31 Mar 2004 07:40:27 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 07:40:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-03.txt Date: Wed, 31 Mar 2004 07:40:46 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327DB9@NAEX01.na.qualcomm.com> Thread-Topic: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-03.txt Thread-Index: AcQA4OioinOXBb0iTe+oSjmJn9/XeQWVXy+g From: "Barany, Pete" To: "Colin Perkins" , Cc: X-OriginalArrivalTime: 31 Mar 2004 15:40:27.0233 (UTC) FILETIME=[7D5FF510:01C41736] 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 Hi, What is the status of this Internet draft? Thanks. Regards, Pete -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of Colin Perkins Sent: Tuesday, March 02, 2004 9:28 PM To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de Subject: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-03.txt This is to announce a working group last call on the SDP Security Descriptions for Media Streams . Please send any final comments on this draft to the MMUSIC mailing list=20 by 19th March 2004. If no substantive technical comments are received by that time, we will request that this draft be published as a proposed standard RFC.=20 --=20 Colin Perkins http://csperkins.org/ _______________________________________________ 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