From exim@www1.ietf.org Sat Nov 1 05:03:35 2003 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 FAA02672 for ; Sat, 1 Nov 2003 05:03: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 1AFsbE-0005mJ-38 for mmusic-archive@odin.ietf.org; Sat, 01 Nov 2003 05:03:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1A3Fvu022200 for mmusic-archive@odin.ietf.org; Sat, 1 Nov 2003 05:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFsbC-0005ly-Ia for mmusic-web-archive@optimus.ietf.org; Sat, 01 Nov 2003 05:03: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 FAA02661 for ; Sat, 1 Nov 2003 05:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFsb9-0007K9-00 for mmusic-web-archive@ietf.org; Sat, 01 Nov 2003 05:03:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFsb8-0007K5-00 for mmusic-web-archive@ietf.org; Sat, 01 Nov 2003 05:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFsb2-0005l5-JL; Sat, 01 Nov 2003 05:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbzB-0000rp-Is for mmusic@optimus.ietf.org; Fri, 31 Oct 2003 11:18: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 LAA05551 for ; Fri, 31 Oct 2003 11:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbzA-0002Wv-00 for mmusic@ietf.org; Fri, 31 Oct 2003 11:18:52 -0500 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 1AFbz9-0002Wa-00 for mmusic@ietf.org; Fri, 31 Oct 2003 11:18:52 -0500 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-1) for id 1AFbyf-0004L3-Ku; Fri, 31 Oct 2003 17:18:21 +0100 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Fri, 31 Oct 2003 17:18:21 +0100 (CET) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-1) for id 1AFbyf-0004Ko-Jv; Fri, 31 Oct 2003 17:18:21 +0100 Received: from almathea (mail@almathea.tkn.TU-Berlin.DE [130.149.49.56]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h9VGILn14569 for ; Fri, 31 Oct 2003 17:18:21 +0100 Received: from karl by almathea with local (Exim 3.35 #1 (Debian)) id 1AFbyf-0006zD-00 for ; Fri, 31 Oct 2003 17:18:21 +0100 To: mmusic@ietf.org Message-Id: From: Holger Karl Date: Fri, 31 Oct 2003 17:18:21 +0100 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Fri, 31 Oct 2003 17:18:21 +0100 Subject: [MMUSIC] Call for Papers: WiOpt'04 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: , Apologies if you receive multiple copies of this call! Please note the deadline extension! ---------------------------------------------------------------------- DEADLINE EXTENSION The submission deadline has been extended to the 12th of November, 2003. *************************************************** ******** 2nd CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 12, 2003 (EXTENDED!). Notification of acceptance: Jan. 15, 2004. Camera ready copy: Feb. 15, 2004. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, X. Cao, A. Chockalingam, Jon Crowcroft, Anthony Ephremides, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Derek Mcauley, Archan Misra, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ariel Orda, Ramesh Rao, Catherine Rosenberg, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier, Moshe Zukerman Local Arrangements Co-Chair: Sven Oestring, Julian Chesterfield and Rajiv Chakravorty Treasurer: Meng How Lim Publicity Chair: Holger Karl The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) Additional financial support is provided by: * Intel * Microsoft Research _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 1 05:49:42 2003 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 FAA02673 for ; Sat, 1 Nov 2003 05:03: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 1AFsbE-0005mI-2n for mmusic-archive@odin.ietf.org; Sat, 01 Nov 2003 05:03:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1A3FYY022205 for mmusic-archive@odin.ietf.org; Sat, 1 Nov 2003 05:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFsbD-0005m3-2R for mmusic-web-archive@optimus.ietf.org; Sat, 01 Nov 2003 05:03: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 FAA02662 for ; Sat, 1 Nov 2003 05:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFsb9-0007KC-00 for mmusic-web-archive@ietf.org; Sat, 01 Nov 2003 05:03:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFsb8-0007K6-00 for mmusic-web-archive@ietf.org; Sat, 01 Nov 2003 05:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFsaz-0005ku-8b; Sat, 01 Nov 2003 05:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaMY-00055z-LL for mmusic@optimus.ietf.org; Fri, 31 Oct 2003 09:34: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 JAA29596 for ; Fri, 31 Oct 2003 09:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaMW-0000n2-00 for mmusic@ietf.org; Fri, 31 Oct 2003 09:34:52 -0500 Received: from varis.cs.tut.fi ([130.230.4.42] helo=cs.tut.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AFaMV-0000mz-00 for mmusic@ietf.org; Fri, 31 Oct 2003 09:34:51 -0500 Received: from samipelt (peltotas@kiuru.cs.tut.fi [130.230.4.18]) by cs.tut.fi (8.12.10/8.12.8) with SMTP id h9VEYnuY028354; Fri, 31 Oct 2003 16:34:49 +0200 (EET) From: "Sami Peltotalo" To: Subject: RE: [MMUSIC] Service/Session Announcement for Multicast Apps Date: Fri, 31 Oct 2003 16:36:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I am currently working with topic, which handles service and session = announcements for multicast applications. SAP/SDP doesn't suit very well = for describing services, which could be categorized to different groups, = for example sports, news etc. So that the receiver could build some kind = of service hierarchy from the announcements, and the user is able to = browse the services from categories he or she is interested. At least I = have chosen another protocols than SAP/SDP in my work. RMT working = group's FLUTE protocol seems to be very good choise for the transmission = of service descriptions, so I am using it. I can't use SAP because it = has limited payload size and payload can't be segmented to different = packets (my service and session descriptions are much larger than for = example one SDP description). I am using XML in my service and session = descriptions so it was nice to notice that SDPng has now again = XML-Schema. Has anyone else considered to use FLUTE for transmission of = session announcements?=20 Cheers, Sami > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Rod.Walsh@nokia.com > Sent: 15. lokakuuta 2003 12:58 > To: mmusic@ietf.org; mboned@network-services.uoregon.edu > Subject: [MMUSIC] Service/Session Announcement for Multicast Apps >=20 >=20 > Does anyone have a problem with a new and better announcement=20 > protocol than SAP? >=20 > We need a few things which SAP doesn't handle too well, which is=20 > one of the things covered by the Internet Media Guide effort in=20 > MMUSIC:=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt >=20 > I guess anyone involved in applications/services over multicast=20 > could be interested, especially where point-to-point isn't desirable. >=20 > I wanted to get an idea of any strong opinions before I stick out=20 > head and propose a real protocol task for MMUSIC next month. >=20 > Cheers, Rod. >=20 > _______________________________________________ > 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 Sun Nov 2 09:57:26 2003 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 JAA16906 for ; Sun, 2 Nov 2003 09:57: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 1AGJf9-0007lC-AL for mmusic-archive@odin.ietf.org; Sun, 02 Nov 2003 09:57:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2Ev769029827 for mmusic-archive@odin.ietf.org; Sun, 2 Nov 2003 09:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGJf9-0007l0-69 for mmusic-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 09:57: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 JAA16891 for ; Sun, 2 Nov 2003 09:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGJf7-0007Ak-00 for mmusic-web-archive@ietf.org; Sun, 02 Nov 2003 09:57:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGJf6-0007Ag-00 for mmusic-web-archive@ietf.org; Sun, 02 Nov 2003 09:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGJf3-0007k5-9P; Sun, 02 Nov 2003 09:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGJec-0007jI-F3 for mmusic@optimus.ietf.org; Sun, 02 Nov 2003 09:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16872 for ; Sun, 2 Nov 2003 09:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGJea-0007A4-00 for mmusic@ietf.org; Sun, 02 Nov 2003 09:56:32 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AGJeZ-00079m-00 for mmusic@ietf.org; Sun, 02 Nov 2003 09:56:31 -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 hA2Etcca023483; Sun, 2 Nov 2003 15:55:38 +0100 (MET) Message-ID: <3FA51B8B.9000908@tzi.uni-bremen.de> Date: Sun, 02 Nov 2003 15:58:19 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: csp@csperkins.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Draft Agenda for MPLS 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 Folks, MMUSIC will be meeting once in MPLS (on Friday morning). Please find attached our draft agenda for this meeting. If anything is missing or incorrect, please let us know. Thanks, Colin and Joerg --------------------------------------------------------------------------- Multiparty Multimedia Session Control (MMUSIC) CHAIRS: Joerg Ott Colin Perkins Friday, 14 November 2003, 09:00 - 11:30 --------------------------------------- 0900 Agenda Bashing and Status Update (Chairs, 15) Recent RFCs draft-ietf-mmusic-sdp4nat-05.txt -> RFC 3605 With RFC editor draft-ietf-mmusic-sdpng-trans-04.txt With IESG draft-ietf-mmusic-sdp-new-15.txt draft-rajeshkumar-mmusic-gpmd-03.txt With AD draft-ietf-mmusic-sdp-comedia-05.txt draft-ietf-mmusic-sdp-bwparam-05.txt draft-ietf-mmusic-srcfilter-05.txt Misc Updates draft-camarillo-mmusic-alt-01.txt draft-ietf-mmusic-kmgmt-ext-09.txt draft-ietf-mmusic-sdp-implem-00.txt draft-ietf-mmusic-sdp-new-15.txt 0915 Internet Media Guides (Manyfolks, 30) draft-ietf-mmusic-img-req-00.txt draft-nomura-mmusic-img-framework-02.txt (draft-luoma-mmusic-img-metadata-02.txt fyi only) (draft-luoma-mmusic-img-muppet-03.txt fyi only) 0945 SDP for alternate IP versions (Camarillo, 10) draft-camarillo-mmusic-alt-02.txt 0955 SDP Security Descriptions for Media Streams (Andreasen, 15) draft-ietf-mmusic-sdescriptions-02.txt draft-andreasen-mmusic-securityprecondition-00.txt 1010 SDP parameters to support H.263/H.261 options (Even/Ismail, 15) draft-even-avt-h263-h261-options-00.txt draft-nismail-mmusic-sdp-video-00.txt 1025 Interactive Connectivity Establishment (ICE) (Rosenberg, 20) draft-ietf-mmusic-ice-00.txt draft-rosenberg-sipping-ice-01.txt 1045 SDPng Update (Kutscher, 15) draft-ietf-mmusic-sdpng-07.txt 1100 RTSP Update (Westerlund/Zeng, 30) draft-ietf-mmusic-rfc2326bis-05.txt draft-ietf-mmusic-rtsp-nat-01.txt draft-zeng-mmusic-rtsp-end-of-stream-01.txt 1130 Close ----------------------------------------------------------------------------- NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 3 04:29:25 2003 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 EAA24935 for ; Mon, 3 Nov 2003 04:29: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 1AGb1E-0000gN-Bo for mmusic-archive@odin.ietf.org; Mon, 03 Nov 2003 04:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA39T4dI002618 for mmusic-archive@odin.ietf.org; Mon, 3 Nov 2003 04:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGb1D-0000g7-Rp for mmusic-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 04:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24862 for ; Mon, 3 Nov 2003 04:28:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGb1A-0002Y6-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 04:29:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGb1A-0002Y3-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 04:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGb1C-0000fW-SD; Mon, 03 Nov 2003 04: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 1AGb0P-0000RC-PA for mmusic@optimus.ietf.org; Mon, 03 Nov 2003 04:28: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 EAA24821 for ; Mon, 3 Nov 2003 04:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGb0M-0002Ww-00 for mmusic@ietf.org; Mon, 03 Nov 2003 04:28:10 -0500 Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx with esmtp (Exim 4.12) id 1AGb0M-0002WV-00 for mmusic@ietf.org; Mon, 03 Nov 2003 04:28:10 -0500 Received: from oleane ([194.250.212.114]) by smtp5.clb.oleane.net with SMTP id hA39RepR016207 for ; Mon, 3 Nov 2003 10:27:40 +0100 Message-ID: <015801c3a1ed$37afe020$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Mon, 3 Nov 2003 10:31:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0155_01C3A1F5.993A4C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [MMUSIC] UWB Summit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0155_01C3A1F5.993A4C60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Which proposal will be selected as the IEEE 802.15.3a standard? A = consortium has just proposed to offer a RANDZ access to its patents. The = industry is now waiting for the reply from the supporters of the other = proposal.=20 This battle between technology heavyweights underlines the growing = importance of a technology expected to generate $1.39 billion in revenue = by 2007. All questions and answers will be delivered during the UWB Summit to be = held in Paris next 2-5 December. All details at: http://www.upperside.fr/newmobtech/uwb03cfp.htm ------=_NextPart_000_0155_01C3A1F5.993A4C60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Which proposal will be selected as = the=20 IEEE 802.15.3a standard? A consortium has just proposed = to=20 offer a RANDZ access to its patents. The industry is now waiting for the = reply=20 from the supporters of the other proposal.
This battle between technology = heavyweights=20 underlines the growing importance of a technology expected to generate = $1.39=20 billion in revenue by 2007.
All questions and answers will be = delivered=20 during the UWB Summit to be held in Paris next 2-5=20 December.
All details at:
http://www.upper= side.fr/newmobtech/uwb03cfp.htm
------=_NextPart_000_0155_01C3A1F5.993A4C60-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 3 05:32:22 2003 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 FAA26591 for ; Mon, 3 Nov 2003 05:32:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc0A-00048T-Va for mmusic-archive@odin.ietf.org; Mon, 03 Nov 2003 05:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3AW2bN015891 for mmusic-archive@odin.ietf.org; Mon, 3 Nov 2003 05: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 1AGc0A-00048E-SR for mmusic-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 05:32: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 FAA26578 for ; Mon, 3 Nov 2003 05:31:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc07-0003M0-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 05:31:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGc06-0003Lx-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 05:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc09-00047f-Lg; Mon, 03 Nov 2003 05:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbzH-00044a-CV for mmusic@optimus.ietf.org; Mon, 03 Nov 2003 05:31: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 FAA26535 for ; Mon, 3 Nov 2003 05:30:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGbzD-0003LH-00 for mmusic@ietf.org; Mon, 03 Nov 2003 05:31:03 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AGbzD-0003LD-00 for mmusic@ietf.org; Mon, 03 Nov 2003 05:31:03 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA3AUtI2011006; Mon, 3 Nov 2003 11:30:55 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NMF80X; Mon, 3 Nov 2003 11:30:55 +0100 Message-ID: <3FA62E59.9040407@ericsson.com> Date: Mon, 03 Nov 2003 11:30:49 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP transport negotiation References: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> <1067625819.5805.48.camel@jamba> In-Reply-To: <1067625819.5805.48.camel@jamba> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In this matter, are there really a need to included a Range header to indicate when the SETUP request is to change parameters? What is the use case for this. You can't send the SETUP to move to the new transport prior to that the new transport interface exist. Therefore I don't see a problem with having it change parameters as soon as the request is received. Unless you have transport interfaces that remain available during some overlapping time you will of course have a result of losing packets during the switch. Regarding the use of Range header in the SETUP. If appropriately motivated it can of course be changed. However the potential backwards compatibility problems needs to be considered. If this work becomes large in impact, we might have to consider splitting it into a separate document. However so far I don't think there are sufficient need. I am sorry that I haven't had time to properly review your proposal. 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 3 09:45:24 2003 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 JAA03979 for ; Mon, 3 Nov 2003 09:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfx3-0001Vx-9n for mmusic-archive@odin.ietf.org; Mon, 03 Nov 2003 09:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Ej5Mb005815 for mmusic-archive@odin.ietf.org; Mon, 3 Nov 2003 09:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfx3-0001Vi-4Z for mmusic-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 09:45: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 JAA03972 for ; Mon, 3 Nov 2003 09:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfx1-0006eS-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 09:45:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGfx0-0006eP-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 09:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfwz-0001VD-PO; Mon, 03 Nov 2003 09:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfwa-0001UI-Eg for mmusic@optimus.ietf.org; Mon, 03 Nov 2003 09:44: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 JAA03948 for ; Mon, 3 Nov 2003 09:44:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfwY-0006ci-00 for mmusic@ietf.org; Mon, 03 Nov 2003 09:44:34 -0500 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 1AGfwY-0006cD-00 for mmusic@ietf.org; Mon, 03 Nov 2003 09:44:34 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HNS00M0163UHR@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 03 Nov 2003 14:41:01 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HNS00M9B61UHG@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 03 Nov 2003 14:39:30 +0000 (GMT) Received: by BEEX10 with Internet Mail Service (5.5.2650.21) id ; Mon, 03 Nov 2003 14:40:00 +0000 Content-return: allowed Date: Mon, 03 Nov 2003 14:33:54 +0000 From: "Elwell, John" To: "'mmusic@ietf.org'" Message-id: <50B1CBA96870A34799A506B2313F266761FE6B@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_DIxZr9bFxanRfrt9Npbk9w)" Subject: [MMUSIC] Clarification on use of sendonly for hold 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: , 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. --Boundary_(ID_DIxZr9bFxanRfrt9Npbk9w) Content-type: text/plain Content-Transfer-Encoding: 7BIT In section 8.4 of RFC3264 it says: "Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out." This seems strange. If the UA is not sending any media to the far end, why not use "inactive" instead of "sendonly"? John Elwell (john.elwell@siemens.com) --Boundary_(ID_DIxZr9bFxanRfrt9Npbk9w) Content-type: text/html Content-Transfer-Encoding: 7BIT Clarification on use of sendonly for hold

In section 8.4 of RFC3264 it says:

"Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far  end, and no media is played out."

This seems strange. If the UA is not sending any media to the far end, why not use "inactive" instead of "sendonly"?

John Elwell (john.elwell@siemens.com)

--Boundary_(ID_DIxZr9bFxanRfrt9Npbk9w)-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 3 17:52:24 2003 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 RAA00475 for ; Mon, 3 Nov 2003 17:52:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnYL-0007RK-Ib for mmusic-archive@odin.ietf.org; Mon, 03 Nov 2003 17:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Mq5Qq028592 for mmusic-archive@odin.ietf.org; Mon, 3 Nov 2003 17:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnYL-0007R5-Eg for mmusic-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:52:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00465 for ; Mon, 3 Nov 2003 17:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnYI-0007bh-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 17:52:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGnYI-0007bV-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 17:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnYG-0007QE-MB; Mon, 03 Nov 2003 17:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnXK-0007P6-MS for mmusic@optimus.ietf.org; Mon, 03 Nov 2003 17:51:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00441 for ; Mon, 3 Nov 2003 17:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnXI-0007aU-00 for mmusic@ietf.org; Mon, 03 Nov 2003 17:51:00 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AGnXH-0007aB-00 for mmusic@ietf.org; Mon, 03 Nov 2003 17:50:59 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2003 14:54:24 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA3MoRAt005781; Mon, 3 Nov 2003 14:50:27 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADR57033; Mon, 3 Nov 2003 17:50:26 -0500 (EST) Message-ID: <3FA6DBB2.6080101@cisco.com> Date: Mon, 03 Nov 2003 17:50:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" CC: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] Clarification on use of sendonly for hold References: <50B1CBA96870A34799A506B2313F266761FE6B@ntht201e> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That sort of makes sense, but it presents a problem. It doesn't provide a clear indication of which end *wants* the call to be on hold, and which one doesn't. Paul Elwell, John wrote: > In section 8.4 of RFC3264 it says: > > "Typically, when a user "presses" hold, the agent will generate an offer > with all streams in the SDP indicating a direction of sendonly, and it > will also locally mute, so that no media is sent to the far end, and no > media is played out." > > This seems strange. If the UA is not sending any media to the far end, > why not use "inactive" instead of "sendonly"? > > John Elwell (john.elwell@siemens.com) > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 3 23:21:24 2003 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 XAA14107 for ; Mon, 3 Nov 2003 23:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsgj-0005jG-2b for mmusic-archive@odin.ietf.org; Mon, 03 Nov 2003 23:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA44L4G0022016 for mmusic-archive@odin.ietf.org; Mon, 3 Nov 2003 23:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsgi-0005j1-Rc for mmusic-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 23:21: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 XAA14088 for ; Mon, 3 Nov 2003 23:20:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsgg-0005E1-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 23:21:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGsgg-0005Dy-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 23:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsgf-0005iE-Ov; Mon, 03 Nov 2003 23:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsg4-0005gm-TO for mmusic@optimus.ietf.org; Mon, 03 Nov 2003 23:20: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 XAA14082 for ; Mon, 3 Nov 2003 23:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsg2-0005Dl-00 for mmusic@ietf.org; Mon, 03 Nov 2003 23:20:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGsg2-0005DZ-00 for mmusic@ietf.org; Mon, 03 Nov 2003 23:20:22 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44Jqca010836; Mon, 3 Nov 2003 23:19:53 -0500 (EST) Message-ID: <3FA6F401.2040606@dynamicsoft.com> Date: Mon, 03 Nov 2003 19:34:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" CC: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] Clarification on use of sendonly for hold References: <50B1CBA96870A34799A506B2313F266761FE6B@ntht201e> In-Reply-To: <50B1CBA96870A34799A506B2313F266761FE6B@ntht201e> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To allow for situations where there is muzak or other media placed while the call is on hold. That said, there is nothing wrong with using inactive if you want, if you have no plans to do that. -Jonathan R. Elwell, John wrote: > In section 8.4 of RFC3264 it says: > > "Typically, when a user "presses" hold, the agent will generate an offer > with all streams in the SDP indicating a direction of sendonly, and it > will also locally mute, so that no media is sent to the far end, and no > media is played out." > > This seems strange. If the UA is not sending any media to the far end, > why not use "inactive" instead of "sendonly"? > > John Elwell (john.elwell@siemens.com) > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 3 23:50:23 2003 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 XAA14757 for ; Mon, 3 Nov 2003 23:50: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 1AGt8m-0007IA-69 for mmusic-archive@odin.ietf.org; Mon, 03 Nov 2003 23:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA44o48E028024 for mmusic-archive@odin.ietf.org; Mon, 3 Nov 2003 23:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGt8m-0007Hv-2h for mmusic-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 23:50: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 XAA14752 for ; Mon, 3 Nov 2003 23:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGt8j-0005Xa-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 23:50:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGt8j-0005XX-00 for mmusic-web-archive@ietf.org; Mon, 03 Nov 2003 23:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGt8k-0007GR-I1; Mon, 03 Nov 2003 23:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGt8c-0007Fd-1q for mmusic@optimus.ietf.org; Mon, 03 Nov 2003 23:49: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 XAA14749 for ; Mon, 3 Nov 2003 23:49:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGt8Z-0005XT-00 for mmusic@ietf.org; Mon, 03 Nov 2003 23:49:51 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGt8Z-0005XO-00 for mmusic@ietf.org; Mon, 03 Nov 2003 23:49:51 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44nDca010931; Mon, 3 Nov 2003 23:49:14 -0500 (EST) Message-ID: <3FA72FC4.3040000@dynamicsoft.com> Date: Mon, 03 Nov 2003 23:49:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Elwell, John" , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] Clarification on use of sendonly for hold References: <50B1CBA96870A34799A506B2313F266761FE6B@ntht201e> <3FA6DBB2.6080101@cisco.com> In-Reply-To: <3FA6DBB2.6080101@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Its not the feature "on-hold" that is being signaled. Its the fact that media is not desired, which can be signaled for any number of reasons. -Jonathan R. Paul Kyzivat wrote: > That sort of makes sense, but it presents a problem. It doesn't provide > a clear indication of which end *wants* the call to be on hold, and > which one doesn't. > > Paul > > Elwell, John wrote: > >> In section 8.4 of RFC3264 it says: >> >> "Typically, when a user "presses" hold, the agent will generate an >> offer with all streams in the SDP indicating a direction of sendonly, >> and it will also locally mute, so that no media is sent to the far >> end, and no media is played out." >> >> This seems strange. If the UA is not sending any media to the far end, >> why not use "inactive" instead of "sendonly"? >> >> John Elwell (john.elwell@siemens.com) >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 4 02:09:24 2003 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 CAA27908 for ; Tue, 4 Nov 2003 02:09:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvJJ-0008Lo-Uc for mmusic-archive@odin.ietf.org; Tue, 04 Nov 2003 02:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA47956O032097 for mmusic-archive@odin.ietf.org; Tue, 4 Nov 2003 02:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvJJ-0008Lc-9z for mmusic-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 02:09: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 CAA27367 for ; Tue, 4 Nov 2003 02:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvJF-0007Js-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 02:09:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGvJF-0007Jp-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 02:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvJF-0008Kr-UD; Tue, 04 Nov 2003 02:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvIP-000898-Or for mmusic@optimus.ietf.org; Tue, 04 Nov 2003 02:08: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 CAA26341 for ; Tue, 4 Nov 2003 02:07:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvIH-0007JK-00 for mmusic@ietf.org; Tue, 04 Nov 2003 02:08:01 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AGvIG-0007JH-00 for mmusic@ietf.org; Tue, 04 Nov 2003 02:08:00 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA477sSs013090; Tue, 4 Nov 2003 08:07:54 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 08:08:16 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Jonathan Rosenberg'" , Paul Kyzivat Cc: "Elwell, John" , "'mmusic@ietf.org'" Subject: RE: [MMUSIC] Clarification on use of sendonly for hold Date: Tue, 4 Nov 2003 08:06:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi, I think it's also to think about what is sent in the ANSWER (it's not very well described in RFC3264). IF the UAS knows the UAS wishes to put the call on-hold (sending "sendonly" in the offer doesn't always have to indicate that, as Jonathain said) it may answer with "inactive". However, if the UAC simply, for whatever reason, doesn't want to receive, but still send, media (by sending "sendonly" in the offer) the UAS may answer with "recvonly". Again, this should probably be a little more clarified in RFC3264. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 4. marraskuuta 2003 6:49 > To: Paul Kyzivat > Cc: Elwell, John; 'mmusic@ietf.org' > Subject: Re: [MMUSIC] Clarification on use of sendonly for hold > > > Its not the feature "on-hold" that is being signaled. Its the fact > that media is not desired, which can be signaled for any number of > reasons. > > -Jonathan R. > > Paul Kyzivat wrote: > > > That sort of makes sense, but it presents a problem. It > doesn't provide > > a clear indication of which end *wants* the call to be on hold, and > > which one doesn't. > > > > Paul > > > > Elwell, John wrote: > > > >> In section 8.4 of RFC3264 it says: > >> > >> "Typically, when a user "presses" hold, the agent will generate an > >> offer with all streams in the SDP indicating a direction > of sendonly, > >> and it will also locally mute, so that no media is sent to > the far > >> end, and no media is played out." > >> > >> This seems strange. If the UA is not sending any media to > the far end, > >> why not use "inactive" instead of "sendonly"? > >> > >> John Elwell (john.elwell@siemens.com) > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 4 03:07:24 2003 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 DAA03030 for ; Tue, 4 Nov 2003 03:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwDS-0005oP-GQ for mmusic-archive@odin.ietf.org; Tue, 04 Nov 2003 03:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4876Fs022332 for mmusic-archive@odin.ietf.org; Tue, 4 Nov 2003 03:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwDR-0005nu-C5 for mmusic-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 03:07: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 DAA03006 for ; Tue, 4 Nov 2003 03:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwDN-0000RP-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 03:07:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGwDM-0000RM-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 03: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 1AGwDN-0005mp-5W; Tue, 04 Nov 2003 03: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 1AGwD0-0005lO-SS for mmusic@optimus.ietf.org; Tue, 04 Nov 2003 03:06: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 DAA02985 for ; Tue, 4 Nov 2003 03:06:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwCw-0000RI-00 for mmusic@ietf.org; Tue, 04 Nov 2003 03:06:34 -0500 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 1AGwCw-0000R9-00 for mmusic@ietf.org; Tue, 04 Nov 2003 03:06:34 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HNT00601IGHPQ@siemenscomms.co.uk> for mmusic@ietf.org; Tue, 04 Nov 2003 08:05:05 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HNT0063RIGHME@siemenscomms.co.uk>; Tue, 04 Nov 2003 08:05:05 +0000 (GMT) Received: by BEEX10 with Internet Mail Service (5.5.2650.21) id ; Tue, 04 Nov 2003 08:05:35 +0000 Content-return: allowed Date: Tue, 04 Nov 2003 07:59:28 +0000 From: "Elwell, John" Subject: RE: [MMUSIC] Clarification on use of sendonly for hold To: "'Jonathan Rosenberg'" Cc: "'mmusic@ietf.org'" Message-id: <50B1CBA96870A34799A506B2313F266761FE6F@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain 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 Jonathan, Your reply below, and also the one you sent to Paul Kyzivat, are in line with how I had interpreted things. However, we have encountered implementations that offer sendonly on audio but do not supply music. The problem we then have is whether a UAS should supply its own music. If it receives inactive, clearly it is at liberty to do so. If it receives sendonly, I believe it should not supply local music, because there may be music or some other audio from the far end (although in many cases there is not). Some clarification in RFC3264 would be beneficial. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 04 November 2003 00:34 > To: Elwell, John > Cc: 'mmusic@ietf.org' > Subject: Re: [MMUSIC] Clarification on use of sendonly for hold > > > To allow for situations where there is muzak or other media placed > while the call is on hold. That said, there is nothing wrong with > using inactive if you want, if you have no plans to do that. > > -Jonathan R. > > Elwell, John wrote: > > > In section 8.4 of RFC3264 it says: > > > > "Typically, when a user "presses" hold, the agent will > generate an offer > > with all streams in the SDP indicating a direction of > sendonly, and it > > will also locally mute, so that no media is sent to the far > end, and no > > media is played out." > > > > This seems strange. If the UA is not sending any media to > the far end, > > why not use "inactive" instead of "sendonly"? > > > > John Elwell (john.elwell@siemens.com) > > > > -- > 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 Nov 4 07:57:22 2003 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 HAA12920 for ; Tue, 4 Nov 2003 07:57:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0k2-0003Ss-Mt for mmusic-archive@odin.ietf.org; Tue, 04 Nov 2003 07:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Cv2m6013312 for mmusic-archive@odin.ietf.org; Tue, 4 Nov 2003 07:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0k2-0003Sd-Ix for mmusic-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 07:57: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 HAA12910 for ; Tue, 4 Nov 2003 07:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0k1-0004yC-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 07:57:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH0k1-0004y9-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 07:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0k1-0003S6-0G; Tue, 04 Nov 2003 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0jG-0003PQ-NM for mmusic@optimus.ietf.org; Tue, 04 Nov 2003 07:56: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 HAA12889 for ; Tue, 4 Nov 2003 07:56:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0jF-0004xj-00 for mmusic@ietf.org; Tue, 04 Nov 2003 07:56:13 -0500 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 1AH0jD-0004wl-00 for mmusic@ietf.org; Tue, 04 Nov 2003 07:56:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] RTSP transport negotiation Date: Tue, 4 Nov 2003 13:57:20 +0100 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B90949F74689@swing.cefriel.it> Thread-Topic: [MMUSIC] RTSP transport negotiation Thread-Index: AcOf3xztkuRZjsErRzqdfedsd8+b9wC5qHZA From: "Enrico Balatti" To: "Geetha Srikantan" Cc: 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Geetha, recently I've implemented the solution a) that you mentioned using well = know open source RTSP client and server implementation. I noticed that sending the SETUP during the play state (to change the = "destination" of RTP packets) and then send the PLAY with the Range header doesn't work very well due = to syncronization problems. The only working solution I found, was to send the PAUSE method before = the SETUP and the PLAY. I think this behaviour is due to the RTSP client-server = implementation that I've used and maybe it doesn't happen with other implementation. Anyway, I think that (in the case of client mobility) the best solution = should be that the client sends only the SETUP request with the new = "client_ip" without any other RTSP message (PAUSE and PLAY). Regards, Enrico ------------------------------------------------------------------ Ing Enrico M. Balatti CEFRIEL - Politecnico di Milano ICT Center of Excellence For Research, Innovation, Education & industrial Labs partnership via Fucini 2, 20133 Milano (ITALY) voice: +39 0223954327 fax: +39 0223954527 e-mail: balatti@cefriel.it www.cefriel.it = =20 ------------------------------------------------------------------ -----Original Message----- From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] Sent: venerd=EC 31 ottobre 2003 19.44 To: Enrico Balatti Cc: mmusic@ietf.org Subject: RE: [MMUSIC] RTSP transport negotiation hi Enrico, Thanks for the comments.. That's true - per the current spec we cannot have a Range header in the SETUP request. However, if there were no Range header in the SETUP request during play state, the client would have to either=20 (a) send a PLAY request with a Range header and use the PLAY response=20 for synchronization, or, (b) live with the range selected by the server when it receives a SETUP=20 during play state. With (a) there is the issue of an extra PLAY request-response. It might just be better for the client to issue a PAUSE from the old transport setting, send a SETUP request to modify transport and PLAY to resume playing from the Range of the client's choosing. Here the transport negotiation happens in Ready state not Play state. With (b) there is a high likelihood of synchronization problems when transport parameters change - RTP packets would get delivered to the old transport, and discarded; the server has no way of knowing the gap in time between when it processes the SETUP during play and when the packets it already sent didn't actually get used by the player. This implies media glitches at the client are a real possibility. My inclination is to go with either specifying a Range header in the SETUP request during play state or send the SETUP request without Range, follow it up with a PLAY request with Range header. In the latter case we'd be violating another restriction in the spec about issuing PLAY requests during Play state, I believe. So this implies the spec would have to modify restrictions on either the SETUP request or the PLAY request. It would be good to get more comments on this, especially from the authors. thanks geetha On Wed, 2003-10-29 at 06:02, Enrico Balatti wrote: > Dear Geetha, >=20 > >... now change client IP address .... > > > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > CSeq: 5 > > Transport: RTP/AVP;unicast;client_ip=3D > client_port=3D8002-8003;server_port=3D9004-9005 > > Range: npt=3D5- > > Session: 12345678 >=20 >=20 > I'm not sure the Range field can be aplicated to the SETUP request. > From the specification it seems the Range is applicable on the SETUP = response > but not in the SETUP request. >=20 > Header Where Proxy DES OPT SETUP PLAY PAUSE TRD =20 >=20 > Range R - - - o o - > Range r - - c m* m* - >=20 >=20 > Best Regards, > Enrico >=20 >=20 >=20 >=20 > ------------------------------------------------------------------ > Ing Enrico M. Balatti > CEFRIEL - Politecnico di Milano > ICT Center of Excellence For Research, Innovation, > Education & industrial Labs partnership > via Fucini 2, 20133 Milano (ITALY) > voice: +39 0223954327 fax: +39 0223954527 > e-mail: balatti@cefriel.it = www.cefriel.it =20 > ------------------------------------------------------------------ >=20 >=20 > -----Original Message----- > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > Sent: mercoled=EC 22 ottobre 2003 7.26 > To: mmusic@ietf.org > Subject: [MMUSIC] RTSP transport negotiation >=20 >=20 > Hello everyone, >=20 > Here is the promised write-up on RTSP transport negotiation..sorry for > the delay. If there is agreement on the content of this note, I can > write up text for the RTSP draft. >=20 > thanks > geetha >=20 >=20 > Topic: RTSP Transport negotiation using SETUP during play state. >=20 > Introduction >=20 > The RTSP specification allows for negotiation of transport parameters > via the SETUP method, while the RTSP session is in play state. The > transport parameters that can be negotiated and the exact form of this > negotiation is under-specified in the RTSP documents. This note is an > attempt to clarify some of the issues around transport negotiation for > inclusion in the ongoing revision of RTSP. >=20 > The recent interest in mobility for RTSP implementations also impacts > transport parameters used by the session. For instance, a wireless > RTSP client could be assigned a new IP address, or may experience > change of network characteristics, while it is in the midst of a RTSP > session. These issues are also addressed in this note. >=20 >=20 > Outline: >=20 > 1. Objective > 2. Enumeration of all Transport Parameters > 3. Transport Parameters Excluded from Negotiation > 4. Negotiable Transport Parameters > 5. Impact of Transport Negotiation > 6. Examples > 6.1 Client IP Address Changes > 6.2 UDP -> TCP > 6.3 TCP -> UDP > 7. Other transport related changes to RTSP draft > 8. Summary >=20 >=20 >=20 > 1. Objective:=20 >=20 > The main goals of this document are to > * Provide an enumeration of transport parameters. > * Identify transport parameters that cannot be negotiated > with minimal impact on other sessions. > * Propose transport parameters that can be negotiated during > play state. > * Determine implications of changing these parameters via a > SETUP request while the session is in play state. > * Provide examples demonstrating transport negotiation. >=20 >=20 > 2. Enumeration of all Transport Parameters >=20 > The following is a list of all transport parameters in the current > RTSP draft. >=20 > unicast/multicast > destination > source > mode (=3DPLAY) > interleaved > layers (for multicast) > ttl (for multicast > port (for multicast) > client_port (for RTP) > server_port (for RTP) > ssrc (for RTP) > url >=20 >=20 > 3. Transport Parameters Excluded from Negotiation >=20 > It is recommended that the following parameters be excluded from = the > negotiation process. >=20 > mode > url > unicast/multicast > layers > ttl > ssrc > destination > source >=20 >=20 > As the "mode" parameter is restricted to a single value in the > current draft, it can be excluded. >=20 > As per the recent proposal to not support addition of urls via = SETUP > during play state, the "url" parameter can be excluded.=20 >=20 > Changing from multicast to unicast based on a single RTSP = session's > SETUP, would impact all the other clients accessing the multicast > session.=20 > Several issues need to be considered in this case, including transport > negotiation. Similarly, changing from unicast to multicast also has > implications beyond a single RTSP session. Changes to other > multicast-related parameters, "layers", "ssrc", "ttl" most likely > requires specification beyond transport negotiation. > The recommendation is to *not* specify changing the transport from > "unicast" to "multicast" or vice versa, and also not specify changes > to the "layers" and "ttl" parameters, in this draft. It is recommedned = > that negotiation of multicast-related transport parameters should be > deferred to an RTSP-extension document.=20 >=20 > Once an RTSP session has been initiated and the "destination" and > "source" have been established - i.e. a multicast "destination" has > been identified, and the stream "source" has been identified, there > should be no need to change these parameters. It is recommended that > the "destination" and "source" parameters not be negotiated when the > session is in play state. The case of the client IP address change is > signaled in a different manner, outlined in the next section. >=20 >=20 > 4. Negotiable Transport Parameters >=20 > Hence there are three main conditions that require transport > negotiation for unicast: >=20 > * client IP address changes > * client wants to switch transport from UDP -> TCP=20 > * client wants to switch transport from TCP -> UDP >=20 > Changes in the client IP address can be indicated using a new > "client_ip" parameter. Hence the parameters that are impacted by > transport negotiation are: >=20 > client_ip > interleaved > client_port > server_port >=20 > =20 > 5. Impact of Transport Negotiation >=20 > The first column describes the primary change, the second and third > columns describe any secondary transport parameters that MUST or=20 > MAY change as a result of the primary change. >=20 >=20 > Changed MUST MAY=09 > ------- ---- --- > =09 > Client IP address client_ip client_port > server_port >=20 > UDP -> TCP interleaved Server may change > Drop client_port interleaved channel ids > Drop server_port in response. >=20 > TCP -> UDP client_port in request client_ip > server_port in response client_port in response=09 > Drop interleaved >=20 >=20 >=20 > 6. Examples >=20 > 6.1 Client IP Address Changes >=20 > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 1 > Content-Type: application/sdp > Content-Length: 164 >=20 > v=3D0 > o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 > s=3DRTSP Session > i=3DAn Example of RTSP Session Usage > a=3Dcontrol:rtsp://foo/twister > t=3D0 0 > m=3Daudio 0 RTP/AVP 0 > a=3Dcontrol:rtsp://foo/twister/audio > m=3Dvideo 0 RTP/AVP 26 > a=3Dcontrol:rtsp://foo/twister/video >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=3D8000-8001 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=3D8000-8001; > server_port=3D9000-9001 > Session: 12345678 >=20 > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 3 > Transport: RTP/AVP;unicast;client_port=3D8002-8003 > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 3 > Transport: RTP/AVP;unicast;client_port=3D8002-8003; > server_port=3D9004-9005 > Session: 12345678 >=20 > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 4 > Range: npt=3D0- > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 4 > Session: 12345678 > RTP-Info: url=3Drtsp://foo/twister/video; > seq=3D9810092;rtptime=3D3450012, > url=3Drtsp://foo/twister/audio;seq=3D5923;rtptime=3D22234432 > Range: npt=3D0-30.76 >=20 > ... now change client IP address .... >=20 > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip=3D client_port=3D8002-8003;server_port=3D9004-9005 > Range: npt=3D5- > Session: 12345678 > =09 > S->C: RTSP/1.0 200 OK > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip=3D; > client_port=3D8002-8003;server_port=3D9004-9005 > RTP-Info: url=3Drtsp://foo/twister/video; > seq=3D;rtptime=3D, > Range: npt=3D5-30.76 > Session: 12345678 >=20 >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 6 > Transport:RTP/AVP;unicast;client_ip=3D; > client_port=3D8000-8001;server_port=3D9000-9001 > Range: npt=3D5- > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 6 > Transport: RTP/AVP;unicast;client_ip=3D; > client_port=3D8000-8001;server_port=3D9000-9001 > RTP-Info:url=3Drtsp://foo/twister/audio; > seq=3D;rtptime=3D > Range: npt=3D5-30.76=09 > Session: 12345678 >=20 >=20 >=20 > =20 > 6.2 UDP -> TCP >=20 > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Content-Length: 230 > Content-Type: application/sdp > Cseq: 1 >=20 > v=3D0 > o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 > s=3DRTSP Session > c=3DIN IP4 0.0.0.0 > t=3D0 0 > a=3Dcontrol:* > a=3Drange:npt=3D0-10.566000 > m=3Dvideo 0 RTP/AVP 26 > a=3Dcontrol:rtsp://foo/twister/video > m=3Daudio 0 RTP/AVP 0 > a=3Dcontrol:rtsp://foo/twister/audio >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 2 > Session: 12345678 > Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; > server_port=3D9000-9001 >=20 > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 3 > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > CSeq: 3 > RTP-Info: = url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D1339949552 > Range: npt=3D0- > Session: 12345678 >=20 > ... now request TCP ... >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 4 > Transport: RTP/AVP/TCP;interleaved=3D0-1 >=20 > S->C: RTSP/1.0 200 OK > Cseq: 4 > Transport: RTP/AVP/TCP;unicast; > client_ip=3D;interleaved=3D0-1 > RTP-Info: = url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D > Range: npt=3D0-10.56600 > Session: 12345678 >=20 >=20 >=20 > 6.3 TCP -> UDP >=20 > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Content-Length: 230 > Content-Type: application/sdp > Cseq: 1 >=20 > v=3D0 > o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 > s=3DRTSP Session > c=3DIN IP4 0.0.0.0 > t=3D0 0 > a=3Dcontrol:* > a=3Drange:npt=3D0-10.566000 > m=3Dvideo 0 RTP/AVP 26 > a=3Dcontrol:rtsp://foo/twister/video > m=3Daudio 0 RTP/AVP 0 > a=3Dcontrol:rtsp://foo/twister/audio >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP/TCP;interleaved=3D0-1 >=20 > S->C: RTSP/1.0 200 OK > Cseq: 2 > Session: 12345678 > Transport: RTP/AVP/TCP;unicast;client_ip=3D;interleaved=3D0-1 >=20 > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 3 > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Cseq: 3 > RTP-Info: = url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D1339949552 > Range: npt=3D0- > Session: 12345678 >=20 > ... now request UDP ... >=20 >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 4 > Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 > Range: npt=3D0- >=20 > S->C: RTSP/1.0 200 OK > CSeq: 4 > Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; > server_port=3D9000-9001 > RTP-Info: = url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D > Range: npt=3D0-10.56600 > Session: 12345678 >=20 >=20 >=20 >=20 > 7. Other transport related changes to RTSP draft >=20 > A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to > transport parameters. >=20 > (a) Section 13.40: > Page 81: Are "src_addr" and "dest_addr" parameters > going away? If these are relevant for NAT, perhaps they belong in > the NAT document? >=20 > Page 83-83: BNF indicates "client_port" and > "server_port" will be indicated as 'port1-port2'. This doesn't = seem > adequate for the case where the RTP and RTCP ports are = non-adjacent > (per the new RTP spec rfc 3550).=20 >=20 > Proposal: > client_port: rtp=3D, rtcp=3D > server_port: rtp=3D, rtcp=3D >=20 > (b) Appendix B, B.1.1 > Page 115: Mentions "src_addresses" and > "dest_addresses" - what are these? >=20 > Page 116: "non-continuous" ports - might want to rephrase to > "non-adjacent" (or "non-continguous") ports? >=20 >=20 >=20 > 8. Summary >=20 >=20 > This note recommends negotiation of a few transport parameters and > specifies mechanisms to do so. One new transport parameter "client_ip" = > is recommended for use in cases where the client's IP address changes > during the session.=20 >=20 > It is also recommended that the client_port and server_port parameters > be specified further with the use of tags "rtp_port" and "rtcp_port" > to handle the case where these ports are non-contiguous. --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 4 13:05:21 2003 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 NAA25538 for ; Tue, 4 Nov 2003 13:05: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 1AH5Y8-0007V7-6d for mmusic-archive@odin.ietf.org; Tue, 04 Nov 2003 13:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4I54Li028816 for mmusic-archive@odin.ietf.org; Tue, 4 Nov 2003 13:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5Y7-0007Ub-Pc for mmusic-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 13:05: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 NAA25532 for ; Tue, 4 Nov 2003 13:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5Y5-0001tn-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 13:05:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH5Y5-0001tk-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 13:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5Y6-0007U4-Hs; Tue, 04 Nov 2003 13:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5Xp-0007TV-MB for mmusic@optimus.ietf.org; Tue, 04 Nov 2003 13:04: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 NAA25524 for ; Tue, 4 Nov 2003 13:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5Xn-0001tZ-00 for mmusic@ietf.org; Tue, 04 Nov 2003 13:04:43 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AH5Xn-0001tW-00 for mmusic@ietf.org; Tue, 04 Nov 2003 13:04:43 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA4I4d62016556 for ; Tue, 4 Nov 2003 11:04:42 -0700 (MST) Received: from jamba (jamba.Eng.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 <0HNU00GROA7R07@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 04 Nov 2003 10:04:40 -0800 (PST) Date: Tue, 04 Nov 2003 10:05:04 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] RTSP transport negotiation In-reply-to: <3FA62E59.9040407@ericsson.com> To: Magnus Westerlund Cc: Enrico Balatti , mmusic@ietf.org Message-id: <1067969103.8724.18.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit References: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> <1067625819.5805.48.camel@jamba> <3FA62E59.9040407@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 Magnus, My assumption was that SETUP during play happens *after* the client has switched to the new transport..synchronization is an issue in this case. I agree that if we can assume that the client requests new transport before switching to the new transport, there is probably no synchronization issue. I have two follow-up questions on this: a) How does a mobile client get notified about new transports - such as a new IP address? How far ahead of time does the client get notified? b) What is the range of time over which the transport switch happens? Consider a scenario where the client requests an IP address change for example, via SETUP with no Range, and the server starts sending packets to the new IP. Is there a chance that the buffers at the new IP get overrun, before the client switches to the new IP? It would help if the network guarantees that the transport switch will not lose any packets due to buffer overflows, thanks geetha On Mon, 2003-11-03 at 02:30, Magnus Westerlund wrote: > Hi, > > In this matter, are there really a need to included a Range header to > indicate when the SETUP request is to change parameters? What is the use > case for this. You can't send the SETUP to move to the new transport > prior to that the new transport interface exist. Therefore I don't see a > problem with having it change parameters as soon as the request is > received. Unless you have transport interfaces that remain available > during some overlapping time you will of course have a result of losing > packets during the switch. > > Regarding the use of Range header in the SETUP. If appropriately > motivated it can of course be changed. However the potential backwards > compatibility problems needs to be considered. If this work becomes > large in impact, we might have to consider splitting it into a separate > document. However so far I don't think there are sufficient need. > > I am sorry that I haven't had time to properly review your proposal. > > Cheers > > Magnus -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 4 13:17:21 2003 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 NAA25967 for ; Tue, 4 Nov 2003 13:17: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 1AH5jj-0008GB-Ta for mmusic-archive@odin.ietf.org; Tue, 04 Nov 2003 13:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4IH3Ma031748 for mmusic-archive@odin.ietf.org; Tue, 4 Nov 2003 13:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5jj-0008Fz-PD for mmusic-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 13:17: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 NAA25944 for ; Tue, 4 Nov 2003 13:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5jh-00026R-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 13:17:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH5jh-00026O-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 13:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5ji-0008FW-4E; Tue, 04 Nov 2003 13:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5jY-0008FC-6x for mmusic@optimus.ietf.org; Tue, 04 Nov 2003 13:16: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 NAA25935 for ; Tue, 4 Nov 2003 13:16:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5jV-000267-00 for mmusic@ietf.org; Tue, 04 Nov 2003 13:16:49 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AH5jU-000260-00 for mmusic@ietf.org; Tue, 04 Nov 2003 13:16:48 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4IFUPx028405 for ; Tue, 4 Nov 2003 11:16:47 -0700 (MST) Received: from jamba (jamba.Eng.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 <0HNU00G3WARB07@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 04 Nov 2003 10:16:23 -0800 (PST) Date: Tue, 04 Nov 2003 10:16:47 -0800 From: Geetha Srikantan Subject: RE: [MMUSIC] RTSP transport negotiation In-reply-to: <6F5FB8313FE82C4EA10DA4DA40B90949F74689@swing.cefriel.it> To: Enrico Balatti Cc: mmusic@ietf.org Message-id: <1067969805.8724.31.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain; charset=ISO-8859-1 References: <6F5FB8313FE82C4EA10DA4DA40B90949F74689@swing.cefriel.it> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by brmea-mail-2.sun.com id hA4IFUPx028405 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi Enrico, Thanks for sharing your experience with implementing this. I wouldn't mind dropping the Range header from SETUP, as long as we also specify (please see my reply to Magnus on the topic): (a) To support transport negotiation in play state, the client may issue SETUP to change transport *before* switching to the new transport, and, (b) the client will switch to the new transport before buffers overrun at the new transport.=20 If transport negotiation is required in play state and (a) and (b) cannot be assumed, the client should issue a PAUSE, SETUP(*) and PLAY - this implies that transport negotiation occurs in ready state and not in play state. Does that sound reasonable? geetha On Tue, 2003-11-04 at 04:57, Enrico Balatti wrote: > Hi Geetha, >=20 > recently I've implemented the solution a) that you mentioned using well= know > open source RTSP client and server implementation. > I noticed that sending the SETUP during the play state (to change the "= destination" of RTP packets) > and then send the PLAY with the Range header doesn't work very well due= to syncronization problems. > The only working solution I found, was to send the PAUSE method before = the SETUP > and the PLAY. I think this behaviour is due to the RTSP client-server i= mplementation that > I've used and maybe it doesn't happen with other implementation. >=20 > Anyway, I think that (in the case of client mobility) the best solution= should be that the client sends only the SETUP request with the new "cli= ent_ip" without any other RTSP message (PAUSE and PLAY). >=20 > Regards, > Enrico >=20 >=20 >=20 > ------------------------------------------------------------------ > Ing Enrico M. Balatti > CEFRIEL - Politecnico di Milano > ICT Center of Excellence For Research, Innovation, > Education & industrial Labs partnership > via Fucini 2, 20133 Milano (ITALY) > voice: +39 0223954327 fax: +39 0223954527 > e-mail: balatti@cefriel.it www.cefriel.it= =20 > ------------------------------------------------------------------ >=20 >=20 > -----Original Message----- > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > Sent: venerd=EC 31 ottobre 2003 19.44 > To: Enrico Balatti > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] RTSP transport negotiation >=20 >=20 > hi Enrico, >=20 > Thanks for the comments.. >=20 > That's true - per the current spec we cannot have a Range header in the > SETUP request. > However, if there were no Range header in the SETUP request during play > state, the client would have to either=20 > (a) send a PLAY request with a Range header and use the PLAY response=20 > for synchronization, or, > (b) live with the range selected by the server when it receives a SETUP= =20 > during play state. >=20 > With (a) there is the issue of an extra PLAY request-response. It might > just be better for the client to issue a PAUSE from the old transport > setting, send a SETUP request to modify transport and PLAY to resume > playing from the Range of the client's choosing. Here the transport > negotiation happens in Ready state not Play state. >=20 > With (b) there is a high likelihood of synchronization problems when > transport parameters change - RTP packets would get delivered to the ol= d > transport, and discarded; the server has no way of knowing the gap in > time between when it processes the SETUP during play and when the > packets it already sent didn't actually get used by the player. This > implies media glitches at the client are a real possibility. >=20 > My inclination is to go with either specifying a Range header in the > SETUP request during play state or send the SETUP request without Range= , > follow it up with a PLAY request with Range header. In the latter case > we'd be violating another restriction in the spec about issuing PLAY > requests during Play state, I believe. So this implies the spec would > have to modify restrictions on either the SETUP request or the PLAY > request. >=20 > It would be good to get more comments on this, especially from the > authors. >=20 > thanks > geetha >=20 >=20 >=20 > On Wed, 2003-10-29 at 06:02, Enrico Balatti wrote: > > Dear Geetha, > >=20 > > >... now change client IP address .... > > > > > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > > CSeq: 5 > > > Transport: RTP/AVP;unicast;client_ip=3D > > client_port=3D8002-8003;server_port=3D9004-9005 > > > Range: npt=3D5- > > > Session: 12345678 > >=20 > >=20 > > I'm not sure the Range field can be aplicated to the SETUP request. > > From the specification it seems the Range is applicable on the SETUP = response > > but not in the SETUP request. > >=20 > > Header Where Proxy DES OPT SETUP PLAY PAUSE TRD =20 > >=20 > > Range R - - - o o - > > Range r - - c m* m* - > >=20 > >=20 > > Best Regards, > > Enrico > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------------------ > > Ing Enrico M. Balatti > > CEFRIEL - Politecnico di Milano > > ICT Center of Excellence For Research, Innovation, > > Education & industrial Labs partnership > > via Fucini 2, 20133 Milano (ITALY) > > voice: +39 0223954327 fax: +39 0223954527 > > e-mail: balatti@cefriel.it www.cefriel.= it =20 > > ------------------------------------------------------------------ > >=20 > >=20 > > -----Original Message----- > > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > > Sent: mercoled=EC 22 ottobre 2003 7.26 > > To: mmusic@ietf.org > > Subject: [MMUSIC] RTSP transport negotiation > >=20 > >=20 > > Hello everyone, > >=20 > > Here is the promised write-up on RTSP transport negotiation..sorry fo= r > > the delay. If there is agreement on the content of this note, I can > > write up text for the RTSP draft. > >=20 > > thanks > > geetha > >=20 > >=20 > > Topic: RTSP Transport negotiation using SETUP during play state. > >=20 > > Introduction > >=20 > > The RTSP specification allows for negotiation of transport parameters > > via the SETUP method, while the RTSP session is in play state. The > > transport parameters that can be negotiated and the exact form of thi= s > > negotiation is under-specified in the RTSP documents. This note is an > > attempt to clarify some of the issues around transport negotiation fo= r > > inclusion in the ongoing revision of RTSP. > >=20 > > The recent interest in mobility for RTSP implementations also impacts > > transport parameters used by the session. For instance, a wireless > > RTSP client could be assigned a new IP address, or may experience > > change of network characteristics, while it is in the midst of a RTSP > > session. These issues are also addressed in this note. > >=20 > >=20 > > Outline: > >=20 > > 1. Objective > > 2. Enumeration of all Transport Parameters > > 3. Transport Parameters Excluded from Negotiation > > 4. Negotiable Transport Parameters > > 5. Impact of Transport Negotiation > > 6. Examples > > 6.1 Client IP Address Changes > > 6.2 UDP -> TCP > > 6.3 TCP -> UDP > > 7. Other transport related changes to RTSP draft > > 8. Summary > >=20 > >=20 > >=20 > > 1. Objective:=20 > >=20 > > The main goals of this document are to > > * Provide an enumeration of transport parameters. > > * Identify transport parameters that cannot be negotiated > > with minimal impact on other sessions. > > * Propose transport parameters that can be negotiated during > > play state. > > * Determine implications of changing these parameters via a > > SETUP request while the session is in play state. > > * Provide examples demonstrating transport negotiation. > >=20 > >=20 > > 2. Enumeration of all Transport Parameters > >=20 > > The following is a list of all transport parameters in the current > > RTSP draft. > >=20 > > unicast/multicast > > destination > > source > > mode (=3DPLAY) > > interleaved > > layers (for multicast) > > ttl (for multicast > > port (for multicast) > > client_port (for RTP) > > server_port (for RTP) > > ssrc (for RTP) > > url > >=20 > >=20 > > 3. Transport Parameters Excluded from Negotiation > >=20 > > It is recommended that the following parameters be excluded from t= he > > negotiation process. > >=20 > > mode > > url > > unicast/multicast > > layers > > ttl > > ssrc > > destination > > source > >=20 > >=20 > > As the "mode" parameter is restricted to a single value in the > > current draft, it can be excluded. > >=20 > > As per the recent proposal to not support addition of urls via SE= TUP > > during play state, the "url" parameter can be excluded.=20 > >=20 > > Changing from multicast to unicast based on a single RTSP session= 's > > SETUP, would impact all the other clients accessing the multicast > > session.=20 > > Several issues need to be considered in this case, including transpor= t > > negotiation. Similarly, changing from unicast to multicast also has > > implications beyond a single RTSP session. Changes to other > > multicast-related parameters, "layers", "ssrc", "ttl" most likely > > requires specification beyond transport negotiation. > > The recommendation is to *not* specify changing the transport from > > "unicast" to "multicast" or vice versa, and also not specify changes > > to the "layers" and "ttl" parameters, in this draft. It is recommedne= d=20 > > that negotiation of multicast-related transport parameters should be > > deferred to an RTSP-extension document.=20 > >=20 > > Once an RTSP session has been initiated and the "destination" and > > "source" have been established - i.e. a multicast "destination" has > > been identified, and the stream "source" has been identified, there > > should be no need to change these parameters. It is recommended that > > the "destination" and "source" parameters not be negotiated when the > > session is in play state. The case of the client IP address change i= s > > signaled in a different manner, outlined in the next section. > >=20 > >=20 > > 4. Negotiable Transport Parameters > >=20 > > Hence there are three main conditions that require transport > > negotiation for unicast: > >=20 > > * client IP address changes > > * client wants to switch transport from UDP -> TCP=20 > > * client wants to switch transport from TCP -> UDP > >=20 > > Changes in the client IP address can be indicated using a new > > "client_ip" parameter. Hence the parameters that are impacted by > > transport negotiation are: > >=20 > > client_ip > > interleaved > > client_port > > server_port > >=20 > > =20 > > 5. Impact of Transport Negotiation > >=20 > > The first column describes the primary change, the second and thir= d > > columns describe any secondary transport parameters that MUST or=20 > > MAY change as a result of the primary change. > >=20 > >=20 > > Changed MUST MAY=09 > > ------- ---- --- > > =09 > > Client IP address client_ip client_port > > server_port > >=20 > > UDP -> TCP interleaved Server may change > > Drop client_port interleaved channel ids > > Drop server_port in response. > >=20 > > TCP -> UDP client_port in request client_ip > > server_port in response client_port in response=09 > > Drop interleaved > >=20 > >=20 > >=20 > > 6. Examples > >=20 > > 6.1 Client IP Address Changes > >=20 > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 > > CSeq: 1 > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 1 > > Content-Type: application/sdp > > Content-Length: 164 > >=20 > > v=3D0 > > o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 > > s=3DRTSP Session > > i=3DAn Example of RTSP Session Usage > > a=3Dcontrol:rtsp://foo/twister > > t=3D0 0 > > m=3Daudio 0 RTP/AVP 0 > > a=3Dcontrol:rtsp://foo/twister/audio > > m=3Dvideo 0 RTP/AVP 26 > > a=3Dcontrol:rtsp://foo/twister/video > >=20 > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 2 > > Transport: RTP/AVP;unicast;client_port=3D8000-8001 > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 2 > > Transport: RTP/AVP;unicast;client_port=3D8000-8001; > > server_port=3D9000-9001 > > Session: 12345678 > >=20 > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > CSeq: 3 > > Transport: RTP/AVP;unicast;client_port=3D8002-8003 > > Session: 12345678 > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 3 > > Transport: RTP/AVP;unicast;client_port=3D8002-8003; > > server_port=3D9004-9005 > > Session: 12345678 > >=20 > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > > CSeq: 4 > > Range: npt=3D0- > > Session: 12345678 > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 4 > > Session: 12345678 > > RTP-Info: url=3Drtsp://foo/twister/video; > > seq=3D9810092;rtptime=3D3450012, > > url=3Drtsp://foo/twister/audio;seq=3D5923;rtptime=3D22234432 > > Range: npt=3D0-30.76 > >=20 > > ... now change client IP address .... > >=20 > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > CSeq: 5 > > Transport: RTP/AVP;unicast;client_ip=3D > client_port=3D8002-8003;server_port=3D9004-9005 > > Range: npt=3D5- > > Session: 12345678 > > =09 > > S->C: RTSP/1.0 200 OK > > CSeq: 5 > > Transport: RTP/AVP;unicast;client_ip=3D; > > client_port=3D8002-8003;server_port=3D9004-9005 > > RTP-Info: url=3Drtsp://foo/twister/video; > > seq=3D;rtptime=3D, > > Range: npt=3D5-30.76 > > Session: 12345678 > >=20 > >=20 > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 6 > > Transport:RTP/AVP;unicast;client_ip=3D; > > client_port=3D8000-8001;server_port=3D9000-9001 > > Range: npt=3D5- > > Session: 12345678 > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 6 > > Transport: RTP/AVP;unicast;client_ip=3D; > > client_port=3D8000-8001;server_port=3D9000-9001 > > RTP-Info:url=3Drtsp://foo/twister/audio; > > seq=3D;rtptime=3D > > Range: npt=3D5-30.76=09 > > Session: 12345678 > >=20 > >=20 > >=20 > > =20 > > 6.2 UDP -> TCP > >=20 > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > > CSeq: 1 > >=20 > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > Content-Length: 230 > > Content-Type: application/sdp > > Cseq: 1 > >=20 > > v=3D0 > > o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 > > s=3DRTSP Session > > c=3DIN IP4 0.0.0.0 > > t=3D0 0 > > a=3Dcontrol:* > > a=3Drange:npt=3D0-10.566000 > > m=3Dvideo 0 RTP/AVP 26 > > a=3Dcontrol:rtsp://foo/twister/video > > m=3Daudio 0 RTP/AVP 0 > > a=3Dcontrol:rtsp://foo/twister/audio > >=20 > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 2 > > Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 2 > > Session: 12345678 > > Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; > > server_port=3D9000-9001 > >=20 > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > > CSeq: 3 > > Session: 12345678 > >=20 > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > CSeq: 3 > > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D133= 9949552 > > Range: npt=3D0- > > Session: 12345678 > >=20 > > ... now request TCP ... > >=20 > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 4 > > Transport: RTP/AVP/TCP;interleaved=3D0-1 > >=20 > > S->C: RTSP/1.0 200 OK > > Cseq: 4 > > Transport: RTP/AVP/TCP;unicast; > > client_ip=3D;interleaved=3D0-1 > > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D > > Range: npt=3D0-10.56600 > > Session: 12345678 > >=20 > >=20 > >=20 > > 6.3 TCP -> UDP > >=20 > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > > CSeq: 1 > >=20 > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > Content-Length: 230 > > Content-Type: application/sdp > > Cseq: 1 > >=20 > > v=3D0 > > o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 > > s=3DRTSP Session > > c=3DIN IP4 0.0.0.0 > > t=3D0 0 > > a=3Dcontrol:* > > a=3Drange:npt=3D0-10.566000 > > m=3Dvideo 0 RTP/AVP 26 > > a=3Dcontrol:rtsp://foo/twister/video > > m=3Daudio 0 RTP/AVP 0 > > a=3Dcontrol:rtsp://foo/twister/audio > >=20 > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 2 > > Transport: RTP/AVP/TCP;interleaved=3D0-1 > >=20 > > S->C: RTSP/1.0 200 OK > > Cseq: 2 > > Session: 12345678 > > Transport: RTP/AVP/TCP;unicast;client_ip=3D;interleave= d=3D0-1 > >=20 > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > > CSeq: 3 > > Session: 12345678 > >=20 > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > Cseq: 3 > > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D133= 9949552 > > Range: npt=3D0- > > Session: 12345678 > >=20 > > ... now request UDP ... > >=20 > >=20 > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 4 > > Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 > > Range: npt=3D0- > >=20 > > S->C: RTSP/1.0 200 OK > > CSeq: 4 > > Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; > > server_port=3D9000-9001 > > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D > > Range: npt=3D0-10.56600 > > Session: 12345678 > >=20 > >=20 > >=20 > >=20 > > 7. Other transport related changes to RTSP draft > >=20 > > A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to > > transport parameters. > >=20 > > (a) Section 13.40: > > Page 81: Are "src_addr" and "dest_addr" parameters > > going away? If these are relevant for NAT, perhaps they belong in > > the NAT document? > >=20 > > Page 83-83: BNF indicates "client_port" and > > "server_port" will be indicated as 'port1-port2'. This doesn't se= em > > adequate for the case where the RTP and RTCP ports are non-adjace= nt > > (per the new RTP spec rfc 3550).=20 > >=20 > > Proposal: > > client_port: rtp=3D, rtcp=3D > > server_port: rtp=3D, rtcp=3D > >=20 > > (b) Appendix B, B.1.1 > > Page 115: Mentions "src_addresses" and > > "dest_addresses" - what are these? > >=20 > > Page 116: "non-continuous" ports - might want to rephrase to > > "non-adjacent" (or "non-continguous") ports? > >=20 > >=20 > >=20 > > 8. Summary > >=20 > >=20 > > This note recommends negotiation of a few transport parameters and > > specifies mechanisms to do so. One new transport parameter "client_ip= "=20 > > is recommended for use in cases where the client's IP address changes > > during the session.=20 > >=20 > > It is also recommended that the client_port and server_port parameter= s > > be specified further with the use of tags "rtp_port" and "rtcp_port" > > to handle the case where these ports are non-contiguous. --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 4 15:58:21 2003 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 PAA05279 for ; Tue, 4 Nov 2003 15:58: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 1AH8FW-0004HO-Ot for mmusic-archive@odin.ietf.org; Tue, 04 Nov 2003 15:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Kw2hf016444 for mmusic-archive@odin.ietf.org; Tue, 4 Nov 2003 15: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 1AH8FW-0004H9-LT for mmusic-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 15:58: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 PAA05275 for ; Tue, 4 Nov 2003 15:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH8FV-0005CH-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 15:58:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH8FU-0005CE-00 for mmusic-web-archive@ietf.org; Tue, 04 Nov 2003 15:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8FV-0004Gg-Ky; Tue, 04 Nov 2003 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8Eu-0004Fv-7A for mmusic@optimus.ietf.org; Tue, 04 Nov 2003 15:57: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 PAA05268 for ; Tue, 4 Nov 2003 15:57:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH8Es-0005Bu-00 for mmusic@ietf.org; Tue, 04 Nov 2003 15:57:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AH8Es-0005Ao-00 for mmusic@ietf.org; Tue, 04 Nov 2003 15:57:22 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 04 Nov 2003 12:56:51 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA4KtODO007150; Tue, 4 Nov 2003 15:55:26 -0500 (EST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS35843; Tue, 4 Nov 2003 15:55:23 -0500 (EST) Message-ID: <3FA8123B.10901@cisco.com> Date: Tue, 04 Nov 2003 15:55:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" CC: "'Jonathan Rosenberg'" , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] Clarification on use of sendonly for hold References: <50B1CBA96870A34799A506B2313F266761FE6F@ntht201e> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that clarification would be good. The good and the bad of the current scheme is that the directionality of send/recv/sendrecv/inactive doesn't correlate directly to the general notion of "on hold". But there is a general notion of "on hold" even if it isn't very well defined. The problem is that the relationship between going on/off hold to the direction attributes isn't entirely clear, as evidenced by John Elwell's experiences below. Paul Elwell, John wrote: > Jonathan, > > Your reply below, and also the one you sent to Paul Kyzivat, are in line > with how I had interpreted things. However, we have encountered > implementations that offer sendonly on audio but do not supply music. The > problem we then have is whether a UAS should supply its own music. If it > receives inactive, clearly it is at liberty to do so. If it receives > sendonly, I believe it should not supply local music, because there may be > music or some other audio from the far end (although in many cases there is > not). > > Some clarification in RFC3264 would be beneficial. > > John > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 04 November 2003 00:34 >>To: Elwell, John >>Cc: 'mmusic@ietf.org' >>Subject: Re: [MMUSIC] Clarification on use of sendonly for hold >> >> >>To allow for situations where there is muzak or other media placed >>while the call is on hold. That said, there is nothing wrong with >>using inactive if you want, if you have no plans to do that. >> >>-Jonathan R. >> >>Elwell, John wrote: >> >> >>>In section 8.4 of RFC3264 it says: >>> >>>"Typically, when a user "presses" hold, the agent will >> >>generate an offer >> >>>with all streams in the SDP indicating a direction of >> >>sendonly, and it >> >>>will also locally mute, so that no media is sent to the far >> >> end, and no >> >>>media is played out." >>> >>>This seems strange. If the UA is not sending any media to >> >>the far end, >> >>>why not use "inactive" instead of "sendonly"? >>> >>>John Elwell (john.elwell@siemens.com) >>> >> >>-- >>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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 5 03:58:23 2003 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 DAA26560 for ; Wed, 5 Nov 2003 03:58: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 1AHJUK-0001U4-8F for mmusic-archive@odin.ietf.org; Wed, 05 Nov 2003 03:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA58w3cr005698 for mmusic-archive@odin.ietf.org; Wed, 5 Nov 2003 03:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJUJ-0001Tp-Ep for mmusic-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 03:58: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 DAA26535 for ; Wed, 5 Nov 2003 03:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJUG-0007KJ-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 03:58:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHJUG-0007KE-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 03:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJUH-0001T7-SJ; Wed, 05 Nov 2003 03:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJTM-0001R1-3g for mmusic@optimus.ietf.org; Wed, 05 Nov 2003 03:57: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 DAA26434 for ; Wed, 5 Nov 2003 03:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJTJ-0007Hh-00 for mmusic@ietf.org; Wed, 05 Nov 2003 03:57:01 -0500 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 1AHJTH-0007G9-00 for mmusic@ietf.org; Wed, 05 Nov 2003 03:56:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] RTSP transport negotiation Date: Wed, 5 Nov 2003 09:58:15 +0100 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B90949F74810@swing.cefriel.it> Thread-Topic: [MMUSIC] RTSP transport negotiation Thread-Index: AcOi/mBsre9HkcFrScqzusITkZvTogAd6Spw From: "Enrico Balatti" To: "Geetha Srikantan" Cc: 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, comments inline: >a) How does a mobile client get notified about new transports - such as = > a new IP address? How far ahead of time does the client get > notified? In my opinion the notification can be done in two different ways: 1) you have have a mobile client application(like MobileIP, CellularIP = etc..)=20 running on you mobile host. In this case this application can inform = you when the handoff happens (before or after the switching to a new = AccessPoint). and if you have changed your IP address or you are reachable from = outside the new domain via a new Public IP address. =20 2) you have not a mobile client application. You get a new IP address = via DHCP. In this case I think the dhcp client should sends you a trigger to = inform of the change. While the 1) can be a very quickly method, I think that 2) is very = slowly due to the dhcp protocol. >b) What is the range of time over which the transport switch happens? > Consider a scenario where the client requests an IP address change > for example, via SETUP with no Range, and the server starts sending > packets to the new IP. Is there a chance that the buffers at the new > IP get overrun, before the client switches to the new IP? > It would help if the network guarantees that the transport switch > will not lose any packets due to buffer overflows, I think that your assumption that "the SETUP during play state happens = after the client has switched to the new handoff" is right.=20 Its is very common that when a mobile host enters in a new IP domain, it = gets a private IP address or if it use a mobile protocols application, this = protocol allows it to maintain its "home address". In both these case the mobile host = will be reachable from the "internet" via a Public IP address (NAT). So, in the case of = rtsp, the mobile client in a play state has to know the new Public IP address an rtp ports (for = example using the stun protocol),=20 create the binding on the NAT, and then send the SETUP with the new = "client_ip". Best Regards, ------------------------------------------------------------------ Ing Enrico M. Balatti CEFRIEL - Politecnico di Milano ICT Center of Excellence For Research, Innovation, Education & industrial Labs partnership via Fucini 2, 20133 Milano (ITALY) voice: +39 0223954327 fax: +39 0223954527 e-mail: balatti@cefriel.it www.cefriel.it = =20 ------------------------------------------------------------------ -----Original Message----- From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] Sent: marted=EC 4 novembre 2003 19.05 To: Magnus Westerlund Cc: Enrico Balatti; mmusic@ietf.org Subject: Re: [MMUSIC] RTSP transport negotiation hi Magnus, My assumption was that SETUP during play happens *after* the client has switched to the new transport..synchronization is an issue in this case. I agree that if we can assume that the client requests new transport before switching to the new transport, there is probably no synchronization issue. I have two follow-up questions on this: a) How does a mobile client get notified about new transports - such as=20 a new IP address? How far ahead of time does the client get notified? b) What is the range of time over which the transport switch happens? Consider a scenario where the client requests an IP address change for example, via SETUP with no Range, and the server starts sending packets to the new IP. Is there a chance that the buffers at the new IP get overrun, before the client switches to the new IP? It would help if the network guarantees that the transport switch will not lose any packets due to buffer overflows, =20 thanks geetha =20 On Mon, 2003-11-03 at 02:30, Magnus Westerlund wrote: > Hi, >=20 > In this matter, are there really a need to included a Range header to=20 > indicate when the SETUP request is to change parameters? What is the = use=20 > case for this. You can't send the SETUP to move to the new transport=20 > prior to that the new transport interface exist. Therefore I don't see = a=20 > problem with having it change parameters as soon as the request is=20 > received. Unless you have transport interfaces that remain available=20 > during some overlapping time you will of course have a result of = losing=20 > packets during the switch. >=20 > Regarding the use of Range header in the SETUP. If appropriately=20 > motivated it can of course be changed. However the potential backwards = > compatibility problems needs to be considered. If this work becomes=20 > large in impact, we might have to consider splitting it into a = separate=20 > document. However so far I don't think there are sufficient need. >=20 > I am sorry that I haven't had time to properly review your proposal. >=20 > Cheers >=20 > Magnus --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 5 06:24:20 2003 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 GAA00920 for ; Wed, 5 Nov 2003 06:24:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLlb-0001Zm-R2 for mmusic-archive@odin.ietf.org; Wed, 05 Nov 2003 06:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5BO3Sn006054 for mmusic-archive@odin.ietf.org; Wed, 5 Nov 2003 06:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLlb-0001ZZ-NO for mmusic-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 06:24: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 GAA00904 for ; Wed, 5 Nov 2003 06:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLlX-0001Xd-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 06:23:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHLlX-0001Xa-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 06:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLlZ-0001Z1-7j; Wed, 05 Nov 2003 06:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLlW-0001Yn-Dj for mmusic@optimus.ietf.org; Wed, 05 Nov 2003 06:23: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 GAA00896 for ; Wed, 5 Nov 2003 06:23:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLlS-0001XQ-00 for mmusic@ietf.org; Wed, 05 Nov 2003 06:23:54 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AHLlR-0001XL-00 for mmusic@ietf.org; Wed, 05 Nov 2003 06:23:53 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA5BNgSs004884; Wed, 5 Nov 2003 12:23:43 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6M23NJC; Wed, 5 Nov 2003 12:23:42 +0100 Message-ID: <3FA8DDB4.5090700@ericsson.com> Date: Wed, 05 Nov 2003 12:23:32 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP transport negotiation References: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> <1067625819.5805.48.camel@jamba> <3FA62E59.9040407@ericsson.com> <1067969103.8724.18.camel@jamba> In-Reply-To: <1067969103.8724.18.camel@jamba> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, Thanks for your views. Comments inline Geetha Srikantan wrote: > hi Magnus, > > My assumption was that SETUP during play happens *after* the client has > switched to the new transport..synchronization is an issue in this case. > I agree that if we can assume that the client requests new transport > before switching to the new transport, there is probably no > synchronization issue. I have two follow-up questions on this: > Yes, I would also think that in most cases the application will not know about the change of transport until it actually happens. This will probably result in the loss of some media packets. This loss can be dealt with in a few different way depending on the what the application can use: media level retransmission, RTSP go back through PAUSE and PLAY. However in regards the question about what your assumption are and why you need Range in the request I think your answer clearly points out that there are no need for Range in the Request. There seem to be reasons for it to be allowed in the Response, to indicate the correct new synchronization after the change of address. So are you still seeing any need for Range in the SETUP request? If that can be motivated I definitely think there will be possibility to change the specification to allow for this. However this would need further investigation. > a) How does a mobile client get notified about new transports - such as > a new IP address? How far ahead of time does the client get > notified? I would say that this is not a question we can answer. I think we simply need to ensure that the solution works with both sufficient notification and without. However without overlap in transport availability, there will be losses of media packets. > > b) What is the range of time over which the transport switch happens? > Consider a scenario where the client requests an IP address change > for example, via SETUP with no Range, and the server starts sending > packets to the new IP. Is there a chance that the buffers at the new > IP get overrun, before the client switches to the new IP? > It would help if the network guarantees that the transport switch > will not lose any packets due to buffer overflows, > As I have stated prior I think we must require the client to have access to an interface it sends traffic to. If there is overlap I would assume that it can receive data on both during this period. I don't find it reasonable to get any guarantees from the networks. I would assume that any switch of network depends on the change of access technology, for example by switching from cable to WLAN or to 3G mobile network. The probability that there will exist any mobility functionality between these networks seems very small. I think that we should design our solution to allow the mobility, only note that it may loss some packets Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 5 13:36:21 2003 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 NAA16308 for ; Wed, 5 Nov 2003 13:36: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 1AHSVe-0002jk-PT for mmusic-archive@odin.ietf.org; Wed, 05 Nov 2003 13:36:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ia2nq010519 for mmusic-archive@odin.ietf.org; Wed, 5 Nov 2003 13:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSVe-0002ja-M9 for mmusic-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:36: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 NAA16288 for ; Wed, 5 Nov 2003 13:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSVc-0000S4-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 13:36:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHSVb-0000S1-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 13:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSVc-0002iy-WF; Wed, 05 Nov 2003 13:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSUq-0002hv-7B for mmusic@optimus.ietf.org; Wed, 05 Nov 2003 13:35: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 NAA16255; Wed, 5 Nov 2003 13:34:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSUn-0000RJ-00; Wed, 05 Nov 2003 13:35:09 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AHSUn-0000R8-00; Wed, 05 Nov 2003 13:35:09 -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 hA5IYnV2004237; Wed, 5 Nov 2003 19:34:50 +0100 (MET) Message-ID: <3FA9436C.9040205@tzi.uni-bremen.de> Date: Wed, 05 Nov 2003 19:37:32 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: csp@csperkins.org, agenda@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Slightly Updated MMUSIC Agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, attached is a slightly updated MMUSIC agenda. The HTML version with all documents linked is available as usual from http://www.dmn.tzi.org/ietf/mmusic/ Joerg -------------------------------------------------------------------- Multiparty Multimedia Session Control (MMUSIC) CHAIRS: Joerg Ott Colin Perkins Friday, 14 November 2003, 09:00 - 11:30 --------------------------------------- 0900 Agenda Bashing and Status Update (Chairs, 15) Recent RFCs draft-ietf-mmusic-sdp4nat-05.txt -> RFC 3605 With RFC editor draft-ietf-mmusic-sdpng-trans-04.txt With IESG draft-ietf-mmusic-sdp-new-15.txt draft-rajeshkumar-mmusic-gpmd-03.txt With AD draft-ietf-mmusic-sdp-comedia-05.txt draft-ietf-mmusic-sdp-bwparam-05.txt draft-ietf-mmusic-srcfilter-05.txt Misc Updates draft-ietf-mmusic-kmgmt-ext-09.txt draft-ietf-mmusic-sdp-implem-00.txt draft-ietf-mmusic-sdp-new-15.txt 0915 Internet Media Guides (Manyfolks, 30) draft-ietf-mmusic-img-req-00.txt draft-nomura-mmusic-img-framework-02.txt (draft-luoma-mmusic-img-metadata-02.txt fyi only) (draft-luoma-mmusic-img-muppet-03.txt fyi only) 0945 SDP for alternate IP versions (Camarillo, 10) draft-camarillo-mmusic-alt-02.txt 0955 SDP Security Descriptions for Media Streams (Andreasen, 15) draft-ietf-mmusic-sdescriptions-02.txt draft-andreasen-mmusic-securityprecondition-00.txt 0945 SDP for alternate IP versions (Camarillo, 10) draft-camarillo-mmusic-alt-02.txt 0955 SDP Security Descriptions for Media Streams (Andreasen, 15) draft-ietf-mmusic-sdescriptions-02.txt draft-andreasen-mmusic-securityprecondition-00.txt 1010 SDP parameters to support H.263/H.261 options (Even/Ismail, 15) draft-even-avt-h263-h261-options-00.txt draft-nismail-mmusic-sdp-video-00.txt 1025 Interactive Connectivity Establishment (ICE) (Rosenberg, 20) draft-ietf-mmusic-ice-00.txt draft-rosenberg-sipping-ice-01.txt 1045 SDPng Update (Kutscher, 15) draft-ietf-mmusic-sdpng-07.txt 1100 RTSP Update (Westerlund/Zeng, 30) draft-ietf-mmusic-rfc2326bis-05.txt draft-ietf-mmusic-rtsp-nat-01.txt draft-zeng-rtsp-end-of-stream-00.txt 1130 Close ----------------------------------------------------------------------------- NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 5 13:38:21 2003 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 NAA16370 for ; Wed, 5 Nov 2003 13:38: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 1AHSXb-00036b-8h for mmusic-archive@odin.ietf.org; Wed, 05 Nov 2003 13:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ic32F011931 for mmusic-archive@odin.ietf.org; Wed, 5 Nov 2003 13:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSXb-00036M-25 for mmusic-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:38: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 NAA16357 for ; Wed, 5 Nov 2003 13:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSXY-0000TM-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 13:38:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHSXY-0000TJ-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 13:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSXZ-00035S-JZ; Wed, 05 Nov 2003 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 1AHSXJ-00031m-6V for mmusic@optimus.ietf.org; Wed, 05 Nov 2003 13:37: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 NAA16351 for ; Wed, 5 Nov 2003 13:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSXG-0000TA-00 for mmusic@ietf.org; Wed, 05 Nov 2003 13:37:42 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AHSXG-0000Sx-00 for mmusic@ietf.org; Wed, 05 Nov 2003 13:37:42 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hA5IbAUT028620 for ; Wed, 5 Nov 2003 10:37:11 -0800 (PST) Received: from jamba (jamba.Eng.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 <0HNW006PX6DYLN@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Wed, 05 Nov 2003 10:37:10 -0800 (PST) Date: Wed, 05 Nov 2003 10:37:33 -0800 From: Geetha Srikantan Subject: RE: [MMUSIC] RTSP transport negotiation In-reply-to: <6F5FB8313FE82C4EA10DA4DA40B90949F74810@swing.cefriel.it> To: Enrico Balatti Cc: mmusic@ietf.org Message-id: <1068057452.890.19.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain; charset=ISO-8859-1 References: <6F5FB8313FE82C4EA10DA4DA40B90949F74810@swing.cefriel.it> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nwkea-mail-1.sun.com id hA5IbAUT028620 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Enrico, Thanks for the background..this helps to understand the scenario better. geetha On Wed, 2003-11-05 at 00:58, Enrico Balatti wrote: > Hi, >=20 > comments inline: >=20 > >a) How does a mobile client get notified about new transports - such a= s=20 > > a new IP address? How far ahead of time does the client get > > notified? >=20 > In my opinion the notification can be done in two different ways: >=20 > 1) you have have a mobile client application(like MobileIP, CellularIP = etc..)=20 > running on you mobile host. In this case this application can inform= you when > the handoff happens (before or after the switching to a new AccessPo= int). > and if you have changed your IP address or you are reachable from ou= tside the new domain > via a new Public IP address. > =20 > 2) you have not a mobile client application. You get a new IP address v= ia DHCP. > In this case I think the dhcp client should sends you a trigger to i= nform of the change. >=20 > While the 1) can be a very quickly method, I think that 2) is very slow= ly due to the dhcp protocol. >=20 > >b) What is the range of time over which the transport switch happens? > > Consider a scenario where the client requests an IP address change > > for example, via SETUP with no Range, and the server starts sending > > packets to the new IP. Is there a chance that the buffers at the ne= w > > IP get overrun, before the client switches to the new IP? > > It would help if the network guarantees that the transport switch > > will not lose any packets due to buffer overflows, >=20 > I think that your assumption that "the SETUP during play state happens = after > the client has switched to the new handoff" is right.=20 > Its is very common that when a mobile host enters in a new IP domain, i= t gets > a private IP address or if it use a mobile protocols application, this = protocol allows > it to maintain its "home address". In both these case the mobile host w= ill be reachable > from the "internet" via a Public IP address (NAT). So, in the case of r= tsp, the mobile client > in a play state has to know the new Public IP address an rtp ports (for= example using the stun protocol),=20 > create the binding on the NAT, and then send the SETUP with the new "cl= ient_ip". >=20 > Best Regards, >=20 > ------------------------------------------------------------------ > Ing Enrico M. Balatti > CEFRIEL - Politecnico di Milano > ICT Center of Excellence For Research, Innovation, > Education & industrial Labs partnership > via Fucini 2, 20133 Milano (ITALY) > voice: +39 0223954327 fax: +39 0223954527 > e-mail: balatti@cefriel.it www.cefriel.it= =20 > ------------------------------------------------------------------ >=20 >=20 > -----Original Message----- > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > Sent: marted=EC 4 novembre 2003 19.05 > To: Magnus Westerlund > Cc: Enrico Balatti; mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP transport negotiation >=20 >=20 > hi Magnus, >=20 > My assumption was that SETUP during play happens *after* the client has > switched to the new transport..synchronization is an issue in this case. > I agree that if we can assume that the client requests new transport > before switching to the new transport, there is probably no > synchronization issue. I have two follow-up questions on this: >=20 > a) How does a mobile client get notified about new transports - such as= =20 > a new IP address? How far ahead of time does the client get > notified? >=20 > b) What is the range of time over which the transport switch happens? > Consider a scenario where the client requests an IP address change > for example, via SETUP with no Range, and the server starts sending > packets to the new IP. Is there a chance that the buffers at the new > IP get overrun, before the client switches to the new IP? > It would help if the network guarantees that the transport switch > will not lose any packets due to buffer overflows, > =20 > thanks > geetha =20 >=20 >=20 >=20 > On Mon, 2003-11-03 at 02:30, Magnus Westerlund wrote: > > Hi, > >=20 > > In this matter, are there really a need to included a Range header to= =20 > > indicate when the SETUP request is to change parameters? What is the = use=20 > > case for this. You can't send the SETUP to move to the new transport=20 > > prior to that the new transport interface exist. Therefore I don't se= e a=20 > > problem with having it change parameters as soon as the request is=20 > > received. Unless you have transport interfaces that remain available=20 > > during some overlapping time you will of course have a result of losi= ng=20 > > packets during the switch. > >=20 > > Regarding the use of Range header in the SETUP. If appropriately=20 > > motivated it can of course be changed. However the potential backward= s=20 > > compatibility problems needs to be considered. If this work becomes=20 > > large in impact, we might have to consider splitting it into a separa= te=20 > > document. However so far I don't think there are sufficient need. > >=20 > > I am sorry that I haven't had time to properly review your proposal. > >=20 > > Cheers > >=20 > > Magnus --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 5 13:56:23 2003 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 NAA17056 for ; Wed, 5 Nov 2003 13:56: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 1AHSp2-0004PD-UK for mmusic-archive@odin.ietf.org; Wed, 05 Nov 2003 13:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Iu40w016929 for mmusic-archive@odin.ietf.org; Wed, 5 Nov 2003 13:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSp2-0004Oy-Qi for mmusic-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:56: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 NAA17015 for ; Wed, 5 Nov 2003 13:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSp0-0000l3-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 13:56:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHSp0-0000l0-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 13:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSp1-0004OL-53; Wed, 05 Nov 2003 13:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSo1-0004Li-Eh for mmusic@optimus.ietf.org; Wed, 05 Nov 2003 13:55: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 NAA16965 for ; Wed, 5 Nov 2003 13:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSnz-0000jo-00 for mmusic@ietf.org; Wed, 05 Nov 2003 13:54:59 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AHSny-0000it-00 for mmusic@ietf.org; Wed, 05 Nov 2003 13:54:58 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hA5IsRUT007804 for ; Wed, 5 Nov 2003 10:54:28 -0800 (PST) Received: from jamba (jamba.Eng.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 <0HNW006CT76RLN@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Wed, 05 Nov 2003 10:54:27 -0800 (PST) Date: Wed, 05 Nov 2003 10:54:51 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] RTSP transport negotiation In-reply-to: <3FA8DDB4.5090700@ericsson.com> To: Magnus Westerlund Cc: Enrico Balatti , mmusic@ietf.org Message-id: <1068058490.890.36.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit References: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> <1067625819.5805.48.camel@jamba> <3FA62E59.9040407@ericsson.com> <1067969103.8724.18.camel@jamba> <3FA8DDB4.5090700@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 Magnus, Yes, it looks like we can drop the Range header from SETUP request. We probably want the Range header + RTP-Info in the SETUP response for VOD streams...with the caveat that packets can be lost during the switch. I don't believe all components of the RTP-Info header are relevant for live streams that are 'reflected' by the server - here the server acts as a translator. The RTP stream url is known, however the exact sequence number and timestamp for RTP packets is determined by the source of the live stream, not the server reflecting the stream. Hence, I recommend that the RTP-Info carry no sequence number or rtptime for live streams. Also, I noticed that the RTP spec requires change of SSRC when the transport changes. This needs to be added to the transport negotiation notes. I will update the notes and send it to the alias. geetha On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: > Hi Geetha, > > Thanks for your views. Comments inline > > Geetha Srikantan wrote: > > hi Magnus, > > > > My assumption was that SETUP during play happens *after* the client has > > switched to the new transport..synchronization is an issue in this case. > > I agree that if we can assume that the client requests new transport > > before switching to the new transport, there is probably no > > synchronization issue. I have two follow-up questions on this: > > > > Yes, I would also think that in most cases the application will not know > about the change of transport until it actually happens. This will > probably result in the loss of some media packets. This loss can be > dealt with in a few different way depending on the what the application > can use: media level retransmission, RTSP go back through PAUSE and PLAY. > > However in regards the question about what your assumption are and why > you need Range in the request I think your answer clearly points out > that there are no need for Range in the Request. There seem to be > reasons for it to be allowed in the Response, to indicate the correct > new synchronization after the change of address. > > So are you still seeing any need for Range in the SETUP request? If that > can be motivated I definitely think there will be possibility to change > the specification to allow for this. However this would need further > investigation. > > > > a) How does a mobile client get notified about new transports - such as > > a new IP address? How far ahead of time does the client get > > notified? > > I would say that this is not a question we can answer. I think we simply > need to ensure that the solution works with both sufficient notification > and without. However without overlap in transport availability, there > will be losses of media packets. > > > > > > b) What is the range of time over which the transport switch happens? > > Consider a scenario where the client requests an IP address change > > for example, via SETUP with no Range, and the server starts sending > > packets to the new IP. Is there a chance that the buffers at the new > > IP get overrun, before the client switches to the new IP? > > It would help if the network guarantees that the transport switch > > will not lose any packets due to buffer overflows, > > > > As I have stated prior I think we must require the client to have access > to an interface it sends traffic to. If there is overlap I would assume > that it can receive data on both during this period. I don't find it > reasonable to get any guarantees from the networks. I would assume that > any switch of network depends on the change of access technology, for > example by switching from cable to WLAN or to 3G mobile network. The > probability that there will exist any mobility functionality between > these networks seems very small. > > I think that we should design our solution to allow the mobility, only > note that it may loss some packets > > Cheers > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 5 14:54:33 2003 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 OAA20392 for ; Wed, 5 Nov 2003 14:54:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTjJ-00011G-VE for mmusic-archive@odin.ietf.org; Wed, 05 Nov 2003 14:54:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JsDhM003917 for mmusic-archive@odin.ietf.org; Wed, 5 Nov 2003 14:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTjJ-000116-RO for mmusic-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:54: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 OAA20329 for ; Wed, 5 Nov 2003 14:54:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTjG-0001zx-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 14:54:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTjG-0001zu-00 for mmusic-web-archive@ietf.org; Wed, 05 Nov 2003 14:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTj9-0000yP-I2; Wed, 05 Nov 2003 14:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTj2-0000nZ-Ry for mmusic@optimus.ietf.org; Wed, 05 Nov 2003 14:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20318 for ; Wed, 5 Nov 2003 14:53:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTj0-0001zb-00 for mmusic@ietf.org; Wed, 05 Nov 2003 14:53:54 -0500 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTiz-0001ym-00 for mmusic@ietf.org; Wed, 05 Nov 2003 14:53:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Nov 2003 11:53:18 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD65411C8@bels002.mediator.com> Thread-Topic: [MMUSIC] RTSP transport negotiation Thread-Index: AcOjzn77m9atFsK4SyaUKFrg6HotVgABrMVQ From: "Gamze Seckin" To: Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] sdp alt, alt-default-id and alt-group 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 Dear mmusic members, my apologies if this is discussed here before: I am looking for ietf pointers (if there are any) on the sdp = descriptions provided in = http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document = s4-30680. on sdp "alt" and "alt-default-id" attributes and the session level = grouping attribute, "alt-group". best regards g ----------------------------------------------------------- Gamze Seckin, Ph.D. Director of Research Vidiator Technology (US) Inc. 411 108th Avenue NE. Suite 688 Bellevue, WA 98004 USA. www.vidiator.com Phone: 1.425.688.8811x2108 Email: gamze@vidiator.com This e-mail message (including any attachment) is intended only for the = personal use of the recipient(s) named above. This message is = confidential and may be legally privileged. If you are not an intended = recipient, you may not review, copy or distribute this message. If you = have received this communication in error, please notify us immediately = by e-mail and delete the original message. Any views or opinions = expressed in this message are those of the author only. Furthermore, = this message including any attachment does not create any legally = binding rights or obligations whatsoever, which may only be created by = the exchange of hard copy documents signed by a duly authorized = representative of Vidiator Technology (US) Inc. ----------------------------------------------------------- -----Original Message----- From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] Sent: Wednesday, November 05, 2003 10:55 AM To: Magnus Westerlund Cc: Enrico Balatti; mmusic@ietf.org Subject: Re: [MMUSIC] RTSP transport negotiation hi Magnus, Yes, it looks like we can drop the Range header from SETUP request. We probably want the Range header + RTP-Info in the SETUP response for VOD streams...with the caveat that packets can be lost during the switch.=20 I don't believe all components of the RTP-Info header are relevant for live streams that are 'reflected' by the server - here the server acts as a translator. The RTP stream url is known, however the exact sequence number and timestamp for RTP packets is determined by the source of the live stream, not the server reflecting the stream. Hence, I recommend that the RTP-Info carry no sequence number or rtptime for live streams. Also, I noticed that the RTP spec requires change of SSRC when the transport changes. This needs to be added to the transport negotiation=20 notes. I will update the notes and send it to the alias. geetha On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: > Hi Geetha, >=20 > Thanks for your views. Comments inline >=20 > Geetha Srikantan wrote: > > hi Magnus, > >=20 > > My assumption was that SETUP during play happens *after* the client = has > > switched to the new transport..synchronization is an issue in this = case. > > I agree that if we can assume that the client requests new transport > > before switching to the new transport, there is probably no > > synchronization issue. I have two follow-up questions on this: > >=20 >=20 > Yes, I would also think that in most cases the application will not = know=20 > about the change of transport until it actually happens. This will=20 > probably result in the loss of some media packets. This loss can be=20 > dealt with in a few different way depending on the what the = application=20 > can use: media level retransmission, RTSP go back through PAUSE and = PLAY. >=20 > However in regards the question about what your assumption are and why = > you need Range in the request I think your answer clearly points out=20 > that there are no need for Range in the Request. There seem to be=20 > reasons for it to be allowed in the Response, to indicate the correct=20 > new synchronization after the change of address. >=20 > So are you still seeing any need for Range in the SETUP request? If = that=20 > can be motivated I definitely think there will be possibility to = change=20 > the specification to allow for this. However this would need further=20 > investigation. >=20 >=20 > > a) How does a mobile client get notified about new transports - such = as=20 > > a new IP address? How far ahead of time does the client get > > notified? >=20 > I would say that this is not a question we can answer. I think we = simply=20 > need to ensure that the solution works with both sufficient = notification=20 > and without. However without overlap in transport availability, there=20 > will be losses of media packets. >=20 >=20 > >=20 > > b) What is the range of time over which the transport switch = happens? > > Consider a scenario where the client requests an IP address = change > > for example, via SETUP with no Range, and the server starts = sending > > packets to the new IP. Is there a chance that the buffers at the = new > > IP get overrun, before the client switches to the new IP? > > It would help if the network guarantees that the transport switch > > will not lose any packets due to buffer overflows, > > =20 >=20 > As I have stated prior I think we must require the client to have = access=20 > to an interface it sends traffic to. If there is overlap I would = assume=20 > that it can receive data on both during this period. I don't find it=20 > reasonable to get any guarantees from the networks. I would assume = that=20 > any switch of network depends on the change of access technology, for=20 > example by switching from cable to WLAN or to 3G mobile network. The=20 > probability that there will exist any mobility functionality between=20 > these networks seems very small. >=20 > I think that we should design our solution to allow the mobility, only = > note that it may loss some packets >=20 > Cheers >=20 >=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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 6 14:30:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24706 for ; Thu, 6 Nov 2003 14:30: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 1AHppq-0004Zy-2h for mmusic-archive@odin.ietf.org; Thu, 06 Nov 2003 14:30:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6JUPan017588 for mmusic-archive@odin.ietf.org; Thu, 6 Nov 2003 14:30:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHppp-0004ZP-If for mmusic-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 14:30: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 OAA24588 for ; Thu, 6 Nov 2003 14:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHppm-0006Pp-00 for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 14:30:22 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHpeh-0006BO-00 for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 14:18:55 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHpYA-00005L-2G for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 14:12:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpY1-0002lZ-Jd; Thu, 06 Nov 2003 14: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 1AHpXi-0002l8-G3 for mmusic@optimus.ietf.org; Thu, 06 Nov 2003 14:11: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 OAA23571 for ; Thu, 6 Nov 2003 14:11:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpXf-00065j-00 for mmusic@ietf.org; Thu, 06 Nov 2003 14:11:39 -0500 Received: from [209.20.232.72] (helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AHpXf-00065V-00 for mmusic@ietf.org; Thu, 06 Nov 2003 14:11:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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] sdp alt, alt-default-id and alt-group Date: Thu, 6 Nov 2003 11:11:07 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD65411DA@bels002.mediator.com> Thread-Topic: [MMUSIC] sdp alt, alt-default-id and alt-group Thread-Index: AcOklVdCNoiLrB6kRSW2swUJNDQ8gAAA5R9g From: "Gamze Seckin" To: "Magnus Westerlund" Cc: 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus, Thanks. I do not see bugs and I think this proposal could be useful = actually. But I also think it is important that IETF takes into account these = sections somehow, since they may have an impact on several proposals, = say such as transport independent bw modifiers? br g -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Thursday, November 06, 2003 10:34 AM To: Gamze Seckin Cc: mmusic@ietf.org Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group Hi Gamze, No there are no IETF pointers about this proposal. This work is totally=20 created within the 3GPP SA4. There should probably have been some review = by the IETF before the acceptance of the proposal, but that has not=20 happened. However as the Release 6 has not been approved yet, any bugs=20 in this proposal can still be fixed. If you are interested in this proposal please review chapter 5.3.3.3.=20 and 5.3.3.4 in the 3GPP TS 26.234 version 0.3.0 of Release 6=20 specification, which can be downloaded here: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/S4-030680.zip This is a 200 kb zipped word document. Cheers Magnus Gamze Seckin wrote: > Dear mmusic members, >=20 > my apologies if this is discussed here before: >=20 > I am looking for ietf pointers (if there are any) on the sdp = descriptions provided in = http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document = s4-30680. > on sdp "alt" and "alt-default-id" attributes and the session level = grouping attribute, "alt-group". >=20 > best regards > g >=20 >=20 >=20 > ----------------------------------------------------------- > Gamze Seckin, Ph.D. > Director of Research > Vidiator Technology (US) Inc. > 411 108th Avenue NE. Suite 688 > Bellevue, WA 98004 USA. > www.vidiator.com >=20 > Phone: 1.425.688.8811x2108 > Email: gamze@vidiator.com >=20 > This e-mail message (including any attachment) is intended only for = the personal use of the recipient(s) named above. This message is = confidential and may be legally privileged. If you are not an intended = recipient, you may not review, copy or distribute this message. If you = have received this communication in error, please notify us immediately = by e-mail and delete the original message. Any views or opinions = expressed in this message are those of the author only. Furthermore, = this message including any attachment does not create any legally = binding rights or obligations whatsoever, which may only be created by = the exchange of hard copy documents signed by a duly authorized = representative of Vidiator Technology (US) Inc. > ----------------------------------------------------------- >=20 >=20 > -----Original Message----- > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > Sent: Wednesday, November 05, 2003 10:55 AM > To: Magnus Westerlund > Cc: Enrico Balatti; mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP transport negotiation >=20 >=20 >=20 > hi Magnus, >=20 > Yes, it looks like we can drop the Range header from SETUP request. > We probably want the Range header + RTP-Info in the SETUP response > for VOD streams...with the caveat that packets can be lost during the > switch.=20 >=20 > I don't believe all components of the RTP-Info header are relevant for > live streams that are 'reflected' by the server - here the server acts > as a translator. The RTP stream url is known, however the exact = sequence > number and timestamp for RTP packets is determined by the source of = the > live stream, not the server reflecting the stream. Hence, I recommend > that the RTP-Info carry no sequence number or rtptime for live = streams. >=20 > Also, I noticed that the RTP spec requires change of SSRC when the > transport changes. This needs to be added to the transport negotiation = > notes. >=20 > I will update the notes and send it to the alias. >=20 > geetha >=20 >=20 > On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: >=20 >>Hi Geetha, >> >>Thanks for your views. Comments inline >> >>Geetha Srikantan wrote: >> >>>hi Magnus, >>> >>>My assumption was that SETUP during play happens *after* the client = has >>>switched to the new transport..synchronization is an issue in this = case. >>>I agree that if we can assume that the client requests new transport >>>before switching to the new transport, there is probably no >>>synchronization issue. I have two follow-up questions on this: >>> >> >>Yes, I would also think that in most cases the application will not = know=20 >>about the change of transport until it actually happens. This will=20 >>probably result in the loss of some media packets. This loss can be=20 >>dealt with in a few different way depending on the what the = application=20 >>can use: media level retransmission, RTSP go back through PAUSE and = PLAY. >> >>However in regards the question about what your assumption are and why = >>you need Range in the request I think your answer clearly points out=20 >>that there are no need for Range in the Request. There seem to be=20 >>reasons for it to be allowed in the Response, to indicate the correct=20 >>new synchronization after the change of address. >> >>So are you still seeing any need for Range in the SETUP request? If = that=20 >>can be motivated I definitely think there will be possibility to = change=20 >>the specification to allow for this. However this would need further=20 >>investigation. >> >> >> >>>a) How does a mobile client get notified about new transports - such = as=20 >>> a new IP address? How far ahead of time does the client get >>> notified? >> >>I would say that this is not a question we can answer. I think we = simply=20 >>need to ensure that the solution works with both sufficient = notification=20 >>and without. However without overlap in transport availability, there=20 >>will be losses of media packets. >> >> >> >>>b) What is the range of time over which the transport switch happens? >>> Consider a scenario where the client requests an IP address change >>> for example, via SETUP with no Range, and the server starts = sending >>> packets to the new IP. Is there a chance that the buffers at the = new >>> IP get overrun, before the client switches to the new IP? >>> It would help if the network guarantees that the transport switch >>> will not lose any packets due to buffer overflows, >>> =20 >> >>As I have stated prior I think we must require the client to have = access=20 >>to an interface it sends traffic to. If there is overlap I would = assume=20 >>that it can receive data on both during this period. I don't find it=20 >>reasonable to get any guarantees from the networks. I would assume = that=20 >>any switch of network depends on the change of access technology, for=20 >>example by switching from cable to WLAN or to 3G mobile network. The=20 >>probability that there will exist any mobility functionality between=20 >>these networks seems very small. >> >>I think that we should design our solution to allow the mobility, only = >>note that it may loss some packets >> >>Cheers >> >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 6 14:57:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25981 for ; Thu, 6 Nov 2003 14:57: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 1AHqFb-0006cS-Qi for mmusic-archive@odin.ietf.org; Thu, 06 Nov 2003 14:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Jv3aG025438 for mmusic-archive@odin.ietf.org; Thu, 6 Nov 2003 14:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqFb-0006c8-Gq for mmusic-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 14:57: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 OAA25946 for ; Thu, 6 Nov 2003 14:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHqFY-0006uV-00 for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 14:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHqFX-0006uP-00 for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 14:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqFZ-0006ac-Df; Thu, 06 Nov 2003 14:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqFB-0006Zd-4K for mmusic@optimus.ietf.org; Thu, 06 Nov 2003 14:56: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 OAA25902 for ; Thu, 6 Nov 2003 14:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHqF8-0006th-00 for mmusic@ietf.org; Thu, 06 Nov 2003 14:56:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AHqF6-0006t3-00 for mmusic@ietf.org; Thu, 06 Nov 2003 14:56:33 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA6Jtgca013155; Thu, 6 Nov 2003 14:55:48 -0500 (EST) Message-ID: <3FAAA73B.3000700@dynamicsoft.com> Date: Thu, 06 Nov 2003 14:55:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gamze Seckin CC: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group References: <787ED0EC136B854DB341E7662D666CD65411DA@bels002.mediator.com> In-Reply-To: <787ED0EC136B854DB341E7662D666CD65411DA@bels002.mediator.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, I've not seen the 3gpp docs, but there is an alt SDP parameter defined in ICE: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt Is this the same as what is being used by 3gpp? If not, we have a serious name collision... -Jonathan R. Gamze Seckin wrote: > Hi Magnus, > > Thanks. I do not see bugs and I think this proposal could be useful actually. > But I also think it is important that IETF takes into account these sections somehow, since they may have an impact on several proposals, say such as transport independent bw modifiers? > > br > g > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, November 06, 2003 10:34 AM > To: Gamze Seckin > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group > > > Hi Gamze, > > No there are no IETF pointers about this proposal. This work is totally > created within the 3GPP SA4. There should probably have been some review > by the IETF before the acceptance of the proposal, but that has not > happened. However as the Release 6 has not been approved yet, any bugs > in this proposal can still be fixed. > > If you are interested in this proposal please review chapter 5.3.3.3. > and 5.3.3.4 in the 3GPP TS 26.234 version 0.3.0 of Release 6 > specification, which can be downloaded here: > > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/S4-030680.zip > > This is a 200 kb zipped word document. > > Cheers > > Magnus > > Gamze Seckin wrote: > > >>Dear mmusic members, >> >>my apologies if this is discussed here before: >> >>I am looking for ietf pointers (if there are any) on the sdp descriptions provided in http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document s4-30680. >>on sdp "alt" and "alt-default-id" attributes and the session level grouping attribute, "alt-group". >> >>best regards >>g >> >> >> >>----------------------------------------------------------- >>Gamze Seckin, Ph.D. >>Director of Research >>Vidiator Technology (US) Inc. >>411 108th Avenue NE. Suite 688 >>Bellevue, WA 98004 USA. >>www.vidiator.com >> >>Phone: 1.425.688.8811x2108 >>Email: gamze@vidiator.com >> >>This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Any views or opinions expressed in this message are those of the author only. Furthermore, this message including any attachment does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Vidiator Technology (US) Inc. >>----------------------------------------------------------- >> >> >>-----Original Message----- >>From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] >>Sent: Wednesday, November 05, 2003 10:55 AM >>To: Magnus Westerlund >>Cc: Enrico Balatti; mmusic@ietf.org >>Subject: Re: [MMUSIC] RTSP transport negotiation >> >> >> >>hi Magnus, >> >>Yes, it looks like we can drop the Range header from SETUP request. >>We probably want the Range header + RTP-Info in the SETUP response >>for VOD streams...with the caveat that packets can be lost during the >>switch. >> >>I don't believe all components of the RTP-Info header are relevant for >>live streams that are 'reflected' by the server - here the server acts >>as a translator. The RTP stream url is known, however the exact sequence >>number and timestamp for RTP packets is determined by the source of the >>live stream, not the server reflecting the stream. Hence, I recommend >>that the RTP-Info carry no sequence number or rtptime for live streams. >> >>Also, I noticed that the RTP spec requires change of SSRC when the >>transport changes. This needs to be added to the transport negotiation >>notes. >> >>I will update the notes and send it to the alias. >> >>geetha >> >> >>On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: >> >> >>>Hi Geetha, >>> >>>Thanks for your views. Comments inline >>> >>>Geetha Srikantan wrote: >>> >>> >>>>hi Magnus, >>>> >>>>My assumption was that SETUP during play happens *after* the client has >>>>switched to the new transport..synchronization is an issue in this case. >>>>I agree that if we can assume that the client requests new transport >>>>before switching to the new transport, there is probably no >>>>synchronization issue. I have two follow-up questions on this: >>>> >>> >>>Yes, I would also think that in most cases the application will not know >>>about the change of transport until it actually happens. This will >>>probably result in the loss of some media packets. This loss can be >>>dealt with in a few different way depending on the what the application >>>can use: media level retransmission, RTSP go back through PAUSE and PLAY. >>> >>>However in regards the question about what your assumption are and why >>>you need Range in the request I think your answer clearly points out >>>that there are no need for Range in the Request. There seem to be >>>reasons for it to be allowed in the Response, to indicate the correct >>>new synchronization after the change of address. >>> >>>So are you still seeing any need for Range in the SETUP request? If that >>>can be motivated I definitely think there will be possibility to change >>>the specification to allow for this. However this would need further >>>investigation. >>> >>> >>> >>> >>>>a) How does a mobile client get notified about new transports - such as >>>> a new IP address? How far ahead of time does the client get >>>> notified? >>> >>>I would say that this is not a question we can answer. I think we simply >>>need to ensure that the solution works with both sufficient notification >>>and without. However without overlap in transport availability, there >>>will be losses of media packets. >>> >>> >>> >>> >>>>b) What is the range of time over which the transport switch happens? >>>> Consider a scenario where the client requests an IP address change >>>> for example, via SETUP with no Range, and the server starts sending >>>> packets to the new IP. Is there a chance that the buffers at the new >>>> IP get overrun, before the client switches to the new IP? >>>> It would help if the network guarantees that the transport switch >>>> will not lose any packets due to buffer overflows, >>>> >>> >>>As I have stated prior I think we must require the client to have access >>>to an interface it sends traffic to. If there is overlap I would assume >>>that it can receive data on both during this period. I don't find it >>>reasonable to get any guarantees from the networks. I would assume that >>>any switch of network depends on the change of access technology, for >>>example by switching from cable to WLAN or to 3G mobile network. The >>>probability that there will exist any mobility functionality between >>>these networks seems very small. >>> >>>I think that we should design our solution to allow the mobility, only >>>note that it may loss some packets >>> >>>Cheers >>> >>> >>>Magnus Westerlund >>> >>>Multimedia Technologies, Ericsson Research EAB/TVA/A >>>---------------------------------------------------------------------- >>>Ericsson AB | Phone +46 8 4048287 >>>Torshamsgatan 23 | Fax +46 8 7575550 >>>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 6 16:43:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02627 for ; Thu, 6 Nov 2003 16:43: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 1AHruF-0005oG-Uw for mmusic-archive@odin.ietf.org; Thu, 06 Nov 2003 16:43:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Lh7M5022326 for mmusic-archive@odin.ietf.org; Thu, 6 Nov 2003 16:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHruF-0005o1-Pq for mmusic-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:43: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 QAA02615 for ; Thu, 6 Nov 2003 16:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHruD-00014H-00 for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 16:43:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHruD-00014E-00 for mmusic-web-archive@ietf.org; Thu, 06 Nov 2003 16:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHru9-0005mO-MF; Thu, 06 Nov 2003 16: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 1AHrtX-0005lj-Hf for mmusic@optimus.ietf.org; Thu, 06 Nov 2003 16:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02604 for ; Thu, 6 Nov 2003 16:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrtJ-00013h-00 for mmusic@ietf.org; Thu, 06 Nov 2003 16:42:09 -0500 Received: from ip72.usw232.dsl-acs2.sea.iinet.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AHrtI-00013M-00 for mmusic@ietf.org; Thu, 06 Nov 2003 16:42:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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] sdp alt, alt-default-id and alt-group Date: Thu, 6 Nov 2003 13:41:37 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD65411DD@bels002.mediator.com> Thread-Topic: [MMUSIC] sdp alt, alt-default-id and alt-group Thread-Index: AcOkoBbv7UrN6CYxQZKGyfnze62qcwADa/Yg From: "Gamze Seckin" To: "Jonathan Rosenberg" Cc: "Magnus Westerlund" , 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan The "alt" in the ice draft is different than the "alt" in the 3gpp = document. The purpose of the alt, alt-default-id and alt-group definitions in = 26.234 for Rel6 is to define alternate groupings for several streaming = tracks, based on bitrate or language.=20 And it is an efficient method. I believe it should be taken into account = by IETF for further work on sdp related efforts.=20 However I am not sure how to solve the naming overlap. g Gamze Seckin, Ph.D. Vidiator Technology US www.vidiator.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, November 06, 2003 11:56 AM To: Gamze Seckin Cc: Magnus Westerlund; mmusic@ietf.org Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group Well, I've not seen the 3gpp docs, but there is an alt SDP parameter=20 defined in ICE: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt Is this the same as what is being used by 3gpp? If not, we have a=20 serious name collision... -Jonathan R. Gamze Seckin wrote: > Hi Magnus, >=20 > Thanks. I do not see bugs and I think this proposal could be useful = actually. > But I also think it is important that IETF takes into account these = sections somehow, since they may have an impact on several proposals, = say such as transport independent bw modifiers? >=20 > br > g >=20 >=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, November 06, 2003 10:34 AM > To: Gamze Seckin > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group >=20 >=20 > Hi Gamze, >=20 > No there are no IETF pointers about this proposal. This work is = totally=20 > created within the 3GPP SA4. There should probably have been some = review=20 > by the IETF before the acceptance of the proposal, but that has not=20 > happened. However as the Release 6 has not been approved yet, any bugs = > in this proposal can still be fixed. >=20 > If you are interested in this proposal please review chapter 5.3.3.3.=20 > and 5.3.3.4 in the 3GPP TS 26.234 version 0.3.0 of Release 6=20 > specification, which can be downloaded here: >=20 > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/S4-030680.zip >=20 > This is a 200 kb zipped word document. >=20 > Cheers >=20 > Magnus >=20 > Gamze Seckin wrote: >=20 >=20 >>Dear mmusic members, >> >>my apologies if this is discussed here before: >> >>I am looking for ietf pointers (if there are any) on the sdp = descriptions provided in = http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document = s4-30680. >>on sdp "alt" and "alt-default-id" attributes and the session level = grouping attribute, "alt-group". >> >>best regards >>g >> >> >> >>----------------------------------------------------------- >>Gamze Seckin, Ph.D. >>Director of Research >>Vidiator Technology (US) Inc. >>411 108th Avenue NE. Suite 688 >>Bellevue, WA 98004 USA. >>www.vidiator.com >> >>Phone: 1.425.688.8811x2108 >>Email: gamze@vidiator.com >> >>This e-mail message (including any attachment) is intended only for = the personal use of the recipient(s) named above. This message is = confidential and may be legally privileged. If you are not an intended = recipient, you may not review, copy or distribute this message. If you = have received this communication in error, please notify us immediately = by e-mail and delete the original message. Any views or opinions = expressed in this message are those of the author only. Furthermore, = this message including any attachment does not create any legally = binding rights or obligations whatsoever, which may only be created by = the exchange of hard copy documents signed by a duly authorized = representative of Vidiator Technology (US) Inc. >>----------------------------------------------------------- >> >> >>-----Original Message----- >>From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] >>Sent: Wednesday, November 05, 2003 10:55 AM >>To: Magnus Westerlund >>Cc: Enrico Balatti; mmusic@ietf.org >>Subject: Re: [MMUSIC] RTSP transport negotiation >> >> >> >>hi Magnus, >> >>Yes, it looks like we can drop the Range header from SETUP request. >>We probably want the Range header + RTP-Info in the SETUP response >>for VOD streams...with the caveat that packets can be lost during the >>switch.=20 >> >>I don't believe all components of the RTP-Info header are relevant for >>live streams that are 'reflected' by the server - here the server acts >>as a translator. The RTP stream url is known, however the exact = sequence >>number and timestamp for RTP packets is determined by the source of = the >>live stream, not the server reflecting the stream. Hence, I recommend >>that the RTP-Info carry no sequence number or rtptime for live = streams. >> >>Also, I noticed that the RTP spec requires change of SSRC when the >>transport changes. This needs to be added to the transport negotiation = >>notes. >> >>I will update the notes and send it to the alias. >> >>geetha >> >> >>On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: >> >> >>>Hi Geetha, >>> >>>Thanks for your views. Comments inline >>> >>>Geetha Srikantan wrote: >>> >>> >>>>hi Magnus, >>>> >>>>My assumption was that SETUP during play happens *after* the client = has >>>>switched to the new transport..synchronization is an issue in this = case. >>>>I agree that if we can assume that the client requests new transport >>>>before switching to the new transport, there is probably no >>>>synchronization issue. I have two follow-up questions on this: >>>> >>> >>>Yes, I would also think that in most cases the application will not = know=20 >>>about the change of transport until it actually happens. This will=20 >>>probably result in the loss of some media packets. This loss can be=20 >>>dealt with in a few different way depending on the what the = application=20 >>>can use: media level retransmission, RTSP go back through PAUSE and = PLAY. >>> >>>However in regards the question about what your assumption are and = why=20 >>>you need Range in the request I think your answer clearly points out=20 >>>that there are no need for Range in the Request. There seem to be=20 >>>reasons for it to be allowed in the Response, to indicate the correct = >>>new synchronization after the change of address. >>> >>>So are you still seeing any need for Range in the SETUP request? If = that=20 >>>can be motivated I definitely think there will be possibility to = change=20 >>>the specification to allow for this. However this would need further=20 >>>investigation. >>> >>> >>> >>> >>>>a) How does a mobile client get notified about new transports - such = as=20 >>>> a new IP address? How far ahead of time does the client get >>>> notified? >>> >>>I would say that this is not a question we can answer. I think we = simply=20 >>>need to ensure that the solution works with both sufficient = notification=20 >>>and without. However without overlap in transport availability, there = >>>will be losses of media packets. >>> >>> >>> >>> >>>>b) What is the range of time over which the transport switch = happens? >>>> Consider a scenario where the client requests an IP address change >>>> for example, via SETUP with no Range, and the server starts = sending >>>> packets to the new IP. Is there a chance that the buffers at the = new >>>> IP get overrun, before the client switches to the new IP? >>>> It would help if the network guarantees that the transport switch >>>> will not lose any packets due to buffer overflows, >>>> =20 >>> >>>As I have stated prior I think we must require the client to have = access=20 >>>to an interface it sends traffic to. If there is overlap I would = assume=20 >>>that it can receive data on both during this period. I don't find it=20 >>>reasonable to get any guarantees from the networks. I would assume = that=20 >>>any switch of network depends on the change of access technology, for = >>>example by switching from cable to WLAN or to 3G mobile network. The=20 >>>probability that there will exist any mobility functionality between=20 >>>these networks seems very small. >>> >>>I think that we should design our solution to allow the mobility, = only=20 >>>note that it may loss some packets >>> >>>Cheers >>> >>> >>>Magnus Westerlund >>> >>>Multimedia Technologies, Ericsson Research EAB/TVA/A >>>----------------------------------------------------------------------= >>>Ericsson AB | Phone +46 8 4048287 >>>Torshamsgatan 23 | Fax +46 8 7575550 >>>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 --=20 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 Fri Nov 7 00:38:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17645 for ; Fri, 7 Nov 2003 00:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzJv-0005OA-3C for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 00:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA75c7JS020708 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 00:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzJu-0005Nv-Ug for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 00:38:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17642 for ; Fri, 7 Nov 2003 00:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzJs-0006u6-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 00:38:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHzJr-0006u3-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 00:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzJp-0005NK-6S; Fri, 07 Nov 2003 00: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 1AHzJ7-00058s-4D for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 00:37: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 AAA17607 for ; Fri, 7 Nov 2003 00:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzJ4-0006tP-00 for mmusic@ietf.org; Fri, 07 Nov 2003 00:37:14 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AHzJ3-0006tL-00 for mmusic@ietf.org; Fri, 07 Nov 2003 00:37:13 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA6IY5I2002090; Thu, 6 Nov 2003 19:34:05 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6MJGZ78; Thu, 6 Nov 2003 19:34:05 +0100 Message-ID: <3FAA940F.2060706@ericsson.com> Date: Thu, 06 Nov 2003 19:33:51 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gamze Seckin CC: mmusic@ietf.org Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group References: <787ED0EC136B854DB341E7662D666CD65411C8@bels002.mediator.com> In-Reply-To: <787ED0EC136B854DB341E7662D666CD65411C8@bels002.mediator.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Gamze, No there are no IETF pointers about this proposal. This work is totally created within the 3GPP SA4. There should probably have been some review by the IETF before the acceptance of the proposal, but that has not happened. However as the Release 6 has not been approved yet, any bugs in this proposal can still be fixed. If you are interested in this proposal please review chapter 5.3.3.3. and 5.3.3.4 in the 3GPP TS 26.234 version 0.3.0 of Release 6 specification, which can be downloaded here: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/S4-030680.zip This is a 200 kb zipped word document. Cheers Magnus Gamze Seckin wrote: > Dear mmusic members, > > my apologies if this is discussed here before: > > I am looking for ietf pointers (if there are any) on the sdp descriptions provided in http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document s4-30680. > on sdp "alt" and "alt-default-id" attributes and the session level grouping attribute, "alt-group". > > best regards > g > > > > ----------------------------------------------------------- > Gamze Seckin, Ph.D. > Director of Research > Vidiator Technology (US) Inc. > 411 108th Avenue NE. Suite 688 > Bellevue, WA 98004 USA. > www.vidiator.com > > Phone: 1.425.688.8811x2108 > Email: gamze@vidiator.com > > This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Any views or opinions expressed in this message are those of the author only. Furthermore, this message including any attachment does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Vidiator Technology (US) Inc. > ----------------------------------------------------------- > > > -----Original Message----- > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > Sent: Wednesday, November 05, 2003 10:55 AM > To: Magnus Westerlund > Cc: Enrico Balatti; mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP transport negotiation > > > > hi Magnus, > > Yes, it looks like we can drop the Range header from SETUP request. > We probably want the Range header + RTP-Info in the SETUP response > for VOD streams...with the caveat that packets can be lost during the > switch. > > I don't believe all components of the RTP-Info header are relevant for > live streams that are 'reflected' by the server - here the server acts > as a translator. The RTP stream url is known, however the exact sequence > number and timestamp for RTP packets is determined by the source of the > live stream, not the server reflecting the stream. Hence, I recommend > that the RTP-Info carry no sequence number or rtptime for live streams. > > Also, I noticed that the RTP spec requires change of SSRC when the > transport changes. This needs to be added to the transport negotiation > notes. > > I will update the notes and send it to the alias. > > geetha > > > On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: > >>Hi Geetha, >> >>Thanks for your views. Comments inline >> >>Geetha Srikantan wrote: >> >>>hi Magnus, >>> >>>My assumption was that SETUP during play happens *after* the client has >>>switched to the new transport..synchronization is an issue in this case. >>>I agree that if we can assume that the client requests new transport >>>before switching to the new transport, there is probably no >>>synchronization issue. I have two follow-up questions on this: >>> >> >>Yes, I would also think that in most cases the application will not know >>about the change of transport until it actually happens. This will >>probably result in the loss of some media packets. This loss can be >>dealt with in a few different way depending on the what the application >>can use: media level retransmission, RTSP go back through PAUSE and PLAY. >> >>However in regards the question about what your assumption are and why >>you need Range in the request I think your answer clearly points out >>that there are no need for Range in the Request. There seem to be >>reasons for it to be allowed in the Response, to indicate the correct >>new synchronization after the change of address. >> >>So are you still seeing any need for Range in the SETUP request? If that >>can be motivated I definitely think there will be possibility to change >>the specification to allow for this. However this would need further >>investigation. >> >> >> >>>a) How does a mobile client get notified about new transports - such as >>> a new IP address? How far ahead of time does the client get >>> notified? >> >>I would say that this is not a question we can answer. I think we simply >>need to ensure that the solution works with both sufficient notification >>and without. However without overlap in transport availability, there >>will be losses of media packets. >> >> >> >>>b) What is the range of time over which the transport switch happens? >>> Consider a scenario where the client requests an IP address change >>> for example, via SETUP with no Range, and the server starts sending >>> packets to the new IP. Is there a chance that the buffers at the new >>> IP get overrun, before the client switches to the new IP? >>> It would help if the network guarantees that the transport switch >>> will not lose any packets due to buffer overflows, >>> >> >>As I have stated prior I think we must require the client to have access >>to an interface it sends traffic to. If there is overlap I would assume >>that it can receive data on both during this period. I don't find it >>reasonable to get any guarantees from the networks. I would assume that >>any switch of network depends on the change of access technology, for >>example by switching from cable to WLAN or to 3G mobile network. The >>probability that there will exist any mobility functionality between >>these networks seems very small. >> >>I think that we should design our solution to allow the mobility, only >>note that it may loss some packets >> >>Cheers >> >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 7 04:41:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07731 for ; Fri, 7 Nov 2003 04:41:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI37G-0003Q8-95 for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 04:41:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79fFXn013121 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 04:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI37B-0003PS-DJ for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 04:41: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 EAA07693 for ; Fri, 7 Nov 2003 04:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI378-00023P-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 04:41:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI377-00023M-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 04:41:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI378-0003OI-M3; Fri, 07 Nov 2003 04:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI36N-0003H0-NU for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 04:40:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07659 for ; Fri, 7 Nov 2003 04:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI36K-00022W-00 for mmusic@ietf.org; Fri, 07 Nov 2003 04:40:20 -0500 Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx with esmtp (Exim 4.12) id 1AI36J-00021A-00 for mmusic@ietf.org; Fri, 07 Nov 2003 04:40:19 -0500 Received: from oleane ([194.250.212.114]) by smtp5.clb.oleane.net with SMTP id hA79dnpR030780 for ; Fri, 7 Nov 2003 10:39:50 +0100 Message-ID: <01e401c3a513$9c62fb00$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Fri, 7 Nov 2003 10:43:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E1_01C3A51B.FDDC9E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [MMUSIC] WiMAX Summit 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_01E1_01C3A51B.FDDC9E60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Are WiMAX and WiFi complementary (local vs. metropolitan area = networking)?=20 When and how will WiMAX evolve towards mobility?=20 Can WiMAX be considered as a migration path to 4G?=20 How is addressed the interoperability challenge?=20 These questions, among others, will be addressed during the WiMAX = Summit, to be held in Paris on May 25 to 28, 2004.=20 A call for papers has been launched on-line at: http://www.upperside.fr/wimax04/wimax04intro.htm ------=_NextPart_000_01E1_01C3A51B.FDDC9E60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Are WiMAX and WiFi complementary (local vs. = metropolitan=20 area networking)?
When and how will WiMAX evolve towards = mobility?=20
Can WiMAX be considered as a migration path to 4G?
How is = addressed the=20 interoperability challenge?

These questions, among others, will = be=20 addressed during the WiMAX = Summit, to=20 be held in Paris on May 25 to 28, 2004. =

A=20 call for papers has been launched on-line at:
http://www.uppe= rside.fr/wimax04/wimax04intro.htm
------=_NextPart_000_01E1_01C3A51B.FDDC9E60-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 7 06:42:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10957 for ; Fri, 7 Nov 2003 06:42: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 1AI50B-0001QP-QR for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 06:42:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Bg7MJ005474 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 06:42:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI50B-0001QD-Ir for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 06:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10904 for ; Fri, 7 Nov 2003 06:41:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI507-0003Sd-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 06:42:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI506-0003Sa-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 06:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI504-0001PP-KI; Fri, 07 Nov 2003 06: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 1AI4zP-0001Ib-Iy for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 06:41: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 GAA10880 for ; Fri, 7 Nov 2003 06:41:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI4zL-0003Rd-00 for mmusic@ietf.org; Fri, 07 Nov 2003 06:41:15 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AI4zK-0003RZ-00 for mmusic@ietf.org; Fri, 07 Nov 2003 06:41:14 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA7BfCI2006553; Fri, 7 Nov 2003 12:41:12 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NNTS2V; Fri, 7 Nov 2003 12:41:12 +0100 Message-ID: <3FAB84C9.1070509@ericsson.com> Date: Fri, 07 Nov 2003 12:40:57 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Gamze Seckin , mmusic@ietf.org Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group References: <787ED0EC136B854DB341E7662D666CD65411DA@bels002.mediator.com> <3FAAA73B.3000700@dynamicsoft.com> In-Reply-To: <3FAAA73B.3000700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, Yes, we have a collision in the name space. I detected it yesterday when I read ICE. However as I understand your proposal for "alt" is brand new. The 3GPP "alt" has been there for a while as being accepted solution and included in the specification. However as it isn't approved yet, it can be changed. However if your parameter is as newly defined as I think, it might be easier for you to rename it. To avoid future problem with this, the 3GPP SDP parameters in the PSS specification should be registered. The question here is what level is needed for registering the parameters. The previous SDP specification is not clear and the new specification requires a specification, which will exist when Release 6 is finished. So any advice from the chair on appropriate level to register them? Is a registering request pointing to 26.234 enough or should a draft be written for this? I would also like to point out that there are a few more attributes also defined: - "a=X-predecbufsize:" This gives the suggested size of the Annex G hypothetical pre-decoder buffer in bytes. - "a=X-initpredecbufperiod:" This gives the required initial pre-decoder buffering period specified according to Annex G. Values are interpreted as clock ticks of a 90-kHz clock. That is, the value is incremented by one for each 1/90 000 seconds. For example, value 180 000 corresponds to a two second initial pre-decoder buffering. - "a=X-initpostdecbufperiod:" This gives the required initial post-decoder buffering period specified according to Annex G. Values are interpreted as clock ticks of a 90-kHz clock. - "a=X-decbyterate:" This gives the peak decoding byte rate that was used to verify the compatibility of the stream with Annex G. Values are given in bytes per second. - "a=framesize: -" This gives the largest video frame size of H.263 streams. - "a=3GPP-Adaptation-Support" Which also should be registered. Cheers Magnus Jonathan Rosenberg wrote: > Well, I've not seen the 3gpp docs, but there is an alt SDP parameter > defined in ICE: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt > > Is this the same as what is being used by 3gpp? If not, we have a > serious name collision... > > -Jonathan R. > > Gamze Seckin wrote: > >> Hi Magnus, >> >> Thanks. I do not see bugs and I think this proposal could be useful >> actually. >> But I also think it is important that IETF takes into account these >> sections somehow, since they may have an impact on several proposals, >> say such as transport independent bw modifiers? >> >> br >> g >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, November 06, 2003 10:34 AM >> To: Gamze Seckin >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group >> >> >> Hi Gamze, >> >> No there are no IETF pointers about this proposal. This work is >> totally created within the 3GPP SA4. There should probably have been >> some review by the IETF before the acceptance of the proposal, but >> that has not happened. However as the Release 6 has not been approved >> yet, any bugs in this proposal can still be fixed. >> >> If you are interested in this proposal please review chapter 5.3.3.3. >> and 5.3.3.4 in the 3GPP TS 26.234 version 0.3.0 of Release 6 >> specification, which can be downloaded here: >> >> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/S4-030680.zip >> >> This is a 200 kb zipped word document. >> >> Cheers >> >> Magnus >> >> Gamze Seckin wrote: >> >> >>> Dear mmusic members, >>> >>> my apologies if this is discussed here before: >>> >>> I am looking for ietf pointers (if there are any) on the sdp >>> descriptions provided in >>> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document >>> s4-30680. >>> on sdp "alt" and "alt-default-id" attributes and the session level >>> grouping attribute, "alt-group". >>> >>> best regards >>> g >>> >>> >>> >>> ----------------------------------------------------------- >>> Gamze Seckin, Ph.D. >>> Director of Research >>> Vidiator Technology (US) Inc. >>> 411 108th Avenue NE. Suite 688 >>> Bellevue, WA 98004 USA. >>> www.vidiator.com >>> >>> Phone: 1.425.688.8811x2108 >>> Email: gamze@vidiator.com >>> >>> This e-mail message (including any attachment) is intended only for >>> the personal use of the recipient(s) named above. This message is >>> confidential and may be legally privileged. If you are not an >>> intended recipient, you may not review, copy or distribute this >>> message. If you have received this communication in error, please >>> notify us immediately by e-mail and delete the original message. Any >>> views or opinions expressed in this message are those of the author >>> only. Furthermore, this message including any attachment does not >>> create any legally binding rights or obligations whatsoever, which >>> may only be created by the exchange of hard copy documents signed by >>> a duly authorized representative of Vidiator Technology (US) Inc. >>> ----------------------------------------------------------- >>> >>> >>> -----Original Message----- >>> From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] >>> Sent: Wednesday, November 05, 2003 10:55 AM >>> To: Magnus Westerlund >>> Cc: Enrico Balatti; mmusic@ietf.org >>> Subject: Re: [MMUSIC] RTSP transport negotiation >>> >>> >>> >>> hi Magnus, >>> >>> Yes, it looks like we can drop the Range header from SETUP request. >>> We probably want the Range header + RTP-Info in the SETUP response >>> for VOD streams...with the caveat that packets can be lost during the >>> switch. >>> I don't believe all components of the RTP-Info header are relevant for >>> live streams that are 'reflected' by the server - here the server acts >>> as a translator. The RTP stream url is known, however the exact sequence >>> number and timestamp for RTP packets is determined by the source of the >>> live stream, not the server reflecting the stream. Hence, I recommend >>> that the RTP-Info carry no sequence number or rtptime for live streams. >>> >>> Also, I noticed that the RTP spec requires change of SSRC when the >>> transport changes. This needs to be added to the transport >>> negotiation notes. >>> >>> I will update the notes and send it to the alias. >>> >>> geetha >>> >>> >>> On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote: >>> >>> >>>> Hi Geetha, >>>> >>>> Thanks for your views. Comments inline >>>> >>>> Geetha Srikantan wrote: >>>> >>>> >>>>> hi Magnus, >>>>> >>>>> My assumption was that SETUP during play happens *after* the client >>>>> has >>>>> switched to the new transport..synchronization is an issue in this >>>>> case. >>>>> I agree that if we can assume that the client requests new transport >>>>> before switching to the new transport, there is probably no >>>>> synchronization issue. I have two follow-up questions on this: >>>>> >>>> >>>> Yes, I would also think that in most cases the application will not >>>> know about the change of transport until it actually happens. This >>>> will probably result in the loss of some media packets. This loss >>>> can be dealt with in a few different way depending on the what the >>>> application can use: media level retransmission, RTSP go back >>>> through PAUSE and PLAY. >>>> >>>> However in regards the question about what your assumption are and >>>> why you need Range in the request I think your answer clearly points >>>> out that there are no need for Range in the Request. There seem to >>>> be reasons for it to be allowed in the Response, to indicate the >>>> correct new synchronization after the change of address. >>>> >>>> So are you still seeing any need for Range in the SETUP request? If >>>> that can be motivated I definitely think there will be possibility >>>> to change the specification to allow for this. However this would >>>> need further investigation. >>>> >>>> >>>> >>>> >>>>> a) How does a mobile client get notified about new transports - >>>>> such as a new IP address? How far ahead of time does the client get >>>>> notified? >>>> >>>> >>>> I would say that this is not a question we can answer. I think we >>>> simply need to ensure that the solution works with both sufficient >>>> notification and without. However without overlap in transport >>>> availability, there will be losses of media packets. >>>> >>>> >>>> >>>> >>>>> b) What is the range of time over which the transport switch happens? >>>>> Consider a scenario where the client requests an IP address change >>>>> for example, via SETUP with no Range, and the server starts sending >>>>> packets to the new IP. Is there a chance that the buffers at the new >>>>> IP get overrun, before the client switches to the new IP? >>>>> It would help if the network guarantees that the transport switch >>>>> will not lose any packets due to buffer overflows, >>>>> >>>> >>>> >>>> As I have stated prior I think we must require the client to have >>>> access to an interface it sends traffic to. If there is overlap I >>>> would assume that it can receive data on both during this period. I >>>> don't find it reasonable to get any guarantees from the networks. I >>>> would assume that any switch of network depends on the change of >>>> access technology, for example by switching from cable to WLAN or to >>>> 3G mobile network. The probability that there will exist any >>>> mobility functionality between these networks seems very small. >>>> >>>> I think that we should design our solution to allow the mobility, >>>> only note that it may loss some packets >>>> >>>> Cheers >>>> >>>> >>>> Magnus Westerlund >>>> >>>> Multimedia Technologies, Ericsson Research EAB/TVA/A >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 8 4048287 >>>> Torshamsgatan 23 | Fax +46 8 7575550 >>>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 7 10:50:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19594 for ; Fri, 7 Nov 2003 10:50: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 1AI8sL-0004T8-Ka for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 10:50:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7FoHPn017177 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 10:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8sL-0004Sy-Gj for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:50: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 KAA19529 for ; Fri, 7 Nov 2003 10:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8s6-0006ek-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 10:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI8s5-0006ee-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 10:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8s5-0004Mi-9J; Fri, 07 Nov 2003 10:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8rI-0004Lc-SC for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 10:49: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 KAA19493 for ; Fri, 7 Nov 2003 10:48:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8rG-0006dh-00 for mmusic@ietf.org; Fri, 07 Nov 2003 10:49:10 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AI8rF-0006de-00 for mmusic@ietf.org; Fri, 07 Nov 2003 10:49:09 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA7Fn5I2028906; Fri, 7 Nov 2003 16:49:05 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V631922S; Fri, 7 Nov 2003 16:49:32 +0100 Message-ID: <3FABBEE2.70500@ericsson.com> Date: Fri, 07 Nov 2003 16:48:50 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comment on draft-ietf-mmusic-ice-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, I had a late night reading session yesterday that produce some comments. 1. I think there are still maybe a few places where ICE is to situation specific towards SIP. I will not go so long to require that mapping of transport addresses are not IP + transport protocol ports as this is what our NAT problem causes. However the constant reference to RTP should probably be removed, there are at least other proprietary media protocols. So I think one should talk about media protocol instead of RTP + RTCP. 2. I think some better motivation why the openly available password in the STUN request is acceptable. And then why the integrity protection gives advantages or not. 3. When the responder performs his connectivity checks and succeed, why does the initiator need to perform a counter check also? Some more should probably be spent on this. The initiator knows the source address as it sees it to send any packets to. The only piece of information missing is what responder connection interface it goes to. This could be identified using STUN supplements and the response message connection IDs. Then the only reasons for doing a counter check is to possibly enable connectivity over a more prioritized connection. OR have I missed something about this. 4. Of course not doing it both way will not provide full protection against the RTP DOS attack. However you have not at all discussed the applicability of ICE for RTP DOS prevention. 5. I also are not finding anything about the retrying in the transmission of STUN request. Should these be done in any special way for ICE? Also there is very little discussion about timer consideration for performing the connectivity checks. 6. In example 6.2 i think it can be easily expanded to show one important functionality of ICE, the possibility to open up restricted NAT through the usage of multiple ICE cycles. If A is behind a restricted NAT it will be able to determine its outermost address and port. However in cycle 1, B will not be able to reach A. When then A tries B over the cycle this may succeed. Then B can verify this by STUNNING a second time. These possibilities are rather tuned down. 7. I think the XML description should be more generic and include 1..N transport addresses for each media session. 8. If anyone missed the other message, the usage of "alt" has a conflict with 3GPP TS 26.234, Rel 6 preliminary specification. 9. I think there should be some example of the complete mesh ICE actually tries. I know it will be a hard thing to draw using ASCII art. 10. If one uses ICE for other purposes then UNSAF mechanism it suddenly will not have any exit strategy for that purpose. However it should still be true that if no relays, etc. are need when people has migrated to IPv6, etc., then it will simply reduce the complexity of doing ICE. 11. When one performs ICE, are there any congestion control considerations to make? If one digs up a number of address locally the local interface might need to send a lot of packets in a short time as it is desired to perform this in parallel. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 7 12:21:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25502 for ; Fri, 7 Nov 2003 12:21: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 1AIAIA-0001lU-LU for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 12:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7HL2ZG006778 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 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 1AIAIA-0001lF-IC for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 12:21: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 MAA25462 for ; Fri, 7 Nov 2003 12:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAI8-0007mf-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 12:21:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIAI7-0007mE-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 12:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAHD-0001eO-0U; Fri, 07 Nov 2003 12: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 1AIAGZ-0001dQ-JK for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 12:19:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25452 for ; Fri, 7 Nov 2003 12:19:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAGY-0007lx-00 for mmusic@ietf.org; Fri, 07 Nov 2003 12:19:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIAGX-0007li-00 for mmusic@ietf.org; Fri, 07 Nov 2003 12:19:21 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7HIkca013552; Fri, 7 Nov 2003 12:18:47 -0500 (EST) Message-ID: <3FABD3F4.5000204@dynamicsoft.com> Date: Fri, 07 Nov 2003 12:18:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: Gamze Seckin , mmusic@ietf.org Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group References: <787ED0EC136B854DB341E7662D666CD65411DA@bels002.mediator.com> <3FAAA73B.3000700@dynamicsoft.com> <3FAB84C9.1070509@ericsson.com> In-Reply-To: <3FAB84C9.1070509@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Magnus Westerlund wrote: > Hi Jonathan, > > Yes, we have a collision in the name space. I detected it yesterday when > I read ICE. However as I understand your proposal for "alt" is brand > new. The 3GPP "alt" has been there for a while as being accepted > solution and included in the specification. I had no idea about it. > However as it isn't approved > yet, it can be changed. However if your parameter is as newly defined as > I think, it might be easier for you to rename it. Yes, its no big deal to change. I am worried more about the potential for other namespace collisions. > > To avoid future problem with this, the 3GPP SDP parameters in the PSS > specification should be registered. Ideally, they should be shared before registration too... > The question here is what level is > needed for registering the parameters. The previous SDP specification is > not clear and the new specification requires a specification, which will > exist when Release 6 is finished. So any advice from the chair on > appropriate level to register them? Well, the tact we took with the SIP documents was this. 3gpp-specific headers were created through IETF RFCs that created "P-headers" that were not for general use. The ensured that the ietf retained ownership and change control for sip and its extensions, while giving 3gpp the ability to have things they needed. Given that the new sdp spec requires an rfc to register parameters, it would seem to imply a similar kind of thing - there should be a doc that goes through the ietf process that defines these attributes and registers them. The 3gpp specs could then reference this doc. I think we ultimately need AD input here on the direction this should go. The "alt" collision is a clear indicator that there is a REAL problem here. -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 Fri Nov 7 16:21:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08224 for ; Fri, 7 Nov 2003 16:21: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 1AIE2S-0001Qh-5P for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LL4dE005488 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2R-0001QP-Uu for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:21: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 QAA08168 for ; Fri, 7 Nov 2003 16:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2Q-00038x-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2P-00038o-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2Q-0001Nw-DL; Fri, 07 Nov 2003 16: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 1AIE1c-0001Id-JN for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 16:20: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 QAA08126 for ; Fri, 7 Nov 2003 16:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1a-000381-00 for mmusic@ietf.org; Fri, 07 Nov 2003 16:20:10 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIE1a-000377-00 for mmusic@ietf.org; Fri, 07 Nov 2003 16:20:10 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30260; Fri, 07 Nov 2003 16:26:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Nov 2003 16:19:34 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F693B@zoe.office.snowshore.com> Thread-Topic: bitrate in gpmd vs. a:bw (from draft-nismail-mmusic-sdp-video-00) Thread-Index: AcOlbA/Sy1f0xIM1SkK0ayrM7BUIZA== From: "Eric Burger" To: Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic-sdp-video-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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section 4.1 Open Issue on counting RTP headers in bitrate: Bitrate is not a network bandwidth parameter, it is a decoder buffer = depth parameter. Thus bitrate needs to reflect the bitrate of the video = stream, not the RTP stream. I can't remember: did we decide that a:bw did count RTP headers? If so, = and you need to limit the RTP stream, there is an existing mechanism to = deal with it. If not, then bitrate is not needed -- just use a:bw. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 7 16:21:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08243 for ; Fri, 7 Nov 2003 16:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2U-0001Tt-38 for mmusic-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LL59T005677 for mmusic-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2T-0001SV-Oy for mmusic-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:21: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 QAA08176 for ; Fri, 7 Nov 2003 16:20:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2Q-00038z-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2P-00038p-00 for mmusic-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2P-0001No-W4; Fri, 07 Nov 2003 16:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1c-0001IU-CV for mmusic@optimus.ietf.org; Fri, 07 Nov 2003 16:20: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 QAA08120; Fri, 7 Nov 2003 16:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1a-00037v-00; Fri, 07 Nov 2003 16:20:10 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIE1Z-000377-00; Fri, 07 Nov 2003 16:20:09 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30260; Fri, 07 Nov 2003 16:26:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Nov 2003 16:19:34 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F693A@zoe.office.snowshore.com> Thread-Topic: Comments on draft-even-avt-h263-h261-options-00 Thread-Index: AcOla1OqRTV+kbv3ThGkLxVO/RC+Gg== From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Comments on draft-even-avt-h263-h261-options-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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section 4: In the example "CIF=3D4 QCIF=3D3 SQCIF=3D2 XMAX=3D360 YMAX=3D240 = MPI=3D2", the text says that the MPI=3D2 parameter goes with SQCIF=3D2. = How does it know? Nits - Section 2 ABNF Size =3D "QCIF" "=3D" "mpi | "CIF" "=3D" mpi Size =3D "QCIF" "=3D" mpi | "CIF" "=3D" mpi ^ Section 3 ABNF "CIF4" "=3D" mpi I "CIF16" "=3D" mpi "CIF4" "=3D" mpi | "CIF16" "=3D" mpi ^ Here #term means comma separated list of term. Here #term means comma separated list of terms. ^ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 8 06:18:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13081 for ; Sat, 8 Nov 2003 06:18:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR6U-0000te-5B for mmusic-archive@odin.ietf.org; Sat, 08 Nov 2003 06:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8BI6rp003440 for mmusic-archive@odin.ietf.org; Sat, 8 Nov 2003 06:18:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR6T-0000tP-W7 for mmusic-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 06:18: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 GAA13069 for ; Sat, 8 Nov 2003 06:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIR6P-0005UW-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 06:18:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIR6P-0005UT-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 06:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR6P-0000sR-6g; Sat, 08 Nov 2003 06:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR5q-0000rW-Ax for mmusic@optimus.ietf.org; Sat, 08 Nov 2003 06:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13066; Sat, 8 Nov 2003 06:17:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIR5m-0005UB-00; Sat, 08 Nov 2003 06:17:22 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1AIR5l-0005Tw-00; Sat, 08 Nov 2003 06:17:21 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 13:16:19 +0200 Message-ID: From: "Even, Roni" To: "'Eric Burger'" , avt@ietf.org, mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-even-avt-h263-h261-options-00 Date: Sat, 8 Nov 2003 13:16:16 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Eric, The 2 in SQCIF=2 is the MPI value. The MPI but it self relates to the custom format x=360, y=240, MPI=2. Roni ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Friday, November 07, 2003 11:20 PM To: avt@ietf.org; mmusic@ietf.org Subject: [MMUSIC] Comments on draft-even-avt-h263-h261-options-00 Section 4: In the example "CIF=4 QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2", the text says that the MPI=2 parameter goes with SQCIF=2. How does it know? Nits - Section 2 ABNF Size = "QCIF" "=" "mpi | "CIF" "=" mpi Size = "QCIF" "=" mpi | "CIF" "=" mpi ^ Section 3 ABNF "CIF4" "=" mpi I "CIF16" "=" mpi "CIF4" "=" mpi | "CIF16" "=" mpi ^ Here #term means comma separated list of term. Here #term means comma separated list of terms. ^ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 8 06:20:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13155 for ; Sat, 8 Nov 2003 06:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR8Q-0001Ag-DJ for mmusic-archive@odin.ietf.org; Sat, 08 Nov 2003 06:20:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8BK6xa004445 for mmusic-archive@odin.ietf.org; Sat, 8 Nov 2003 06:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR8M-00018B-B1 for mmusic-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 06:20: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 GAA13134 for ; Sat, 8 Nov 2003 06:19:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIR8I-0005Vb-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 06:19:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIR8H-0005VY-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 06:19:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR8L-00016o-25; Sat, 08 Nov 2003 06:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR7Z-00013r-Tc for mmusic@optimus.ietf.org; Sat, 08 Nov 2003 06:19: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 GAA13122 for ; Sat, 8 Nov 2003 06:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIR7V-0005V7-00 for mmusic@ietf.org; Sat, 08 Nov 2003 06:19:09 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1AIR7V-0005Uj-00 for mmusic@ietf.org; Sat, 08 Nov 2003 06:19:09 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 13:18:39 +0200 Message-ID: From: "Even, Roni" To: "'Eric Burger'" , mmusic@ietf.org Subject: RE: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic- sdp-video-00) Date: Sat, 8 Nov 2003 13:18:30 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Eric, I agree that here it should be the decoder bit rate and not the RTP. We intend to merge our drafts and that was one of the issues I told Nermeen we have to fix. It is only for H.263 Roni ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Friday, November 07, 2003 11:20 PM To: mmusic@ietf.org Subject: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic-sdp-video-00) Section 4.1 Open Issue on counting RTP headers in bitrate: Bitrate is not a network bandwidth parameter, it is a decoder buffer depth parameter. Thus bitrate needs to reflect the bitrate of the video stream, not the RTP stream. I can't remember: did we decide that a:bw did count RTP headers? If so, and you need to limit the RTP stream, there is an existing mechanism to deal with it. If not, then bitrate is not needed -- just use a:bw. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 8 22:51:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05894 for ; Sat, 8 Nov 2003 22:51: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 1AIgbQ-00052c-5c for mmusic-archive@odin.ietf.org; Sat, 08 Nov 2003 22:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA93p4XB019374 for mmusic-archive@odin.ietf.org; Sat, 8 Nov 2003 22:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgbQ-00052P-28 for mmusic-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 22:51: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 WAA05890 for ; Sat, 8 Nov 2003 22:50:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIgbM-0001vL-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 22:51:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIgbM-0001vH-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 22:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgbN-00051s-1J; Sat, 08 Nov 2003 22:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgaW-0004zr-9U for mmusic@optimus.ietf.org; Sat, 08 Nov 2003 22:50: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 WAA05885 for ; Sat, 8 Nov 2003 22:49:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIgaS-0001v6-00 for mmusic@ietf.org; Sat, 08 Nov 2003 22:50:04 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIgaS-0001v1-00 for mmusic@ietf.org; Sat, 08 Nov 2003 22:50:04 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic-sdp-video-00) Date: Sat, 8 Nov 2003 19:48:17 -0800 Message-ID: <6677B3346233B94EBB11C060935101207749C0@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic-sdp-video-00) Thread-Index: AcOl6hx+AL1N94EjRHasEbmHfsi8NAAiRqtw From: "John Restrick" To: "Even, Roni" , "Eric Burger" , 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agree, it should not include RTP overhead. As for using, bw as long as there is a way to associate that bandwidth with other video information. For example, I may be able to do H.263 up to 768 kbps but H.263 with annex foo might only make sense up to 128kbps - beyond that it might be counterproductive (increase computation time for no quality benefit perhaps).=20 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il]=20 > Sent: Saturday, November 08, 2003 3:19 AM > To: 'Eric Burger'; mmusic@ietf.org > Subject: RE: [MMUSIC] bitrate in gpmd vs. a:bw (from=20 > draft-nismail-mmusic-sdp-video-00) >=20 >=20 > Eric, > I agree that here it should be the decoder bit rate and not=20 > the RTP. We intend to merge our drafts and that was one of=20 > the issues I told Nermeen we have to fix. It is only for H.263 Roni >=20 > ************************************* > Roni Even > VP Product Planning > Polycom Israel >=20 > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >=20 >=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Friday, November 07, 2003 11:20 PM > To: mmusic@ietf.org > Subject: [MMUSIC] bitrate in gpmd vs. a:bw (from > draft-nismail-mmusic-sdp-video-00) >=20 >=20 > Section 4.1 Open Issue on counting RTP headers in bitrate:=20 > Bitrate is not a network bandwidth parameter, it is a decoder=20 > buffer depth parameter. Thus bitrate needs to reflect the=20 > bitrate of the video stream, not the RTP stream. >=20 > I can't remember: did we decide that a:bw did count RTP=20 > headers? If so, and you need to limit the RTP stream, there=20 > is an existing mechanism to deal with it. If not, then=20 > bitrate is not needed -- just use a:bw. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 8 23:54:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07250 for ; Sat, 8 Nov 2003 23:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhaN-0007Ln-8A for mmusic-archive@odin.ietf.org; Sat, 08 Nov 2003 23:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA94s3pb028249 for mmusic-archive@odin.ietf.org; Sat, 8 Nov 2003 23:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhaN-0007LY-4M for mmusic-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 23:54: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 XAA07247 for ; Sat, 8 Nov 2003 23:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhaK-0002iu-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 23:54:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIhaK-0002ir-00 for mmusic-web-archive@ietf.org; Sat, 08 Nov 2003 23:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhaK-0007L4-T1; Sat, 08 Nov 2003 23:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIha0-0007Jx-QP for mmusic@optimus.ietf.org; Sat, 08 Nov 2003 23:53:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07241 for ; Sat, 8 Nov 2003 23:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhZy-0002ib-00 for mmusic@ietf.org; Sat, 08 Nov 2003 23:53:38 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AIhZx-0002iY-00 for mmusic@ietf.org; Sat, 08 Nov 2003 23:53:37 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA94rGI2010580; Sun, 9 Nov 2003 05:53:19 +0100 (MET) Received: from ericsson.com (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6MKLMKT; Sun, 9 Nov 2003 05:53:15 +0100 Message-ID: <3FADC826.1030609@ericsson.com> Date: Sun, 09 Nov 2003 05:52:54 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Restrick CC: "Even, Roni" , Eric Burger , mmusic@ietf.org Subject: Re: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic-sdp-video-00) References: <6677B3346233B94EBB11C060935101207749C0@vtg-um-e2k1.sj21ad.cisco.com> In-Reply-To: <6677B3346233B94EBB11C060935101207749C0@vtg-um-e2k1.sj21ad.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Are you talking about the b=AS: or is a:bw something else? The meaning fo b=AS is that it includes all lower layer overhead including IP. But the video bitrate parameter probably makes sense to talk about at a bitstream level. Cheers Magnus John Restrick wrote: >Agree, it should not include RTP overhead. > >As for using, bw as long as there is a way to associate that bandwidth >with other video information. For example, I may be able to do H.263 up >to 768 kbps but H.263 with annex foo might only make sense up to 128kbps >- beyond that it might be counterproductive (increase computation time >for no quality benefit perhaps). > > > > >>-----Original Message----- >>From: Even, Roni [mailto:roni.even@polycom.co.il] >>Sent: Saturday, November 08, 2003 3:19 AM >>To: 'Eric Burger'; mmusic@ietf.org >>Subject: RE: [MMUSIC] bitrate in gpmd vs. a:bw (from >>draft-nismail-mmusic-sdp-video-00) >> >> >>Eric, >>I agree that here it should be the decoder bit rate and not >>the RTP. We intend to merge our drafts and that was one of >>the issues I told Nermeen we have to fix. It is only for H.263 Roni >> >>************************************* >>Roni Even >>VP Product Planning >>Polycom Israel >> >>Tel: +972-3-9251200 >>Cell: +972-55-481099 >>email:roni.even@polycom.co.il >>******************************************* >> >> >>-----Original Message----- >>From: Eric Burger [mailto:eburger@snowshore.com] >>Sent: Friday, November 07, 2003 11:20 PM >>To: mmusic@ietf.org >>Subject: [MMUSIC] bitrate in gpmd vs. a:bw (from >>draft-nismail-mmusic-sdp-video-00) >> >> >>Section 4.1 Open Issue on counting RTP headers in bitrate: >>Bitrate is not a network bandwidth parameter, it is a decoder >>buffer depth parameter. Thus bitrate needs to reflect the >>bitrate of the video stream, not the RTP stream. >> >>I can't remember: did we decide that a:bw did count RTP >>headers? If so, and you need to limit the RTP stream, there >>is an existing mechanism to deal with it. If not, then >>bitrate is not needed -- just use a:bw. >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 9 09:04:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28611 for ; Sun, 9 Nov 2003 09:04: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 1AIqAj-0003JF-EL for mmusic-archive@odin.ietf.org; Sun, 09 Nov 2003 09:04:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9E49GO012717 for mmusic-archive@odin.ietf.org; Sun, 9 Nov 2003 09:04:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqAj-0003J2-BP for mmusic-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 09:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28608 for ; Sun, 9 Nov 2003 09:03:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqAh-0001Sc-00 for mmusic-web-archive@ietf.org; Sun, 09 Nov 2003 09:04:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIqAh-0001SZ-00 for mmusic-web-archive@ietf.org; Sun, 09 Nov 2003 09:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqAc-0003HG-Hl; Sun, 09 Nov 2003 09:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqAT-0003Ga-DW for mmusic@optimus.ietf.org; Sun, 09 Nov 2003 09:03: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 JAA28605 for ; Sun, 9 Nov 2003 09:03:39 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqAR-0001SQ-00 for mmusic@ietf.org; Sun, 09 Nov 2003 09:03:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIqAQ-0001SN-00 for mmusic@ietf.org; Sun, 09 Nov 2003 09:03:50 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9E3mA04791 for ; Sun, 9 Nov 2003 16:03:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 9 Nov 2003 16:03:48 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 16:03:48 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 16:03:48 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 9 Nov 2003 16:03:47 +0200 Message-ID: <2BF0AD29BC31FE46B7887732114404310357E784@trebe003.europe.nokia.com> Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-02.txt Thread-Index: AcOclZ30APcQbuByRciaTjzTs24QQwAAVvUg To: X-OriginalArrivalTime: 09 Nov 2003 14:03:48.0209 (UTC) FILETIME=[4BD0DE10:01C3A6CA] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Free beer in Mpls 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 To announce the availability of free beer over the Internet, I'd need a = pretty good announcement protocol. Something that can handle the good = news regardless of the language I chose to describe it in, that scales = up to several thousand potential users, that gives decent reliability = and doesn't congest the bars or the back account too heavily. If you've got any interest in media & content discovery, there's a = pretty good chance you'll need to announce it in this way for multicast = networks. And even more so for scaling up to many thousands (or = millions) for mass media. We've got some well developed ideas on how to = do this, and now we want your opinions. Take a look at = draft-ietf-mmusic-img-framework-00.txt and tell us what you think! Cheers, Rod. PS Sorry about the gratuitous use of temptation. But it's the jet lagand = lack of sleep - if you read this far you most definately deserve free = beer and all good reviews end up in beer, even if it's not free :) http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-00.tx= t _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 9 22:42:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23789 for ; Sun, 9 Nov 2003 22:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ2wG-0001ZL-KL for mmusic-archive@odin.ietf.org; Sun, 09 Nov 2003 22:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA3g4Sk006025 for mmusic-archive@odin.ietf.org; Sun, 9 Nov 2003 22:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ2wG-0001Z6-Fd for mmusic-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 22:42: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 WAA23785 for ; Sun, 9 Nov 2003 22:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ2wD-0005FJ-00 for mmusic-web-archive@ietf.org; Sun, 09 Nov 2003 22:42:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ2wC-0005FG-00 for mmusic-web-archive@ietf.org; Sun, 09 Nov 2003 22:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ2wD-0001Yc-1S; Sun, 09 Nov 2003 22:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ2vW-0001Y4-EP for mmusic@optimus.ietf.org; Sun, 09 Nov 2003 22:41: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 WAA23760 for ; Sun, 9 Nov 2003 22:41:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ2vT-0005Em-00 for mmusic@ietf.org; Sun, 09 Nov 2003 22:41:15 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AJ2vS-0005Ej-00 for mmusic@ietf.org; Sun, 09 Nov 2003 22:41:14 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAA3fDI2009059 for ; Mon, 10 Nov 2003 04:41:13 +0100 (MET) Received: from ericsson.com (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V63F6JJZ; Mon, 10 Nov 2003 04:41:47 +0100 Message-ID: <3FAF08C1.8020007@ericsson.com> Date: Mon, 10 Nov 2003 04:40:49 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP offline meeting Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi RTSP fans! We will have a offline meeting on Tuseday from lunch until the coffebreak. We are gathering at 11.40 in the main lobby on gound floor and will continue until 15.15. People interested in participating should RSVP. Discussion topics will be sent to the list later. Cheers Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 04:46:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14179 for ; Mon, 10 Nov 2003 04:46: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 1AJ8cd-0003eB-RD for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 04:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA9kBDo014015 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 04:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ8cc-0003dr-6v for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 04:46: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 EAA14169 for ; Mon, 10 Nov 2003 04:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ8cZ-00025e-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 04:46:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ8cY-00025a-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 04:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ8cW-0003d2-AR; Mon, 10 Nov 2003 04:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ8cP-0003ci-LY for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 04:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14158 for ; Mon, 10 Nov 2003 04:45:44 -0500 (EST) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ8cM-00025O-00 for mmusic@ietf.org; Mon, 10 Nov 2003 04:45:54 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJ8cL-00025L-00 for mmusic@ietf.org; Mon, 10 Nov 2003 04:45:53 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAA9jsK02788 for ; Mon, 10 Nov 2003 11:45:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Nov 2003 11:45:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Nov 2003 11:45:23 +0200 Received: from trebe007.NOE.Nokia.com ([172.22.232.184]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 11:45:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Nov 2003 11:45:22 +0200 Message-ID: <450DCD80CA58884D95FF1840ED26A7A02E46A3@trebe007.europe.nokia.com> Thread-Topic: RTSP SET_PARAMETER with no parameters. Thread-Index: AcOnb1xYFaRmSfZPTxqBnCsPAnhLOw== To: X-OriginalArrivalTime: 10 Nov 2003 09:45:23.0444 (UTC) FILETIME=[5CAB3B40:01C3A76F] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RTSP SET_PARAMETER with no 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear MMUSIC members and RTSP experts, I have a question related to the RTSP SET_PARAMETER method. Is it possible to issue an RTSP SET_PARAMETER method without a parameter = ? Here is an example: SET_PARAMETER rtsp://server/content.3gp RTSP/1.0 CSeq: 123 Session: 12345678 Bandwidth: 64000 Standard_Defined_Header: some_parameter=3Dnew_value_of_some_parameter Content-length: 0=20 Content-type: text/parameters Basically the aim is to update the "Standard_Defined_Header" header = field. I was wondering if this update could be done with such a = SET_PARAMETER request. And if so, how should be the response behaviour = of the server to that? Another alternative may be the usage of OPTIONS method with a Session = ID. Could you experts comment on which way is better? Cheers, Emre _________________________________ Emre Baris Aksu Nokia Mobile Software P.O. Box 88, FIN-33100 Tampere Tel: +358 7180 08000 e-mail: emre.aksu@nokia.com =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 11:33:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28592 for ; Mon, 10 Nov 2003 11:33:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyR-0006qz-4x for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 11:33:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGX78Y026339 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 11:33:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyQ-0006qi-Uf for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28551 for ; Mon, 10 Nov 2003 11:32:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEyP-0007VH-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 11:33:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEyP-0007VD-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 11:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyN-0006pi-P7; Mon, 10 Nov 2003 11:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJExy-0006p0-LA for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 11:32: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 LAA28516 for ; Mon, 10 Nov 2003 11:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJExx-0007Uf-00 for mmusic@ietf.org; Mon, 10 Nov 2003 11:32:37 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AJExw-0007Uc-00 for mmusic@ietf.org; Mon, 10 Nov 2003 11:32:37 -0500 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AJExu-00052u-00; Mon, 10 Nov 2003 08:32:34 -0800 Date: Mon, 10 Nov 2003 08:32:34 -0800 From: Tom Marshall To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP offline meeting Message-ID: <20031110163233.GA19382@real.com> References: <3FAF08C1.8020007@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <3FAF08C1.8020007@ericsson.com> User-Agent: Mutt/1.5.4i 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: , --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Could you push that back a bit? I'm not arriving until about 7:00 Tuesday evening. On Mon, Nov 10, 2003 at 04:40:49AM +0100, Magnus Westerlund wrote: > Hi RTSP fans! >=20 > We will have a offline meeting on Tuseday from lunch until the=20 > coffebreak. We are gathering at 11.40 in the main lobby on gound floor=20 > and will continue until 15.15. People interested in participating should= =20 > RSVP. Discussion topics will be sent to the list later. --=20 It is by the fortune of God that, in this country, we have three benefits: freedom of speech, freedom of thought, and the wisdom never to use either. -- Mark Twain --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/r72hqznSmcYu2m8RAtesAJoDJWAFudeWocEkLhGmYlhY+MnINQCePo3e I78pFPlxOCKlifxIruDxqfg= =dKqS -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 11:44:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29147 for ; Mon, 10 Nov 2003 11:44: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 1AJF92-0008Pf-3A for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 11:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGi4IA032338 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 11:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF91-0008PV-Tn for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:44: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 LAA29140 for ; Mon, 10 Nov 2003 11:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJF90-0007fd-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 11:44:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJF90-0007fa-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 11:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF8y-0008Nk-P0; Mon, 10 Nov 2003 11:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF8s-0008NE-35 for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 11:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29137 for ; Mon, 10 Nov 2003 11:43:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJF8q-0007fR-00 for mmusic@ietf.org; Mon, 10 Nov 2003 11:43:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJF8q-0007fF-00 for mmusic@ietf.org; Mon, 10 Nov 2003 11:43:52 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 08:46:36 -0800 Received: from nismail-w2k02.cisco.com (sjc-vpn4-80.cisco.com [10.21.80.80]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAAGhJiO002056; Mon, 10 Nov 2003 08:43:20 -0800 (PST) Message-Id: <4.3.2.7.2.20031110083958.00b014d0@VTG-UM-E2K1> X-Sender: nismail@VTG-UM-E2K1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 08:43:17 -0800 To: "Even, Roni" From: Nermeen Ismail Subject: RE: [MMUSIC] bitrate in gpmd vs. a:bw (from draft-nismail-mmusic- sdp-video-00) Cc: "'Eric Burger'" , mmusic@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , I also agree that bitrate should represent that of the video stream rather than the RTP stream. However the main difference between it and the BW parameter is that it is defined for each pair of video encoding and resolution. The a:bw is defined per media line. nermeen >Eric, >I agree that here it should be the decoder bit rate and not the RTP. We >intend to merge our drafts and that was one of the issues I told Nermeen we >have to fix. It is only for H.263 >Roni > >************************************* >Roni Even >VP Product Planning >Polycom Israel > >Tel: +972-3-9251200 >Cell: +972-55-481099 >email:roni.even@polycom.co.il >******************************************* > > >-----Original Message----- >From: Eric Burger [mailto:eburger@snowshore.com] >Sent: Friday, November 07, 2003 11:20 PM >To: mmusic@ietf.org >Subject: [MMUSIC] bitrate in gpmd vs. a:bw (from >draft-nismail-mmusic-sdp-video-00) > > >Section 4.1 Open Issue on counting RTP headers in bitrate: >Bitrate is not a network bandwidth parameter, it is a decoder buffer depth >parameter. Thus bitrate needs to reflect the bitrate of the video stream, >not the RTP stream. > >I can't remember: did we decide that a:bw did count RTP headers? If so, and >you need to limit the RTP stream, there is an existing mechanism to deal >with it. If not, then bitrate is not needed -- just use a:bw. > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 11:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29592 for ; Mon, 10 Nov 2003 11:51:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFFl-0000RV-Ti for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 11:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGp15K001695 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFFl-0000RG-Os for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:51: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 LAA29529 for ; Mon, 10 Nov 2003 11:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFFk-00002I-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 11:51:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFFk-00002F-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 11:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFFk-0000PK-BL; Mon, 10 Nov 2003 11:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFFA-0000JR-BJ for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 11:50: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 LAA29461; Mon, 10 Nov 2003 11:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFEw-000015-00; Mon, 10 Nov 2003 11:50:10 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AJFEv-000012-00; Mon, 10 Nov 2003 11:50:09 -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 hAAGnqWV006621; Mon, 10 Nov 2003 17:49:53 +0100 (MET) Message-ID: <3FAFC258.7030005@tzi.uni-bremen.de> Date: Mon, 10 Nov 2003 17:52:40 +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, agenda@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Updated MMUSIC agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, please find attached a slightly revised MMUSIC agenda. Multiparty Multimedia Session Control (MMUSIC) CHAIRS: Joerg Ott Colin Perkins Friday, 14 November 2003, 09:00 - 11:30, Salon D ------------------------------------------------ 0900 Agenda Bashing and Status Update (Chairs, 15) Recent RFCs draft-ietf-mmusic-sdp4nat-05.txt -> RFC 3605 With RFC editor draft-ietf-mmusic-sdpng-trans-04.txt With IESG draft-ietf-mmusic-sdp-new-15.txt draft-rajeshkumar-mmusic-gpmd-03.txt With AD draft-ietf-mmusic-sdp-comedia-05.txt draft-ietf-mmusic-sdp-bwparam-05.txt draft-ietf-mmusic-srcfilter-05.txt Misc Updates draft-camarillo-mmusic-alt-01.txt draft-ietf-mmusic-kmgmt-ext-09.txt draft-ietf-mmusic-sdp-implem-00.txt draft-ietf-mmusic-sdp-new-15.txt 0915 Internet Media Guides (Manyfolks, 30) draft-ietf-mmusic-img-req-00.txt draft-nomura-mmusic-img-framework-02.txt (draft-luoma-mmusic-img-metadata-02.txt fyi only) (draft-luoma-mmusic-img-muppet-03.txt fyi only) 0945 SDP for alternate IP versions (Camarillo, 10) draft-camarillo-mmusic-alt-02.txt 0955 SDP Security Descriptions for Media Streams (Andreasen, 15) draft-ietf-mmusic-sdescriptions-02.txt draft-andreasen-mmusic-securityprecondition-00.txt 1010 SDP parameters to support H.263/H.261 options (Even/Ismail, 30) draft-even-avt-h263-h261-options-00.txt draft-nismail-mmusic-sdp-video-00.txt 1040 Interactive Connectivity Establishment (ICE) (Rosenberg, 20) draft-ietf-mmusic-ice-00.txt draft-rosenberg-sipping-ice-01.txt 1100 RTSP Update (Westerlund/Zeng, 30) draft-ietf-mmusic-rfc2326bis-05.txt draft-ietf-mmusic-rtsp-nat-01.txt draft-zeng-mmusic-rtsp-end-of-stream-01.txt 1130 Close ----------------------------------------------------------------------------- NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 13:10:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03602 for ; Mon, 10 Nov 2003 13:10:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGUF-0006Gr-Qk for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 13:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAIA3BE024099 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 13:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGUF-0006Gc-MS for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 13:10: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 NAA03599 for ; Mon, 10 Nov 2003 13:09:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGUD-0001TT-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 13:10:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJGUD-0001TQ-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 13:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGUD-0006Fy-8l; Mon, 10 Nov 2003 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 1AJGU3-0006Fa-1A for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 13:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03594 for ; Mon, 10 Nov 2003 13:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGU0-0001TJ-00 for mmusic@ietf.org; Mon, 10 Nov 2003 13:09:49 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AJGU0-0001TF-00 for mmusic@ietf.org; Mon, 10 Nov 2003 13:09:48 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAAI9eSs015726; Mon, 10 Nov 2003 19:09:41 +0100 (MET) Received: from ericsson.com (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V63GHG4V; Mon, 10 Nov 2003 19:10:16 +0100 Message-ID: <3FAFD44C.2010000@ericsson.com> Date: Mon, 10 Nov 2003 19:09:16 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP offline meeting References: <20031110163233.GA19382@real.com> In-Reply-To: <20031110163233.GA19382@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom, No, I don't think we can do that. At least I have no other hole in my agenda sufficiently long to have time for real discussion. It will be unfortunate if you can't participate. Magnus Tom Marshall wrote: >Could you push that back a bit? I'm not arriving until about 7:00 >Tuesday >evening. > >On Mon, Nov 10, 2003 at 04:40:49AM +0100, Magnus Westerlund wrote: > > >>Hi RTSP fans! >> >>We will have a offline meeting on Tuseday from lunch until the >>coffebreak. We are gathering at 11.40 in the main lobby on gound floor >> >> > > > >>and will continue until 15.15. People interested in participating >> >> >should > > >>RSVP. Discussion topics will be sent to the list later. >> >> > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 13:31:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04339 for ; Mon, 10 Nov 2003 13:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGoi-0007Rr-0f for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 13:31:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAIVBgc028630 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 13:31:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGoh-0007Rh-Hu for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 13: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 NAA04268 for ; Mon, 10 Nov 2003 13:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGof-0001nS-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 13:31:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJGof-0001nP-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 13:31:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGoZ-0007R0-OE; Mon, 10 Nov 2003 13:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGnk-0007Ol-Jw for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 13:30: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 NAA04249 for ; Mon, 10 Nov 2003 13:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGni-0001jv-00 for mmusic@ietf.org; Mon, 10 Nov 2003 13:30:10 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AJGnh-0001js-00 for mmusic@ietf.org; Mon, 10 Nov 2003 13:30:09 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAAIU8Ss018953; Mon, 10 Nov 2003 19:30:08 +0100 (MET) Received: from ericsson.com (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V63GHPKV; Mon, 10 Nov 2003 19:30:43 +0100 Message-ID: <3FAFD917.1020607@ericsson.com> Date: Mon, 10 Nov 2003 19:29:43 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: emre.aksu@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP SET_PARAMETER with no parameters. References: <450DCD80CA58884D95FF1840ED26A7A02E46A3@trebe007.europe.nokia.com> In-Reply-To: <450DCD80CA58884D95FF1840ED26A7A02E46A3@trebe007.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Emre, Please see my comments inline. emre.aksu@nokia.com wrote: >Dear MMUSIC members and RTSP experts, > >I have a question related to the RTSP SET_PARAMETER method. >Is it possible to issue an RTSP SET_PARAMETER method without a parameter ? > Yes, but is rather a SET_PARAMETER without a body. >Here is an example: > > SET_PARAMETER rtsp://server/content.3gp RTSP/1.0 > CSeq: 123 > Session: 12345678 > Bandwidth: 64000 > Standard_Defined_Header: some_parameter=new_value_of_some_parameter > Content-length: 0 > Content-type: text/parameters > > > Therfore it would not contain any of the Content-x headers. >Basically the aim is to update the "Standard_Defined_Header" header field. I was wondering if this update could be done with such a SET_PARAMETER request. And if so, how should be the response behaviour of the server to that? > The response to such a request is a 200 OK. However that will not necessary mean that the recipient has understood all headers, only the mandatory. Therefore if one has important functionality and do not know appriori that it will behave in this way one should use a Require header with a feature tag for the functionality. > >Another alternative may be the usage of OPTIONS method with a Session ID. Could you experts comment on which way is better? > Options is not better. Options has another semantics and induce other overhead. So the usage of SET_PARAMETER is the right one. Cheers Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 10 21:39:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01019 for ; Mon, 10 Nov 2003 21:39: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 1AJOQu-0000Ei-EL for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 21:39:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2d8K0000902 for mmusic-archive@odin.ietf.org; Mon, 10 Nov 2003 21:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOQu-0000ET-92 for mmusic-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00996 for ; Mon, 10 Nov 2003 21:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOQr-000368-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 21:39:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJOQr-000365-00 for mmusic-web-archive@ietf.org; Mon, 10 Nov 2003 21: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 1AJOQn-0000D2-SK; Mon, 10 Nov 2003 21: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 1AJOQh-000079-2K for mmusic@optimus.ietf.org; Mon, 10 Nov 2003 21:38:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00963 for ; Mon, 10 Nov 2003 21:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOQe-000350-00 for mmusic@ietf.org; Mon, 10 Nov 2003 21:38:52 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AJOQc-00034f-00 for mmusic@ietf.org; Mon, 10 Nov 2003 21:38:51 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAB2ciSs003463 for ; Tue, 11 Nov 2003 03:38:48 +0100 (MET) Received: from ericsson.com (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6ML2Q9C; Tue, 11 Nov 2003 03:38:43 +0100 Message-ID: <3FB04903.3070504@ericsson.com> Date: Tue, 11 Nov 2003 03:27:15 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP off line meeting Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi RTSP fans, First I would like to announce a new meeting place. We now meet at 11.40 at the Message board at floor three, in front of the registration desk. We will go directly to find somewhere to sit down and talk. Therefore I will ask that people either bring something to eat or abstain from lunch. I have also managed to make an agenda. If people has additions, you can mail them to the list or simply remember them until the meeting. Cheers Magnus RTSP issues agenda for discussions in MPLS 1. Administrative 2. Since last meeting (1st of October). a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Await review from the WG. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Needs text d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - Await review from the WG. e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Await review from the WG. f. http://rtsp.org/bug531189 - How does REDIRECT method work Everything except the following seem to be OK: - REDIRECT and the usage of Close:Connection. g. http://rtsp.org/bug810678 - How to indicate end of media stream - We need to document in the RTSP specification regarding RTP what happens when a source times out a SSRC or receives a RTCP BYE for a source. - Using BYE is not suitable way to indicate the end of the stream. The motivation for this can be seen in Thomas proposal. - Look into SIP to see how they have resolved the discrepancies between media and signalling channel. - See draft-ietf-zeng-rtsp-end-of-stream-00.txt * RTCP * RTSP * Both h. http://rtsp.org/bug770522 - Request to response time is not limited. - Sean to write up text. i. http://rtsp.org/bug810681 - The updated specification version number - Awaiting investigation results regarding changes by Aravind. - Question of intentions. j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - Has been removed from spec. k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Awaiting review from the WG. l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - Text sent to mailing list, comments? m. http://rtsp.org/bug810666 - Removal of SETUP in play state - Removed from draft n. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes o. http://rtsp.org/bug795314 - Caching of OPTIONS request 3. New issues a. http://rtsp.org/bug - Should all ABNF syntax be gathered in one chapter? b. http://rtsp.org/bug829528 - Usage of Grouping of media lines with RTSP. 4. Other RTSP related things - RTSP NAT, what are our intentions with this work. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 11 01:39:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08660 for ; Tue, 11 Nov 2003 01:39: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 1AJSB4-0006BO-L4 for mmusic-archive@odin.ietf.org; Tue, 11 Nov 2003 01:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB6d2xN023760 for mmusic-archive@odin.ietf.org; Tue, 11 Nov 2003 01:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJSB4-0006B9-GO for mmusic-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 01:39: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 BAA08648 for ; Tue, 11 Nov 2003 01:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJSB1-0006Bq-00 for mmusic-web-archive@ietf.org; Tue, 11 Nov 2003 01:38:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJSB0-0006Bn-00 for mmusic-web-archive@ietf.org; Tue, 11 Nov 2003 01:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJSB3-0006Af-15; Tue, 11 Nov 2003 01: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 1AJSA5-0006A9-AG for mmusic@optimus.ietf.org; Tue, 11 Nov 2003 01:38: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 BAA08640 for ; Tue, 11 Nov 2003 01:37:49 -0500 (EST) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJSA2-0006BO-00 for mmusic@ietf.org; Tue, 11 Nov 2003 01:37:58 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJSA1-0006BL-00 for mmusic@ietf.org; Tue, 11 Nov 2003 01:37:57 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB6buc06178 for ; Tue, 11 Nov 2003 08:37:57 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 08:37:51 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 08:37:47 +0200 Received: from trebe007.NOE.Nokia.com ([172.22.232.184]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 08:37:43 +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] RTSP SET_PARAMETER with no parameters. Date: Tue, 11 Nov 2003 08:37:38 +0200 Message-ID: <450DCD80CA58884D95FF1840ED26A7A02E46B0@trebe007.europe.nokia.com> Thread-Topic: [MMUSIC] RTSP SET_PARAMETER with no parameters. Thread-Index: AcOnuOJi13kqAf5CQaqZwsu6xZh9nwAZUN7w To: Cc: X-OriginalArrivalTime: 11 Nov 2003 06:37:43.0235 (UTC) FILETIME=[4F797130:01C3A81E] 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable HI Magnus, Thanks for the clarification. > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > ext Magnus Westerlund > Sent: 10 November, 2003 20:30 > To: Aksu Emre (NMP-MSW/Tampere) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP SET_PARAMETER with no parameters. >=20 >=20 > Hi Emre, >=20 > Please see my comments inline. >=20 > emre.aksu@nokia.com wrote: >=20 > >Dear MMUSIC members and RTSP experts, > > > >I have a question related to the RTSP SET_PARAMETER method. > >Is it possible to issue an RTSP SET_PARAMETER method without=20 > a parameter ? > > >=20 > Yes, but is rather a SET_PARAMETER without a body. >=20 > >Here is an example: > > > > SET_PARAMETER rtsp://server/content.3gp RTSP/1.0 > > CSeq: 123 > > Session: 12345678 > > Bandwidth: 64000 > > Standard_Defined_Header:=20 > some_parameter=3Dnew_value_of_some_parameter > > Content-length: 0=20 > > Content-type: text/parameters > > > > =20 > > > Therfore it would not contain any of the Content-x headers. >=20 > >Basically the aim is to update the "Standard_Defined_Header"=20 > header field. I was wondering if this update could be done=20 > with such a SET_PARAMETER request. And if so, how should be=20 > the response behaviour of the server to that? > > >=20 > The response to such a request is a 200 OK. However that will not=20 > necessary mean that the recipient has understood all headers,=20 > only the=20 > mandatory. Therefore if one has important functionality and=20 > do not know=20 > appriori that it will behave in this way one should use a=20 > Require header=20 > with a feature tag for the functionality. >=20 > > > >Another alternative may be the usage of OPTIONS method with=20 > a Session ID. Could you experts comment on which way is better? > > >=20 > Options is not better. Options has another semantics and induce other=20 > overhead. So the usage of SET_PARAMETER is the right one. >=20 > Cheers >=20 > Magnus >=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 Tue Nov 11 12:29:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11751 for ; Tue, 11 Nov 2003 12:29: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 1AJcK9-0003vN-Jd for mmusic-archive@odin.ietf.org; Tue, 11 Nov 2003 12:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHT5JL015084 for mmusic-archive@odin.ietf.org; Tue, 11 Nov 2003 12:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcK9-0003vD-GO for mmusic-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:29: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 MAA11744 for ; Tue, 11 Nov 2003 12:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcK7-0006bf-00 for mmusic-web-archive@ietf.org; Tue, 11 Nov 2003 12:29:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcK7-0006bX-00 for mmusic-web-archive@ietf.org; Tue, 11 Nov 2003 12:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcK5-0003uN-Oj; Tue, 11 Nov 2003 12:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcJD-0003q9-FY for mmusic@optimus.ietf.org; Tue, 11 Nov 2003 12:28: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 MAA11733 for ; Tue, 11 Nov 2003 12:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcJB-0006bS-00 for mmusic@ietf.org; Tue, 11 Nov 2003 12:28:05 -0500 Received: from db1.ncube.com ([134.242.64.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcJB-0006bB-00 for mmusic@ietf.org; Tue, 11 Nov 2003 12:28:05 -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 hABHRXip007385 for ; Tue, 11 Nov 2003 09:27:34 -0800 (PST) From: Sean Sheedy To: mmusic@ietf.org Content-Type: text/plain Organization: nCube Corporation Message-Id: <1068571652.3166.93.camel@laptop.osioda.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 11 Nov 2003 11:27:33 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Proposed text for client timeout 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 Here's a first cut at some proposed text describing client request timeouts in RTSP. Please seen http://rtsp.org/bug770522 for more details. Sean ***** 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. 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. 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. -- 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 Nov 11 13:03:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13764 for ; Tue, 11 Nov 2003 13:03:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcr0-0007RG-Mu for mmusic-archive@odin.ietf.org; Tue, 11 Nov 2003 13:03:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABI32dP028593 for mmusic-archive@odin.ietf.org; Tue, 11 Nov 2003 13:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcr0-0007R6-J1 for mmusic-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:03: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 NAA13734 for ; Tue, 11 Nov 2003 13:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcqy-0007JB-00 for mmusic-web-archive@ietf.org; Tue, 11 Nov 2003 13:03:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcqy-0007J8-00 for mmusic-web-archive@ietf.org; Tue, 11 Nov 2003 13:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcqz-0007QS-5l; Tue, 11 Nov 2003 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcq9-0007PM-RY for mmusic@optimus.ietf.org; Tue, 11 Nov 2003 13:02: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 NAA13701 for ; Tue, 11 Nov 2003 13:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcq7-0007Hw-00 for mmusic@ietf.org; Tue, 11 Nov 2003 13:02:07 -0500 Received: from ip72.usw232.dsl-acs2.sea.iinet.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AJcq7-0007HH-00 for mmusic@ietf.org; Tue, 11 Nov 2003 13:02:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Nov 2003 10:01:30 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD6540E9A@bels002.mediator.com> Thread-Topic: [MMUSIC] RTSP: Proposed text for client timeout Thread-Index: AcOoeVcFJkJbd9P7QcyWFJG6rZQexQAA7L/A From: "Gamze Seckin" To: Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] STUN vs Symmetric RTP 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 Hi, I checked the rtsp nat traversal draft = (draft-ietf-mmusic-rtsp-nat-01.txt) but could not find a comprehensive = comparison between STUN vs Symmetric RTP. Is anybody actually using STUN? How about symmetric RTP? Which one would you recommend if you had to actually deploy it ? Any pointers appreciated. Br g ----------------------------------------------------------- Gamze Seckin, Ph.D. Director of Research Vidiator Technology (US) Inc. 411 108th Avenue NE. Suite 688 Bellevue, WA 98004 USA. www.vidiator.com Phone: 1.425.688.8811x2108 Email: gamze@vidiator.com This e-mail message (including any attachment) is intended only for the = personal use of the recipient(s) named above. This message is = confidential and may be legally privileged. If you are not an intended = recipient, you may not review, copy or distribute this message. If you = have received this communication in error, please notify us immediately = by e-mail and delete the original message. Any views or opinions = expressed in this message are those of the author only. Furthermore, = this message including any attachment does not create any legally = binding rights or obligations whatsoever, which may only be created by = the exchange of hard copy documents signed by a duly authorized = representative of Vidiator Technology (US) Inc. ----------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 00:38:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09095 for ; Wed, 12 Nov 2003 00:38: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 1AJnhb-0000pj-7i for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 00:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC5c3Xa003194 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 00:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnha-0000p3-MI for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 00:38: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 AAA09061 for ; Wed, 12 Nov 2003 00:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnhX-0001C0-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 00:37:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJnhX-0001Bw-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 00:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnhZ-0000nD-Bi; Wed, 12 Nov 2003 00: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 1AJnhJ-0000lx-1a for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 00:37: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 AAA09058 for ; Wed, 12 Nov 2003 00:37:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnhG-0001Bs-00 for mmusic@ietf.org; Wed, 12 Nov 2003 00:37:42 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AJnhF-0001Bp-00 for mmusic@ietf.org; Wed, 12 Nov 2003 00:37:41 -0500 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AJnhB-0006xE-00; Tue, 11 Nov 2003 21:37:37 -0800 Date: Tue, 11 Nov 2003 21:37:37 -0800 From: Tom Marshall To: Sean Sheedy Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: Proposed text for client timeout Message-ID: <20031112053737.GE26651@real.com> References: <1068571652.3166.93.camel@laptop.osioda.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline In-Reply-To: <1068571652.3166.93.camel@laptop.osioda.org> User-Agent: Mutt/1.5.4i 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: , --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > 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. > 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. >=20 > A client SHOULD wait at least 20*T1 before concluding that the server > will not be responding to its request. >=20 > 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.= =20 > 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? 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). --=20 Beware of Programmers who carry screwdrivers. -- Leonard Brandwein --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/scchqznSmcYu2m8RAv55AJ9WPOY9tbasZPbv0mO5IgM5qzCoSgCgj/3x 0suH/qwCrpHbu0STffpCXzg= =EcfC -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 00:46:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09426 for ; Wed, 12 Nov 2003 00:46: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 1AJnp2-0001ox-C6 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 00:45:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC5jihr006993 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 00:45:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnp2-0001oi-7x for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 00:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09407 for ; Wed, 12 Nov 2003 00:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnoz-0001Kp-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 00:45:41 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJnj0-0001CV-01 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 00:39:30 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJnUA-0004cw-ML for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 00:24:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnU5-000811-0l; Wed, 12 Nov 2003 00:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJmdH-0004l7-Ky for mmusic@optimus.ietf.org; Tue, 11 Nov 2003 23:29: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 XAA07282 for ; Tue, 11 Nov 2003 23:29:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJmdF-0000R0-00 for mmusic@ietf.org; Tue, 11 Nov 2003 23:29:29 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AJmdE-0000Qx-00 for mmusic@ietf.org; Tue, 11 Nov 2003 23:29:29 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 11 Nov 2003 20:29:04 -0800 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); Tue, 11 Nov 2003 20:29:03 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Tue, 11 Nov 2003 20:28:38 -0800 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 1AJmcb-0006Rj-00 for ; Tue, 11 Nov 2003 20:28:49 -0800 Date: Tue, 11 Nov 2003 20:27:20 -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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on scarface.real.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #107 - 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-840304 ] CSEQ is direction dependent in numberspaces. (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 11 Nov 2003 13:54:14 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. Bugs item #840304, was opened at 2003-11-11 22:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=840304&group_id=23194 Category: Editorial Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: CSEQ is direction dependent in numberspaces. Initial Comment: IETF 58 off-line discussion resulted in one point to ensure is edited in:It needs to be clarified that CSeq sequence number spaces are direction dependent. The C->S Requests uses a different space then S->C Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=840304&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 Nov 12 15:41:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08080 for ; Wed, 12 Nov 2003 15:41:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1nV-0001O9-4O for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 15:41:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKf5vB005334 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 15:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1nU-0001Nx-Ta for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:41: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 PAA08027 for ; Wed, 12 Nov 2003 15:40:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1nT-0005fS-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 15:41:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1nS-0005fP-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 15:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1nR-0001N7-CE; Wed, 12 Nov 2003 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1mp-0001Lo-QK for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 15:40:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08012 for ; Wed, 12 Nov 2003 15:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1mo-0005ex-00 for mmusic@ietf.org; Wed, 12 Nov 2003 15:40:22 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AK1mn-0005eu-00 for mmusic@ietf.org; Wed, 12 Nov 2003 15:40:21 -0500 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AK1ml-0007Ph-00; Wed, 12 Nov 2003 12:40:19 -0800 Date: Wed, 12 Nov 2003 12:40:19 -0800 From: Tom Marshall To: Sean Sheedy Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: Proposed text for client timeout Message-ID: <20031112204019.GA28461@real.com> References: <1068571652.3166.93.camel@laptop.osioda.org> <20031112053737.GE26651@real.com> <1068668428.3172.36.camel@laptop.osioda.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <1068668428.3172.36.camel@laptop.osioda.org> User-Agent: Mutt/1.5.4i 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: , --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > 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. Absolutely. So why are we proposing to measure RTT at all? Why don't we just say this: The server SHOULD respond to all requests as soon as practicable. If a request takes a significant amount of time to process, or there is an expectation that it will, the server SHOULD send 100 responses at regular intervals so that the client knows its request is still being processed. The client SHOULD give the server a reasonable amount of time to process = its requests. If an unreasonable amount of time elapses without receiving any response, the client MAY assume the server is unresponsive and abort the connection. If a 100 response is received, the client MUST reset its response timer. The only remaining question would be what constitutes a reasonable amount of time and a regular interval. --=20 I put instant coffee in a microwave and almost went back in time. -- Steven Wright --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/spqzqznSmcYu2m8RAtPEAKCN3GUGVDSXSmHyg2erCdiueiNESQCggUyx 5wnRA0OjeTgS5wnvzKtMUyk= =64wJ -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 15:51:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08732 for ; Wed, 12 Nov 2003 15:51:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1ws-0003JQ-QH for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 15:50:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKokIh012731 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 15:50:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1wr-0003JC-SU for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:50: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 PAA08693 for ; Wed, 12 Nov 2003 15:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1wo-0005wK-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 15:50:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1wn-0005wH-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 15:50:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1wT-0003FV-Kr; Wed, 12 Nov 2003 15:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1w0-0003CH-T1 for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 15:49: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 PAA08652 for ; Wed, 12 Nov 2003 15:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1vx-0005vI-00 for mmusic@ietf.org; Wed, 12 Nov 2003 15:49:49 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AK1vv-0005vD-00 for mmusic@ietf.org; Wed, 12 Nov 2003 15:49:48 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hACKnh5u000883 for ; Wed, 12 Nov 2003 13:49:43 -0700 (MST) Received: from sun.com (vpn-129-150-17-47.SFBay.Sun.COM [129.150.17.47]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HO9002FBB6UON@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Wed, 12 Nov 2003 12:49:43 -0800 (PST) Date: Wed, 12 Nov 2003 14:49:46 -0600 From: Aravind Narasimhan To: mmusic@ietf.org Message-id: <3FB29CEA.3030208@sun.com> 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 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP offline meeting Notes - 11/11 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 The meeting followed the agenda that Magnus sent out on 11/10 Attendees: Thomas Zeng, Henning Schulzerine Geetha Srikantan Victor Varsa Sean Sheedy Adrea Basso Magnus Westerlund Colin Perkins Aravind Narasimhan Issues: 2A. RTP Timestamps under pause clarification. - Aravind to write up text - Not Done. Hopefully by the end of week. 2B. PLAY request at the end of a media clip - Awaiting review 2C. Implicit Redirect - Philippe/Aravind to write up text? 2D. Aggregate URL deriving - Awaiting review. - HS: Is there motivation for deriving the URL? It should be opaque? I can't use for something else? - TZ: It might conflict with an actual URL? - HS: Seems like a recipie for strange cases. - TZ: SDP from two different sources that you want to mix. - HS: The server should give you the URL. If the SDP doesn't have an aggregate URL than the media can't be played in aggregate fashion. - HS: Concerned about specifying generating URL. How do you know what you are getting? What if it is not there? - TZ: Have SETUP two separate streams. Need to control together. Session ID should be enough, but URL is needed for PLAY request. - AN: URL is used for proxies and accounting. - CP: State explicitly what needs to be done. - HS: Server needs to accept the need to do it. - CP: Imposing rules on URL is hard. Nontraditional URIs. What do you do. - HS: Toss this feature and verbiage from the spec. because it is hard to specify. - MW: Leave it as open issue. See if Tom has issue. But will remove from spec if no objections. Conclusion: Hard feature to specify. We should not try to do it because we will do a poor job of it. Will remove from spec if no objections. 2E: A=range in SDP indicates live media - HS: An undefined range means there is no defined a range forward or back. - GS: How about RTP-Info. Does it go away? - MW: You need RTP-Info - AN: Server does not know NPT. Can't generate it in many cases. - HS: How do you do Tivo like model? - HS: From whereever you started recording to now. - CP: It's not quite that simple. You can play past the pause point because the Tivo is still recording. - HS: Dont' want to break the spec. Don't want to label things. Because you may have part live and part not live. - MW: Two aspects. We need something new, but we can't break range. - HS: If range abs time doesnt support this model. - HS: If you use UTC, then you know if you are asking for a time tomorrow then it is live. - CP: How about clock skew. - HS: If we can do time till now, it works with the Tivo Case. - TZ: If you say UTC -, then the slider size is going to be hard to determine. - HS: a user interface issue. Conclusion: + In the SDP range if there is an open range, then it is live. We need to check the Tivo case is supported + Need Live media defintion: media with out a defined end point during playback. + SDP is referencing RTSP for range format. Need to register with IANA. 2.F REDIRECT with Connetion close: - MW: Normally connection is closed by the client. The server may close the connection after 200k is recieved. - TZ: a bit rude bit its fine. Conclusion: Server MAY drop the connection after it has recieved 200 OK response on a REDIRECT. 2G. End of Stream - TZ: Need a persistant connection - MW: Is there a usecase in SIP for End of playout notification? - HS: There Is media level, application level and , session level - HS: It is hard to dectect the last packet stream. Technically hard. - HS: What is the use case for needing end of stream in the RTP/RTCP? End of segment/ End of stream is it a more generic problem? - TZ: This is more like an event. - HS: DTMF-AD was trying to signal time synchornized notification. Not universally popular. - TZ: Not event registration frame work. Is something like SIP event framework overkill? - AN: The client in RTSP doesnt know the media has ended if you play Range - - TZ: Also for live. - AN: but the live server doesnt know when the range ends - HS: How about send an announce with the new SDP that stream's end range has changed? - HS: How about BYE - TZ: Don't wnat to do BYE because it gets rid of the SSRC and you want to keep RTCP reporting. - TZ: Also want to report error - HS: Make that generic. Is the consumer a machine or is it for human user? - AN: Once persistence is established you can add all kinds of server reporting features. - SS: Almost always it will be a machine that will consume the error information. - TZ: A more generic framework for header that can be in end of stream and in Announce. - HS: Use Announce to send the SDP with the new range header - TZ: You dont need the whole range header. You alredy have have SDP. - HS: You have a trade of with efficiently and future supoprt. Try to overly optimize is not a good idea. - AN: No reason why RTCP can't say end of stream as a separate thing. - HS: Yes. But keep it separarte and have AVT work on it. - MW: Use ANNOUNCE. to do this. Revivie Sean's old spec. Conclusion: Keep the end of stream messages in the control channel rather than the data chanel. TZ will take ownership. - Keep the idea of server trying to start a coneection with client as a separate issue. 2H. How long to wait for response? - SS: 5 Seconds? - HS: 10 times longer than SIP. - SS: This is RTSP over TCP. UDP is lot longer - HS: 100 is a indication that it will succeed. You want to send it early rather than later. So 5 seconds may be too long. - TS: The first 100 response is easy. Do we need to send it periodically. - HS: There is a reasons to send useful feedback, but do we need to send more than that. - HS: Should not be mandated - AN: Server MAY / SHOULD send 100, but client MUST deal with it. - CP: If the server knows its going to take appreciable amount of time, send 100 immediately (less than 2 seconds). - TZ: Sean's proposal is reasonable. - CP: If the server should send in a "couple" of seconds. - CP: It's hard to place a time limit. - TZ: Implementor's guide. - HS: Not a good idea because it's hard to do, and may contradict the spec. - TZ: Provide some motivation example. Conclusion: Sean's writeup seems reasonable. Change the timelimit to 2 seconds and make sure that wording is there to indicate server should do this immediately if it know it's going to take a long time. Need motivation example. 2I. Version number of new spec - MW: will try to make it 1.0 - HS: Protocols don't generally get a second chance - HS: If you want to go with a new protocol version than get some better features. - TZ: There are servers out there that wont interop. - CP: Document where the potential interop problems will be. - AN: We will be hard pressed to keep the current version number. But let's see after the change spec is done. 2J. Teardown * and Ready-nm - Removed from spec. Awaiting WG review 2K. How to handle sync in re-SETUP - Awaiting review from the WG. - Need to look at the level of mandate for RTP-Info in live case. 2L. Re-Setup of Transport parameters - GS: Not to unicast -> multicast. - HS: May want to switch from multicast to unicast. . . - MW: Take to list. 2M. Removal of SETUP in play state - Removed from spec. - CP: Keep it unspecified rather then saying that it cannot be done. That breaks being able to do that in the future. - AN: Explicitly state that it is unspecified instead of cant be done. Conclusion: Remove but state that it is unspecified and a new draft needs to be writted to make it work. 2N. Use of c= in SDP to know possible address classes - CP: It is reasonable to connet to the server with one protocol and use a different protocol for the media. - TZ: Is it reasonable to have two, (one for IPv4, and one for IPv6). - CP: You can specify alternatives. - MW: 3338+gonzolo. Use the alt group thing. Conclusion: Should look at address classes in the SDP to figure what protocol to use (need to add SDP section of RTSP) Look at c= line syntax. Multiple c lines can be use in media field? SIP resolution was that multiple c lines should not be used to express multiple connection address. 2O. How should proxies cache? OPTIONS. Conclusion: Caching dropped. make it explicitly unspecified in the spec. 3A. ABNF should be moved to end. - HS: Difficult problem with SIP spec is that the when the semantic description is given, it should reference ABNF name. - CP: IETF has tools as well has henning. 3B. . . . 4. How to do RTSP over NAT? NAT Requirements? Priorities: 1. Server is deployed in open network. 2. Server behind firewall next. 3. If a client is not dual hosted, it should not have to deal with additional protocols. 4. Must have defense against DOS 5. Security. 6. MUST deal with symmetric nat. 7. ALG. The firewall traversal should not interfere with ALGs. 8. Advise to ALG writers not to screw it up. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 16:31:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10767 for ; Wed, 12 Nov 2003 16:31: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 1AK2Zc-0008Cj-V6 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLUm4W031531 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Zc-0008CA-LE for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10606 for ; Wed, 12 Nov 2003 16:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2ZZ-0006i4-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:30:45 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK2Ll-0006W8-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:16:30 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK27t-0003ZI-HN for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK27n-00053f-Sj; Wed, 12 Nov 2003 16:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK27G-00051Q-K0 for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 16:01: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 QAA09441 for ; Wed, 12 Nov 2003 16:01:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK27E-0006F3-00 for mmusic@ietf.org; Wed, 12 Nov 2003 16:01:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AK27B-0006Es-00 for mmusic@ietf.org; Wed, 12 Nov 2003 16:01:26 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACKxwI2002833; Wed, 12 Nov 2003 21:59:58 +0100 (MET) Received: from ericsson.com (permit156.er.ki.sw.ericsson.se [147.214.97.156]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6MMJMC7; Wed, 12 Nov 2003 21:59:57 +0100 Message-ID: <3FB29F0A.6040009@ericsson.com> Date: Wed, 12 Nov 2003 21:58:50 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Sean Sheedy , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: Proposed text for client timeout References: <20031112204019.GA28461@real.com> In-Reply-To: <20031112204019.GA28461@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I think Tom's text is basically what the conclusions was of yesterday's RTSP meeting. I think there was talk about being a little bit more strict on some cases. I think there was some talk about saying: A server MUST send a 1xx response if the request takes or is expected to take more than 2 seconds to process. The server SHOULD send further 1xx messages if further information about the processing of the request becomes available. On the client side we talked about writing some general cautioning that the client needs to take transport delays into consideration. Cheers Magnus Tom Marshall wrote: >>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. >> >> > >Absolutely. So why are we proposing to measure RTT at all? Why don't >we >just say this: > > The server SHOULD respond to all requests as soon as practicable. If >a > request takes a significant amount of time to process, or there is an > expectation that it will, the server SHOULD send 100 responses at >regular > intervals so that the client knows its request is still being >processed. > > The client SHOULD give the server a reasonable amount of time to >process its > requests. If an unreasonable amount of time elapses without receiving >any > response, the client MAY assume the server is unresponsive and abort >the > connection. If a 100 response is received, the client MUST reset its > response timer. > >The only remaining question would be what constitutes a reasonable >amount of >time and a regular interval. > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 16:31:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10808 for ; Wed, 12 Nov 2003 16:31: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 1AK2Zn-0008Em-V9 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 16:31:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLUxcn031658 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Zn-0008EX-RY for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:30: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 QAA10650 for ; Wed, 12 Nov 2003 16:30:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Zi-0006kA-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:30:54 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK2LT-0006W8-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:16:12 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK2Ch-0003kY-JO for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Cb-00061d-Iw; Wed, 12 Nov 2003 16: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 1AK2Bq-0005uE-1S for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 16:06: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 QAA09652 for ; Wed, 12 Nov 2003 16:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Bn-0006KP-00 for mmusic@ietf.org; Wed, 12 Nov 2003 16:06:11 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Bm-0006J8-00 for mmusic@ietf.org; Wed, 12 Nov 2003 16:06:10 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id hACL5aio018285; Wed, 12 Nov 2003 13:05:36 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 13:05:36 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17CAF@misty.packetvideo.com> From: Thomas Zeng To: "'Aravind Narasimhan'" , mmusic@ietf.org Subject: RE: [MMUSIC] RTSP offline meeting Notes - 11/11 Date: Wed, 12 Nov 2003 13:05:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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: , Thanks for the comments. Two important corrections, see inline. > -----Original Message----- > From: Aravind Narasimhan [mailto:Aravind.Narasimhan@Sun.COM] > Sent: Wednesday, November 12, 2003 12:50 PM > To: mmusic@ietf.org > Subject: [MMUSIC] RTSP offline meeting Notes - 11/11 > > > The meeting followed the agenda that Magnus sent out on 11/10 > > Attendees: > > Thomas Zeng, > Henning Schulzerine > Geetha Srikantan > Victor Varsa > Sean Sheedy > Adrea Basso > Magnus Westerlund > Colin Perkins > Aravind Narasimhan > > > Issues: > > 2A. RTP Timestamps under pause clarification. > - Aravind to write up text - Not Done. Hopefully by the end of week. > > 2B. PLAY request at the end of a media clip > - Awaiting review > > 2C. Implicit Redirect > - Philippe/Aravind to write up text? > > 2D. Aggregate URL deriving > - Awaiting review. > - HS: Is there motivation for deriving the URL? It should > be opaque? > I can't use for something else? > - TZ: It might conflict with an actual URL? > - HS: Seems like a recipie for strange cases. > - TZ: SDP from two different sources that you want to mix. > - HS: The server should give you the URL. If the SDP > doesn't have an > aggregate URL than the media can't be played in aggregate fashion. > - HS: Concerned about specifying generating URL. How do you > know what > you are getting? What if it is not there? > - TZ: Have SETUP two separate streams. Need to control together. > Session ID should be enough, but URL is needed for PLAY request. > - AN: URL is used for proxies and accounting. > - CP: State explicitly what needs to be done. > - HS: Server needs to accept the need to do it. > - CP: Imposing rules on URL is hard. Nontraditional URIs. > What do you do. > - HS: Toss this feature and verbiage from the spec. because > it is hard > to specify. > - MW: Leave it as open issue. See if Tom has issue. But > will remove > from spec if no objections. > Conclusion: Hard feature to specify. We should not try to do it > because we will do a poor job of it. Will remove from spec if no > objections. > > 2E: A=range in SDP indicates live media > - HS: An undefined range means there is no defined a range > forward or back. > - GS: How about RTP-Info. Does it go away? > - MW: You need RTP-Info > - AN: Server does not know NPT. Can't generate it in many cases. > - HS: How do you do Tivo like model? > - HS: From whereever you started recording to now. > - CP: It's not quite that simple. You can play past the pause point > because the Tivo is still recording. > - HS: Dont' want to break the spec. Don't want to label things. > Because you may have part live and part not live. > - MW: Two aspects. We need something new, but we can't break range. > - HS: If range abs time doesnt support this model. > - HS: If you use UTC, then you know if you are asking for a time > tomorrow then it is live. > - CP: How about clock skew. > - HS: If we can do time till now, it works with the Tivo Case. > - TZ: If you say UTC -, then the slider size is going to be hard to > determine. > - HS: a user interface issue. > Conclusion: > + In the SDP range if there is an open range, then it is > live. We need > to check the Tivo case is supported > + Need Live media defintion: media with out a defined end > point during > playback. > + SDP is referencing RTSP for range format. Need to > register with IANA. > > 2.F REDIRECT with Connetion close: > - MW: Normally connection is closed by the client. The server may > close the connection after 200k is recieved. > - TZ: a bit rude bit its fine. > Conclusion: Server MAY drop the connection after it has > recieved 200 OK > response on a REDIRECT. > > 2G. End of Stream > - TZ: Need a persistant connection > - MW: Is there a usecase in SIP for End of playout notification? > - HS: There Is media level, application level and , session level > - HS: It is hard to dectect the last packet stream. > Technically hard. > - HS: What is the use case for needing end of stream in the > RTP/RTCP? > End of segment/ End of stream is it a more generic problem? > - TZ: This is more like an event. > - HS: DTMF-AD was trying to signal time synchornized notification. > Not universally popular. > - TZ: Not event registration frame work. Is something like > SIP event > framework overkill? > - AN: The client in RTSP doesnt know the media has ended if you play > Range - > - TZ: Also for live. > - AN: but the live server doesnt know when the range ends > - HS: How about send an announce with the new SDP that stream's end > range has changed? > - HS: How about BYE > - TZ: Don't wnat to do BYE because it gets rid of the SSRC > and you want > to keep RTCP reporting. > - TZ: Also want to report error > - HS: Make that generic. Is the consumer a machine or is it > for human > user? > - AN: Once persistence is established you can add all kinds > of server > reporting features. > - SS: Almost always it will be a machine that will consume the error > information. > - TZ: A more generic framework for header that can be in end > of stream > and in Announce. > - HS: Use Announce to send the SDP with the new range header > - TZ: You dont need the whole range header. What I said was: You don't need the whole SDP here, just an updated Range plus Reason header. > You alredy have > have SDP. > - HS: You have a trade of with efficiently and future > supoprt. Try to > overly optimize is not a good idea. > - AN: No reason why RTCP can't say end of stream as a separate thing. > - HS: Yes. But keep it separarte and have AVT work on it. > - MW: Use ANNOUNCE. to do this. Revivie Sean's old spec. > Conclusion: Keep the end of stream messages in the control channel > rather than the data chanel. TZ will take ownership. > - Keep the idea of server trying to start a coneection with > client as a > separate issue. > > 2H. How long to wait for response? > - SS: 5 Seconds? > - HS: 10 times longer than SIP. > - SS: This is RTSP over TCP. UDP is lot longer > - HS: 100 is a indication that it will succeed. You want to send it > early rather than later. So 5 seconds may be too long. > - TS: The first 100 response is easy. Do we need to send it > periodically. > - HS: There is a reasons to send useful feedback, but do we need to > send more than that. > - HS: Should not be mandated > - AN: Server MAY / SHOULD send 100, but client MUST deal with it. > - CP: If the server knows its going to take appreciable > amount of time, > send 100 immediately (less than 2 seconds). > - TZ: Sean's proposal is reasonable. > - CP: If the server should send in a "couple" of seconds. > - CP: It's hard to place a time limit. > - TZ: Implementor's guide. > - HS: Not a good idea because it's hard to do, and may > contradict the spec. > - TZ: Provide some motivation example. > Conclusion: Sean's writeup seems reasonable. Change the > timelimit to 2 > seconds and make sure that wording is there to indicate > server should do > this immediately if it know it's going to take a long time. Need > motivation example. > > 2I. Version number of new spec > - MW: will try to make it 1.0 > - HS: Protocols don't generally get a second chance > - HS: If you want to go with a new protocol version than get > some better > features. > - TZ: There are servers out there that wont interop. > - CP: Document where the potential interop problems will be. > - AN: We will be hard pressed to keep the current version > number. But > let's see after the change spec is done. > > 2J. Teardown * and Ready-nm > - Removed from spec. Awaiting WG review > > 2K. How to handle sync in re-SETUP > - Awaiting review from the WG. > - Need to look at the level of mandate for RTP-Info in live case. > > 2L. Re-Setup of Transport parameters > - GS: Not to unicast -> multicast. > - HS: May want to switch from multicast to unicast. . . > - MW: Take to list. > > 2M. Removal of SETUP in play state > - Removed from spec. > - CP: Keep it unspecified rather then saying that it cannot > be done. > That breaks being able to do that in the future. > - AN: Explicitly state that it is unspecified instead of > cant be done. > Conclusion: Remove but state that it is unspecified and a new draft > needs to be writted to make it work. > > 2N. Use of c= in SDP to know possible address classes > - CP: It is reasonable to connet to the server with one > protocol and use > a different protocol for the media. > - TZ: Is it reasonable to have two, (one for IPv4, and one for IPv6). > - CP: You can specify alternatives. > - MW: 3338+gonzolo. Use the alt group thing. > > Conclusion: > Should look at address classes in the SDP to figure what > protocol to use > (need to add SDP section of RTSP) > Look at c= line syntax. Multiple c lines can be use in media field? > SIP resolution was that multiple c lines should not be used > to express > multiple connection address. > > 2O. How should proxies cache? OPTIONS. > Conclusion: > Caching dropped. make it explicitly unspecified in the spec. > > 3A. ABNF should be moved to end. > - HS: Difficult problem with SIP spec is that the when the semantic > description is given, it should reference ABNF name. > - CP: IETF has tools as well has henning. > > 3B. . . . > > 4. How to do RTSP over NAT? > > NAT Requirements? > Priorities: > 1. Server is deployed in open network. > 2. Server behind firewall next. > 3. If a client is not dual hosted, If a client is neither behind NAT/FW, nor dual-hosted, it should not have to pay additional price (in terms of delay, at least). > it should not have to deal with > additional protocols. > 4. Must have defense against DOS > 5. Security. > 6. MUST deal with symmetric nat. > 7. ALG. The firewall traversal should not interfere with ALGs. > 8. Advise to ALG writers not to screw it up. > > Aravind > > > _______________________________________________ > 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 Nov 12 16:41:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11451 for ; Wed, 12 Nov 2003 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 1AK2jX-00012Y-Qu for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 16:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLf3Om003992 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 16:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2jX-00012J-MY for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:41: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 QAA11440 for ; Wed, 12 Nov 2003 16:40:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2jV-0006ww-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:41:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK2jV-0006wt-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 16:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2jV-00011o-NC; Wed, 12 Nov 2003 16:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2j5-000114-5x for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 16:40: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 QAA11419 for ; Wed, 12 Nov 2003 16:40:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2j2-0006wj-00 for mmusic@ietf.org; Wed, 12 Nov 2003 16:40:32 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AK2j1-0006wg-00 for mmusic@ietf.org; Wed, 12 Nov 2003 16:40:32 -0500 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AK2j0-0007Sr-00; Wed, 12 Nov 2003 13:40:30 -0800 Date: Wed, 12 Nov 2003 13:40:30 -0800 From: Tom Marshall To: Aravind Narasimhan Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP offline meeting Notes - 11/11 Message-ID: <20031112214030.GA28520@real.com> References: <3FB29CEA.3030208@sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <3FB29CEA.3030208@sun.com> User-Agent: Mutt/1.5.4i 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: , --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > 2D. Aggregate URL deriving > - Awaiting review.=20 > - HS: Is there motivation for deriving the URL? It should be opaque? = =20 > I can't use for something else? > - TZ: It might conflict with an actual URL? > - HS: Seems like a recipie for strange cases. > - TZ: SDP from two different sources that you want to mix. > - HS: The server should give you the URL. If the SDP doesn't have an=20 > aggregate URL than the media can't be played in aggregate fashion. > - HS: Concerned about specifying generating URL. How do you know what= =20 > you are getting? What if it is not there? > - TZ: Have SETUP two separate streams. Need to control together.=20 > Session ID should be enough, but URL is needed for PLAY request. > - AN: URL is used for proxies and accounting. > - CP: State explicitly what needs to be done. > - HS: Server needs to accept the need to do it. > - CP: Imposing rules on URL is hard. Nontraditional URIs. What do you = do. > - HS: Toss this feature and verbiage from the spec. because it is hard= =20 > to specify. > - MW: Leave it as open issue. See if Tom has issue. But will remove=20 > from spec if no objections. > Conclusion: Hard feature to specify. We should not try to do it=20 > because we will do a poor job of it. Will remove from spec if no=20 > objections. I don't have any objection either way here. It would be nice if we could provide a recommendation to make this work but if not, it's not a big deal.= =20 There is no real-world use case as far as I can tell. My theoretical use case (playing audio from one file and video from another) is not supported by our server. If a use case pops up, the implementor can deal with it. > 2G. End of Stream > - TZ: Need a persistant connection > - MW: Is there a usecase in SIP for End of playout notification? > - HS: There Is media level, application level and , session level > - HS: It is hard to dectect the last packet stream. Technically hard. > - HS: What is the use case for needing end of stream in the RTP/RTCP? = =20 > End of segment/ End of stream is it a more generic problem? > - TZ: This is more like an event. > - HS: DTMF-AD was trying to signal time synchornized notification. =20 > Not universally popular. > - TZ: Not event registration frame work. Is something like SIP event=20 > framework overkill? > - AN: The client in RTSP doesnt know the media has ended if you play=20 > Range - > - TZ: Also for live. > - AN: but the live server doesnt know when the range ends > - HS: How about send an announce with the new SDP that stream's end=20 > range has changed? > - HS: How about BYE > - TZ: Don't wnat to do BYE because it gets rid of the SSRC and you want= =20 > to keep RTCP reporting. > - TZ: Also want to report error > - HS: Make that generic. Is the consumer a machine or is it for human= =20 > user? > - AN: Once persistence is established you can add all kinds of server=20 > reporting features. > - SS: Almost always it will be a machine that will consume the error=20 > information. > - TZ: A more generic framework for header that can be in end of stream= =20 > and in Announce. > - HS: Use Announce to send the SDP with the new range header > - TZ: You dont need the whole range header. You alredy have have SDP. > - HS: You have a trade of with efficiently and future supoprt. Try to= =20 > overly optimize is not a good idea. > - AN: No reason why RTCP can't say end of stream as a separate thing. > - HS: Yes. But keep it separarte and have AVT work on it. > - MW: Use ANNOUNCE. to do this. Revivie Sean's old spec. > Conclusion: Keep the end of stream messages in the control channel=20 > rather than the data chanel. TZ will take ownership. > - Keep the idea of server trying to start a coneection with client as a= =20 > separate issue. If we take an END_OF_STREAM proposal, I think it should be an extension signalled by a feature tag. I believe this is a deficiency in the RTP transport and we should bring the issue up in AVT. We have heard from someone that has implemented a transport level stream end notification so we know that it's both possible and deployed. We also know that END_OF_STREAM has issues with connectionless control that a transport solution does not. > 2H. How long to wait for response? > - SS: 5 Seconds? > - HS: 10 times longer than SIP. > - SS: This is RTSP over TCP. UDP is lot longer > - HS: 100 is a indication that it will succeed. You want to send it=20 > early rather than later. So 5 seconds may be too long. > - TS: The first 100 response is easy. Do we need to send it periodicall= y. > - HS: There is a reasons to send useful feedback, but do we need to=20 > send more than that. > - HS: Should not be mandated > - AN: Server MAY / SHOULD send 100, but client MUST deal with it. > - CP: If the server knows its going to take appreciable amount of time,= =20 > send 100 immediately (less than 2 seconds). > - TZ: Sean's proposal is reasonable. > - CP: If the server should send in a "couple" of seconds. > - CP: It's hard to place a time limit. > - TZ: Implementor's guide. > - HS: Not a good idea because it's hard to do, and may contradict the sp= ec. > - TZ: Provide some motivation example. > Conclusion: Sean's writeup seems reasonable. Change the timelimit to 2= =20 > seconds and make sure that wording is there to indicate server should do= =20 > this immediately if it know it's going to take a long time. Need=20 > motivation example. Please see my message from a few minutes ago. I don't think RTT measurements are meaningful. In addition to being unaware of the physical layer and TCP retransmission delays, this proposal makes it clear that servers have real and occasionally significant processing delays. This makes any RTT measurement extremely unreliable. I think that we should drop the RTT measurements and focus on the actual issue, which is total delay seen by the client. I have implementation concerns with using 100 responses on the server side.= =20 As an example, our server is highly asynchronous. It does nonblocking reads and writes on all I/O, including files. Further, complex datatypes (such as mpeg4) require quite a few read/seek operations to formulate an SDP for the DESCRIBE response. Now suppose the server is busy. Really busy. It's taking, say, 100ms or so to process all of its events each time through its main event loop. The server doesn't know how long it is going to take to formulate the SDP because it doesn't know exactly how many reads it will take. And to make matters worse, sending 100 responses both generates more network traffic and more event traffic (you need to set a timer so that you know when the response is taking too long). It may even make the difference between handling the requests and failing. Is sending one or more 100 responses really the best thing to do in this situation? --=20 Most people are too busy to have time for anything important. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/sqjOqznSmcYu2m8RAvz6AJ97P9CxMt6nJeDTXW+RMjB8Cmq3TwCdEC9g 1B7ysykYu9h40tQcror4SVk= =7SAl -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 17:15:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12841 for ; Wed, 12 Nov 2003 17:15: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 1AK3GW-0003VW-Fb for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 17:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACMF8R8013481 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 17:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3GV-0003VM-RZ for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:15: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 RAA12815 for ; Wed, 12 Nov 2003 17:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3GT-0007WY-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 17:15:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK3GS-0007WV-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 17:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3GQ-0003Uo-P4; Wed, 12 Nov 2003 17:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3Ft-0003UH-Rz for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 17:14: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 RAA12794 for ; Wed, 12 Nov 2003 17:14:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3Fr-0007Vv-00 for mmusic@ietf.org; Wed, 12 Nov 2003 17:14:27 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AK3Fq-0007Vs-00 for mmusic@ietf.org; Wed, 12 Nov 2003 17:14:26 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACMEOSs006147; Wed, 12 Nov 2003 23:14:25 +0100 (MET) Received: from ericsson.com (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WYRF4X2J; Wed, 12 Nov 2003 23:15:06 +0100 Message-ID: <3FB2B010.7010301@ericsson.com> Date: Wed, 12 Nov 2003 23:11:28 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aravind Narasimhan CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP offline meeting Notes - 11/11 References: <3FB29CEA.3030208@sun.com> In-Reply-To: <3FB29CEA.3030208@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, some comments, removing any sections without comments: Aravind Narasimhan wrote: > > 2E: A=range in SDP indicates live media > - HS: An undefined range means there is no defined a range forward or > back. > - GS: How about RTP-Info. Does it go away? > - MW: You need RTP-Info > - AN: Server does not know NPT. Can't generate it in many cases. > - HS: How do you do Tivo like model? > - HS: From whereever you started recording to now. > - CP: It's not quite that simple. You can play past the pause point > because the Tivo is still recording. > - HS: Dont' want to break the spec. Don't want to label things. > Because you may have part live and part not live. > - MW: Two aspects. We need something new, but we can't break range. > - HS: If range abs time doesnt support this model. > - HS: If you use UTC, then you know if you are asking for a time > tomorrow then it is live. > - CP: How about clock skew. > - HS: If we can do time till now, it works with the Tivo Case. > - TZ: If you say UTC -, then the slider size is going to be hard to > determine. > - HS: a user interface issue. > Conclusion: + In the SDP range if there is an open range, then it is > live. We need to check the Tivo case is supported > + Need Live media defintion: media with out a defined end point > during playback. > + SDP is referencing RTSP for range format. Need to register with IANA. I think that we had a conclusion to write a informative note about TIVO scenario signalling using large future values. The question is how this relates to the range limitations and what happens when a client asks for a futuer point. As I can see it the server can answer with what it actually will play out. > > 2G. End of Stream > - TZ: Need a persistant connection > - MW: Is there a usecase in SIP for End of playout notification? > - HS: There Is media level, application level and , session level > - HS: It is hard to dectect the last packet stream. Technically hard. > - HS: What is the use case for needing end of stream in the > RTP/RTCP? End of segment/ End of stream is it a more generic problem? > - TZ: This is more like an event. > - HS: DTMF-AD was trying to signal time synchornized notification. > Not universally popular. > - TZ: Not event registration frame work. Is something like SIP event > framework overkill? > - AN: The client in RTSP doesnt know the media has ended if you play > Range - > - TZ: Also for live. > - AN: but the live server doesnt know when the range ends > - HS: How about send an announce with the new SDP that stream's end > range has changed? > - HS: How about BYE > - TZ: Don't wnat to do BYE because it gets rid of the SSRC and you > want to keep RTCP reporting. > - TZ: Also want to report error > - HS: Make that generic. Is the consumer a machine or is it for > human user? > - AN: Once persistence is established you can add all kinds of server > reporting features. > - SS: Almost always it will be a machine that will consume the error > information. > - TZ: A more generic framework for header that can be in end of > stream and in Announce. > - HS: Use Announce to send the SDP with the new range header > - TZ: You dont need the whole range header. You alredy have have SDP. > - HS: You have a trade of with efficiently and future supoprt. Try > to overly optimize is not a good idea. > - AN: No reason why RTCP can't say end of stream as a separate thing. > - HS: Yes. But keep it separarte and have AVT work on it. > - MW: Use ANNOUNCE. to do this. Revivie Sean's old spec. > Conclusion: Keep the end of stream messages in the control channel > rather than the data chanel. TZ will take ownership. > - Keep the idea of server trying to start a coneection with client as > a separate issue. > > 2H. How long to wait for response? > - SS: 5 Seconds? > - HS: 10 times longer than SIP. > - SS: This is RTSP over TCP. UDP is lot longer > - HS: 100 is a indication that it will succeed. You want to send it > early rather than later. So 5 seconds may be too long. > - TS: The first 100 response is easy. Do we need to send it > periodically. > - HS: There is a reasons to send useful feedback, but do we need to > send more than that. > - HS: Should not be mandated > - AN: Server MAY / SHOULD send 100, but client MUST deal with it. > - CP: If the server knows its going to take appreciable amount of > time, send 100 immediately (less than 2 seconds). > - TZ: Sean's proposal is reasonable. > - CP: If the server should send in a "couple" of seconds. > - CP: It's hard to place a time limit. > - TZ: Implementor's guide. > - HS: Not a good idea because it's hard to do, and may contradict the > spec. > - TZ: Provide some motivation example. > Conclusion: Sean's writeup seems reasonable. Change the timelimit to > 2 seconds and make sure that wording is there to indicate server > should do this immediately if it know it's going to take a long time. > Need motivation example. I think we ad more discussion in the direction that we don't need exact rules for clients on how long they should wait, rather clarify why the client should wait sufficently long. > > 2I. Version number of new spec > - MW: will try to make it 1.0 > - HS: Protocols don't generally get a second chance > - HS: If you want to go with a new protocol version than get some > better features. > - TZ: There are servers out there that wont interop. > - CP: Document where the potential interop problems will be. > - AN: We will be hard pressed to keep the current version number. But > let's see after the change spec is done. I think the hennings important comments, that a solution if one creates non-interoperable changes to document them and explain how to support them, but clearly show that they are deprecated and can be removed at a later stage when old implementation has been upgraded. > 3B. . . . This will be included due to 2N. Cheers Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 12 22:07:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24264 for ; Wed, 12 Nov 2003 22:07:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7p2-0005g3-SK for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 22:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD374r9021796 for mmusic-archive@odin.ietf.org; Wed, 12 Nov 2003 22:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7p1-0005fT-Fy for mmusic-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:07: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 WAA24258 for ; Wed, 12 Nov 2003 22:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7oy-00048M-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 22:07:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7ox-00048J-00 for mmusic-web-archive@ietf.org; Wed, 12 Nov 2003 22:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7oy-0005dQ-W3; Wed, 12 Nov 2003 22:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7oq-0005cw-Tl for mmusic@optimus.ietf.org; Wed, 12 Nov 2003 22:06: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 WAA24254 for ; Wed, 12 Nov 2003 22:06:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7on-00048G-00 for mmusic@ietf.org; Wed, 12 Nov 2003 22:06:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AK7on-00047q-00 for mmusic@ietf.org; Wed, 12 Nov 2003 22:06:49 -0500 Received: from cisco.com (sjc-vpn4-48.cisco.com [10.21.80.48]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAD36HrX010325; Wed, 12 Nov 2003 19:06:17 -0800 (PST) Message-ID: <3FB2F528.4C3BBD97@cisco.com> Date: Wed, 12 Nov 2003 22:06:16 -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: "mmusic@ietf.org" CC: Dan Wing , Mark Baugher Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA24255 Subject: [MMUSIC] SDP security descriptions - updates and open issues in -02 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Greetings We submitted an update to the SDP Security Descriptions draft which you can find at: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-02.t= xt The draft was reworked to more clearly divide it into two: - A core security description framework - An SRTP profile of the security description core. For each of these, details on high-level operation, parameter definitions, use with and without offer/answer, and a grammar was provided. Also, the following more detailed changes were introduced: - Offer/Answer highlights differences between unicast/multicast, and initial/subsequent offer. - Rekeying addressed via offer/answer; everything can be changed (not just keys) - Additional rules and considerations for communicating the SRTP SRC parameter (SSRC, SEQ, ROC). - Removed SRTP =93use=94 parameter (decryption, encryption or both) - now inferred from context - Added Window-Size Hint and to SRTP profile - Extension rules were defined for key methods, SRTP crypto-suites, and SRTP session parameters - IANA considerations and registration procedures were added - Grammar was updated Finally, in Section 9 (and in a couple of places throughout the document), we identified the following open issues: 1) The use of security descriptions, and in particular SRTP security descriptions, with multicast streams where offer/answer is being used is not well understood and results in several complications. 2) Another aspect related to multicast is the SRC parameter which is used to instantiate crypto contexts. The question is how this parameter should be used with multicast streams, and in particular if it should be allowed to instantiate multiple crypto context. There is also an issue here in how to deal with "SSRC collisions" which is primarily a concern for multicast. 3) The security descriptions do not deal with hierarchically encoded streams (or at least they have not been considered). Note that this is only an issue for multicast streams. 4) The current mechanism does not allow for a key to be specified as being an encryption or decryption key or both; instead this is inferred from the context (e.g. unicast offer). Should there be a mechanism to allow a key to be tagged as an encryption, decryption or both key ? Again, this is mostly seen as an issue for multicast streams. Support for multicast streams is at the heart of these issues, and solving them in a way that is satisfactory to multicast in general is something the authors believe will require considerable work and result in a significant delay in progressing the draft. We therefore propose to restrict the scope of the draft to deal with unicast streams only and leave support for multicast streams for further study. If there is sufficient interest in solving all the multicast issues, these can then be worked on in a seperate document that can still use the general mechanism defined in the current draft. Please let us know if you disagree with this proposal. Thanks and regards Flemming, Mark, and Dan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 13 00:54:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29752 for ; Thu, 13 Nov 2003 00:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAQf-0007mx-7y for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 00:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD5s5BZ029935 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 00:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAQf-0007mk-4P for mmusic-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 00:54: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 AAA29725 for ; Thu, 13 Nov 2003 00:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKAQc-0006bM-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 00:54:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKAQb-0006bJ-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 00:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAQb-0007m9-Ee; Thu, 13 Nov 2003 00:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAPk-0007kq-6V for mmusic@optimus.ietf.org; Thu, 13 Nov 2003 00:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29659 for ; Thu, 13 Nov 2003 00:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKAPh-0006ZS-00 for mmusic@ietf.org; Thu, 13 Nov 2003 00:53:05 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AKAPg-0006Ya-00 for mmusic@ietf.org; Thu, 13 Nov 2003 00:53:04 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id hAD5qMio035800; Wed, 12 Nov 2003 21:52:22 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 21:52:21 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17CBC@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , Jonathan Rosenberg , IETF MMUSIC WG Subject: [MMUSIC] Comment on draft-ietf-mmusic-ice-00.txt Date: Wed, 12 Nov 2003 21:52:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi Jonathan: I finally got around to go through your draft. As always, I enjoy your writing style very much, plus that this version is much improved than the previous one. Some comments (more or less from RTSP perspective): 1. Section 5.1, last paragraph: There is a statement: "However, in order to communicate with the peer, at least one of the offered addresses has to be guaranteed to work with any peer that might be called. This generally requires that at least one of the derived addresses be obtained from a relay service (such as TURN) that exist within the public Internet." I don't agree this statement. Consider the case of RTSP streaming, if the server is in the open, and client behind NAT, I fail to see the need to require "relay service (such as TURN)". 2. Section 5.5, page 13, also on page 14, 3rd paragraph There is a statement: "This BindingRequest MUST contain the USERNAME attribute, and the value of the USERNAME MUST equal the username from that alternate element. Similarly, the BindingRequest MUST contain a PASSWORD attribute, and the value of the PASSWORD MUST equal the password from the alternate element." Why can't a USERNAME be globally unqiue for each RTP and RTCP port? That way USERNAME alone is enough to figure out the alternate. Inclusion of password in the BindingRequest is a security compromise (especially that such message is sent in the clear), and it contradicts rfc3489, section 9.3, where the password is not included in the BindingRequest. It is important not to send password in the open. 3. Also page 13: on the lock down problem, the solution I see would be to have multiple TURN servers available, so as to make it possible to try alternates in parrellel. TURN servers in general are not very scalable any way, so it is not unthinkable to deploy multiple STUN servers ... 4. section 6.2 second paragraph: The scenario described is not going to work for symetric NAT, am I correct? If so, it probably is useful to state it explicitly. 5. Section 7: xml schema for ICE Messages: There is one attribute ("extension base?") called "rtp-info". Does this have anything to do with "rtp-info" in RFC2326? It doesn't match the parameters in rfc2326's Rtp-info header. I suspect this to be a name space conflict? 6. It would nice to have a mapping from ICE to RTSP. thanks, thomas > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, November 07, 2003 7:49 AM > To: Jonathan Rosenberg; IETF MMUSIC WG > Subject: [MMUSIC] Comment on draft-ietf-mmusic-ice-00.txt > > > Hi Jonathan, > > I had a late night reading session yesterday that produce > some comments. > > 1. I think there are still maybe a few places where ICE is to > situation > specific towards SIP. I will not go so long to require that > mapping of > transport addresses are not IP + transport protocol ports as this is > what our NAT problem causes. However the constant reference to RTP > should probably be removed, there are at least other > proprietary media > protocols. So I think one should talk about media protocol instead of > RTP + RTCP. > > 2. I think some better motivation why the openly available > password in > the STUN request is acceptable. And then why the integrity protection > gives advantages or not. > > 3. When the responder performs his connectivity checks and > succeed, why > does the initiator need to perform a counter check also? Some more > should probably be spent on this. The initiator knows the > source address > as it sees it to send any packets to. The only piece of information > missing is what responder connection interface it goes to. > This could be > identified using STUN supplements and the response message > connection IDs. > > Then the only reasons for doing a counter check is to possibly enable > connectivity over a more prioritized connection. OR have I missed > something about this. > > 4. Of course not doing it both way will not provide full protection > against the RTP DOS attack. However you have not at all discussed the > applicability of ICE for RTP DOS prevention. > > 5. I also are not finding anything about the retrying in the > transmission of STUN request. Should these be done in any special way > for ICE? Also there is very little discussion about timer > consideration > for performing the connectivity checks. > > 6. In example 6.2 i think it can be easily expanded to show one > important functionality of ICE, the possibility to open up restricted > NAT through the usage of multiple ICE cycles. If A is behind a > restricted NAT it will be able to determine its outermost address and > port. However in cycle 1, B will not be able to reach A. When then A > tries B over the cycle this may succeed. Then B can verify this by > STUNNING a second time. These possibilities are rather tuned down. > > 7. I think the XML description should be more generic and > include 1..N > transport addresses for each media session. > > 8. If anyone missed the other message, the usage of "alt" has > a conflict > with 3GPP TS 26.234, Rel 6 preliminary specification. > > 9. I think there should be some example of the complete mesh ICE > actually tries. I know it will be a hard thing to draw using > ASCII art. > > 10. If one uses ICE for other purposes then UNSAF mechanism > it suddenly > will not have any exit strategy for that purpose. However it should > still be true that if no relays, etc. are need when people > has migrated > to IPv6, etc., then it will simply reduce the complexity of doing ICE. > > 11. When one performs ICE, are there any congestion control > considerations to make? If one digs up a number of address > locally the > local interface might need to send a lot of packets in a > short time as > it is desired to perform this in parallel. > > > Best Regards > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 13 10:12:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01416 for ; Thu, 13 Nov 2003 10:12:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ8d-0001GH-TA for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 10:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFC3o2004843 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 10:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ8d-0001G2-NJ for mmusic-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:12: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 KAA01350 for ; Thu, 13 Nov 2003 10:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJ8a-0006Xt-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 10:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJ8a-0006Xn-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 10: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 1AKJ8b-0001FC-FS; Thu, 13 Nov 2003 10: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 1AKJ7d-00019p-O7 for mmusic@optimus.ietf.org; Thu, 13 Nov 2003 10:11: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 KAA01195 for ; Thu, 13 Nov 2003 10:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJ7b-0006Vh-00 for mmusic@ietf.org; Thu, 13 Nov 2003 10:10:59 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKJ7W-0006Va-00 for mmusic@ietf.org; Thu, 13 Nov 2003 10:10:58 -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 hADF9lEf018167; Thu, 13 Nov 2003 16:09:49 +0100 (MET) Message-ID: <3FB39F67.2020300@tzi.uni-bremen.de> Date: Thu, 13 Nov 2003 16:12:39 +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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Slides for tomorrow's session 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 All presenters in tomorrow's MMUSIC session: please send us a copy of your slides in PS, PDF or PPT (PPT preferred) until 8am tomorrow morning. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 13 18:02:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26322 for ; Thu, 13 Nov 2003 18:02:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQTV-0006cz-0W for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 18:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADN24Iq025473 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 18:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQTU-0006cm-T5 for mmusic-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:02: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 SAA26291 for ; Thu, 13 Nov 2003 18:01:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQTS-0007JN-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 18:02:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQTR-0007JJ-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 18: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 1AKQTR-0006bv-Mz; Thu, 13 Nov 2003 18: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 1AKQSj-0006Zr-4f for mmusic@optimus.ietf.org; Thu, 13 Nov 2003 18:01: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 SAA26278 for ; Thu, 13 Nov 2003 18:01:03 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQSg-0007Ix-00 for mmusic@ietf.org; Thu, 13 Nov 2003 18:01:14 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AKQSf-0007Iu-00 for mmusic@ietf.org; Thu, 13 Nov 2003 18:01:13 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADN1D608773 for ; Fri, 14 Nov 2003 01:01:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Nov 2003 01:01:13 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Nov 2003 01:01:13 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 01:01:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Nov 2003 01:01:12 +0200 Message-ID: <2BF0AD29BC31FE46B7887732114404310357E7DC@trebe003.europe.nokia.com> Thread-Topic: IMG in mpls Thread-Index: AcOlRusnLukDbxfuQqCgLjZ0o7ouxQDq6cvQAE328LA= To: X-OriginalArrivalTime: 13 Nov 2003 23:01:12.0980 (UTC) FILETIME=[08D97540:01C3AA3A] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Internet Media Guide comments from Brit's Pub 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 Hi Everyone We had an IMG "design team bar bof" with Colin & Joerg on IMG in the = Brit's Pub and collected multiple review comments face-to-face. We're = updating the IMG requirements and framework and will release updated IDs = ASAP. Please review and comment the documents by email (and also tomorrow = morning if you're with us in Minneapolis). Here's a summary of the comments and some responses over the good old = Internet...=20 Cheers, Rod. --- *** IMG Document Review, IETF-58 / 10.November.2003 / Brit's Pub *** =3D=3D Requirements Draft =3D=3D RQ1. requirements should be numbered to make it easy to reperence (and = identify) them RQ2. "Agnostic" can have some negative conertainions so swap "agnostic" = for "supports many different ones". RQ3. Make it explicit that we assume many more receivers than senders as = it's important to make the primary use clear. RQ4. The receiver can be intermittently connected but it is unclear = whether the document is saying the sender could be too. Show the = assumption that, for the duration of interest, the sender is continually = connected. RQ5. Customizing and Scalability are somewhat exclusive. For general = scalability we are talking of possibly millions of users, for = customisation involving receiver -> sender/network messaging we can = expect scalability to considerably smaller numbers. RQ6. There are a few requirements draft terminology problems... The term IMG -> changed to IMG metadata where appropriate, and IMG and = IMG metadata definitions updated/added: IMG networks -> networks IMG transport -> IMG transport protocol IMG system -> clarified in places complete IMG knowledge -> complete IMG metadata knowledge IMG originators -> IMG senders IMG components -> IMG entities IMG content -> IMG metadata =3D=3D IMG Framework =3D=3D FW1. 3.2 is conent use cases. The use of the term "file" was verified in = 3.2.1 - it (correctly) refers to a content type which maybe described = (and have it's transport media described) in IMG metadata. Minor chanes = to emphasis this will be made. FW2. Where to put use cases - it was felt that they're ok where they are FW3. A "reference/pointer" to an IMG delivery session would be useful - = it gives for descriptors to define an IMG delivery session. (an SDP = descriptor?) Clarification for this is added in 4.1.3. FW4. Framework should not mix the description of IMGs with what is in = the IETF scope and what is not. Thus the two are now seperated. FW5. [Note - several other standards bodies could be good places for = application specific metadata] FW6. We condisered and change the "SHOULD" to "MUST" for the requirement = on authenticating fragments of IMG metadata study the feasibility and = imply options -> Relates, especially, to transceiver/proxy issues of = middlebox fragmentation, reassembly, aggregation, and augmentation. I.e. = can a middlebox authenticate original parts of the metadata with the = original source 'signature' and new/modified parts with it's own = 'signature'. Generally it's not going to be needed. If it is, the = middlebox either gets the source to re-sign the fragment, or the = original metadata must be reasonably fragmented already (allowing the = middlebox to replace a small fragment without changing the authenticity = of the remainder). Easy fixes in the req doc. FW7. It's "IMG in IETF" scope to look at IMG Delivery (link traversing), = whereas it is not "IMG in IETF" scope to standardise = application-specific metadata including data models. This practically = means multicast transport (=A76.3.1), Usage of Unicast Transport = Protocols (=A76.3.2) and The Metadata Envelope (=A76.3.3) are = recommended for IETF work items. Whereas for the Baseline (Meta)Data = Model Specification (=A76.3.4) we acknowledge the need to exchange and = agree on a baseline metadata model and application specific metadata for = the purposes of interoperability testing between different = implementations of IMG related IETF protocols - but the IETF standards = process is not required for this. FW8. Each connectity/network use case should show that unicast or = multicast is needed, which they do FW9. identifier - URL in HTTP, what about delta? how to describe the = correlations? Identifier is likely to be a URI in all cases. Same ID for = deltas, just that the payload type (in metadata envelope) would be = different. We also discussed that SDP-delta would need to be a different = type from SDP. Solution belongs to the metadata envelope spec. FW10. Framework draft terminology problems proxy -> deleted IMG information -> IMG metadata IMG protocol -> IMG transport protocol (in 2/3 places) announcement protocol -> added a note that SAP is an announement = protocol, but don't really need to define a fixed term --- Comments are welcome! _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 13 18:11:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27737 for ; Thu, 13 Nov 2003 18:11:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQc9-0007ry-QA for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 18:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADNB16E030244 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 18:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQc9-0007rj-K5 for mmusic-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:11: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 SAA27675 for ; Thu, 13 Nov 2003 18:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQc6-0007Z2-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 18:10:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQc6-0007Yz-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 18:10:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQc8-0007q1-Bf; Thu, 13 Nov 2003 18:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQbS-0007oA-Pb for mmusic@optimus.ietf.org; Thu, 13 Nov 2003 18:10: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 SAA27593 for ; Thu, 13 Nov 2003 18:10:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQbP-0007Y5-00 for mmusic@ietf.org; Thu, 13 Nov 2003 18:10:15 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AKQbO-0007V5-00 for mmusic@ietf.org; Thu, 13 Nov 2003 18:10:14 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hADN8jUP024347 for ; Thu, 13 Nov 2003 15:08:45 -0800 (PST) Received: from jamba (jamba.Eng.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 <0HOB00AYWCAK1I@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 13 Nov 2003 15:08:45 -0800 (PST) Date: Thu, 13 Nov 2003 15:09:12 -0800 From: Geetha Srikantan To: mmusic@ietf.org Message-id: <1068764951.4490.221.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] comments on draft-ietf-mmusic-rfc2326bis-05.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, A few comments on the latest draft.. 1. Page 18, feature tags: It would be good to mention which ones are defined currently and refer to section 18 where they are described in detail. The text refers to several instances of feature-tags well before they are described..it's confusing for the reader. 2. Page 26: How does table 8.1 relate to entity tags? Am not sure if the table needs to be moved? 3. Page 60, last part of 13.4: "The headers value is valid....media supports." It's not clear what this means..might want to reword.. 4. RTP-Info for Live sessions - specification to be revisited (as discussed in the offline meeting on 11//11). 5. Hope that we can include some text specifying transport negotiation when we've decided what it is. geetha -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 13 18:51:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00200 for ; Thu, 13 Nov 2003 18:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKREt-0002oW-70 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 18:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADNp3tE010810 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 18:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKREt-0002oH-3B for mmusic-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:51: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 SAA00177 for ; Thu, 13 Nov 2003 18:50:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKREp-0000VB-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 18:50:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKREp-0000V8-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 18:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKREr-0002n1-Ih; Thu, 13 Nov 2003 18:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKREM-0002lI-8j for mmusic@optimus.ietf.org; Thu, 13 Nov 2003 18:50: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 SAA00133 for ; Thu, 13 Nov 2003 18:50:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKREJ-0000U1-00 for mmusic@ietf.org; Thu, 13 Nov 2003 18:50:27 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AKREI-0000Ty-00 for mmusic@ietf.org; Thu, 13 Nov 2003 18:50:26 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADNoPI2013289; Fri, 14 Nov 2003 00:50:26 +0100 (MET) Received: from ericsson.com (permit156.er.ki.sw.ericsson.se [147.214.97.156]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WYRGH9K7; Fri, 14 Nov 2003 00:51:10 +0100 Message-ID: <3FB418A2.6060304@ericsson.com> Date: Fri, 14 Nov 2003 00:49:54 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: mmusic@ietf.org Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-rfc2326bis-05.txt References: <1068764951.4490.221.camel@jamba> In-Reply-To: <1068764951.4490.221.camel@jamba> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, Geetha Srikantan wrote: >Hello, > >A few comments on the latest draft.. > >1. Page 18, feature tags: It would be good to mention which ones are > defined currently and refer to section 18 where they are described > in detail. The text refers to several instances of feature-tags > well before they are described..it's confusing for the reader. > I can understand this, there are probably a lot of these things that has to do with inconsistency of the whole draft. > >2. Page 26: How does table 8.1 relate to entity tags? Am not sure if > the table needs to be moved? > Table 1, are response codes. They do not relate to entity tags, however the table is floating to where it fits, accroding to Latex. > >3. Page 60, last part of 13.4: "The headers value is valid....media > supports." It's not clear what this means..might want to reword.. > Agree, it need some rewording. Proposal: "The server SHOULD indicate what range units it supports, for the given media resource in the SETUP response." Is this clearer? > >4. RTP-Info for Live sessions - specification to be revisited (as > discussed in the offline meeting on 11//11). > Yes. > >5. Hope that we can include some text specifying transport negotiation > when we've decided what it is. > > Yes, please review the proposed text, send comments to the mailing list. Cheers Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 13 20:47:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04071 for ; Thu, 13 Nov 2003 20:47:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT37-0002AO-Ph for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 20:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1l1nD008324 for mmusic-archive@odin.ietf.org; Thu, 13 Nov 2003 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT37-0002AB-K6 for mmusic-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:47: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 UAA04067 for ; Thu, 13 Nov 2003 20:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKT35-0002Hn-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 20:46:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKT34-0002Hi-00 for mmusic-web-archive@ietf.org; Thu, 13 Nov 2003 20:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT36-00029b-ID; Thu, 13 Nov 2003 20:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT2n-00028q-9m for mmusic@optimus.ietf.org; Thu, 13 Nov 2003 20:46: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 UAA04061 for ; Thu, 13 Nov 2003 20:46:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKT2k-0002HW-00 for mmusic@ietf.org; Thu, 13 Nov 2003 20:46:38 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AKT2j-0002Gr-00 for mmusic@ietf.org; Thu, 13 Nov 2003 20:46:38 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAE1jtUn027486 for ; Thu, 13 Nov 2003 17:46:08 -0800 (PST) Received: from jamba (jamba.Eng.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 <0HOB002BXJKP8R@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 13 Nov 2003 17:46:01 -0800 (PST) Date: Thu, 13 Nov 2003 17:46:28 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-rfc2326bis-05.txt In-reply-to: <3FB418A2.6060304@ericsson.com> To: Magnus Westerlund Cc: mmusic@ietf.org Message-id: <1068774387.4490.246.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit References: <1068764951.4490.221.camel@jamba> <3FB418A2.6060304@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 Magnus, I'm sure most of the editorial nits will get addressed in a couple of revs. More inline... On Thu, 2003-11-13 at 15:49, Magnus Westerlund wrote: > Hi Geetha, > > > >3. Page 60, last part of 13.4: "The headers value is valid....media > > supports." It's not clear what this means..might want to reword.. > > > > Agree, it need some rewording. Proposal: "The server SHOULD indicate > what range units it supports, for the given media resource in the SETUP > response." > Is this clearer? > sounds good.. > > > >4. RTP-Info for Live sessions - specification to be revisited (as > > discussed in the offline meeting on 11//11). > > > > Yes. > great.. > > > >5. Hope that we can include some text specifying transport negotiation > > when we've decided what it is. > > > > > > Yes, please review the proposed text, send comments to the mailing list. > I did take a look at the text in the draft..it looks good. I was hoping there would be some text to specify which transport parameters can be negotiated. It would be ok to leave out negotiation of some parameters to an extension document (such as multicast->unicast), however we should say so explicitly in the text? If people are in agreement wrt on which parameters to negotiate (see my note earlier), I can write up some text for this. > Cheers > > Magnus > > geetha > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 14 04:38:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03342 for ; Fri, 14 Nov 2003 04:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKaP1-0000ZH-4P for mmusic-archive@odin.ietf.org; Fri, 14 Nov 2003 04:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE9c6Vn002179 for mmusic-archive@odin.ietf.org; Fri, 14 Nov 2003 04:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKaOz-0000Yw-KU for mmusic-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 04:38: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 EAA03335 for ; Fri, 14 Nov 2003 04:37:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKaOw-0001wq-00 for mmusic-web-archive@ietf.org; Fri, 14 Nov 2003 04:38:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKaOw-0001wn-00 for mmusic-web-archive@ietf.org; Fri, 14 Nov 2003 04:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKaOv-0000Xm-O1; Fri, 14 Nov 2003 04: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 1AKaOh-0000V8-8M for mmusic@optimus.ietf.org; Fri, 14 Nov 2003 04:37:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03332 for ; Fri, 14 Nov 2003 04:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKaOe-0001wd-00 for mmusic@ietf.org; Fri, 14 Nov 2003 04:37:44 -0500 Received: from varis.cs.tut.fi ([130.230.4.42] helo=cs.tut.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AKaOd-0001wZ-00 for mmusic@ietf.org; Fri, 14 Nov 2003 04:37:43 -0500 Received: from kiuru.cs.tut.fi (peltotas@kiuru.cs.tut.fi [130.230.4.18]) by cs.tut.fi (8.12.10/8.12.8) with ESMTP id hAE9bhsZ004286 for ; Fri, 14 Nov 2003 11:37:43 +0200 (EET) Date: Fri, 14 Nov 2003 11:37:43 +0200 (EET) From: Peltotalo Sami To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] IMG metadata 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: , Hi, Has someone read Luoma's metadata dratf (http://www.ietf.org/internet-drafts/draft-luoma-mmusic-img-metadata-02.txt). My question concerns about the relational part of the IMG metadata. For example, we might have a use case where content providers (IP Service Portal in the metadata model) announce their own services (many IMG roots) and then IMG transceiver (see IMG framework draft) merges those to a single IMG root. I think this database might grow to quite big, and probably it is too large to be forwarded ahead for example in a single set of metadata. Has anyone ideas how the relational part of the metadata might be splitted into smaller pieces, which can then be gathered and rendered, in the receiver, as a service hierarchy? How does it sound, if the IMG transceiver sends a set of metadata, which informs the content providers, that are included in its IMG (database). After that, it sends the content providers' IMGs. This first set of metadata helps receivers to notice when they have reveived the complete IMG from the IMG transceiver. Metadata spec. says that there is root ID for IMG database. So for example in the above mentioned use case, the first content provider had ID one, and the second had ID two. Now the IMG transceiver's IMG database has ID three. So the IMG tranceiver sends the content providers' IMG with its own IMG root ID (three). Is this correct? Cheers, Sami _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 14 13:33:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23877 for ; Fri, 14 Nov 2003 13:33: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 1AKikq-0006B2-GA for mmusic-archive@odin.ietf.org; Fri, 14 Nov 2003 13:33:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEIXCAM023740 for mmusic-archive@odin.ietf.org; Fri, 14 Nov 2003 13:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKikq-0006Ap-CV for mmusic-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 13:33:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23863 for ; Fri, 14 Nov 2003 13:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiko-0002RE-00 for mmusic-web-archive@ietf.org; Fri, 14 Nov 2003 13:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKikn-0002Qy-00 for mmusic-web-archive@ietf.org; Fri, 14 Nov 2003 13:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKijh-000672-Iv; Fri, 14 Nov 2003 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKijN-00066m-4n for mmusic@optimus.ietf.org; Fri, 14 Nov 2003 13:31: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 NAA23795 for ; Fri, 14 Nov 2003 13:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKijK-0002Qo-00 for mmusic@ietf.org; Fri, 14 Nov 2003 13:31:38 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1AKijK-0002Ql-00 for mmusic@ietf.org; Fri, 14 Nov 2003 13:31:38 -0500 Received: from vit (dyn128-155.ietf58.ietf.org [130.129.128.155]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hAEIVZZ02425 for ; Fri, 14 Nov 2003 19:31:35 +0100 (CET) From: "Gunnar Hellstrom" To: Subject: [mmusic] Inclusion of media type = "text" in SDP Date: Fri, 14 Nov 2003 12:31:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id hAEIVZZ02425 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is a request for a minor addition to draft-ietf-mmusic-sdp-new-15.tx= t to acknowledge use of the media type "text" in sessions. An RTP transport for real time character by character transmission of tex= t was defined a couple of years ago in RFC2793. It is now successfully used in conversational applications, usually combi= ned with voice and/or video to enable the participants in the session to communicate in any preferred medium. One important user group is deaf and hard-of-hearing people, but the feature is of course of value for all. In the past, most multimedia implementors have been eager to create interoperability in video and audio, while the text part has been left behind and iimplemented as manufacturer specific message-oriented "chat"-additions. It is time for a change, to raise all the three media o= f video, text and audio to the same status of interoperability and deployme= nt. That will give SIP based conversational services a real benefit. This is also needed for the transcoding work. By mistake no registration of "text" as an allowed media in the m=3D descriptor of SDP has yet taken place. This was discussed in the mmusic meeting today, and the conclusion was that since it is already a MIME top level medium, it is just a matter of including it in the sdp document to make it allowed. Therefore I suggest the addition of the word "text" in the following thre= e places in draft-ietf-mmusic-sdp-new-15.txt . In discussion with Colin, we came to the conclusion that this action woul= d be sufficient for acknowledging the text medium. --------in section 5.14 ---------------------------------------------- 5.14 Media Announcements ("m=3D") m=3D A session description may contain a number of media descriptions. Each media description starts with an "m=3D" field, and is terminated by either the next "m=3D" field or by the end of the session description. A media field has several sub-fields. The first sub-field is the media type. Currently defined media are "audio", "video", "text", "application", "data" and "control", though this list may be extended in future. -----further down, same section ----------- The fourth and subsequent sub-fields are media formats. For audio text and video, these SHOULD reference a MIME sub-type describing the format under the "audio", "text" and "video" top-level MIME types. ------In Appendix A------------------------------ ; sub-rules of 'm=3D' media =3D token ;typically "audio", "video", "text", "application" ;or "data" ------End of proposal-----------------------------------------------------------------= --- -------- Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 15 17:05:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21409 for ; Sat, 15 Nov 2003 17:05: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 1AL8XW-0004rT-OO for mmusic-archive@odin.ietf.org; Sat, 15 Nov 2003 17:05:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFM5A0n018683 for mmusic-archive@odin.ietf.org; Sat, 15 Nov 2003 17:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL8XW-0004rG-KJ for mmusic-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 17:05: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 RAA21397 for ; Sat, 15 Nov 2003 17:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL8XT-0006WG-00 for mmusic-web-archive@ietf.org; Sat, 15 Nov 2003 17:05:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AL8XT-0006WC-00 for mmusic-web-archive@ietf.org; Sat, 15 Nov 2003 17:05:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL8XO-0004qi-C9; Sat, 15 Nov 2003 17:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKicc-0005Ii-J6 for mmusic@optimus.ietf.org; Fri, 14 Nov 2003 13:24: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 NAA23472; Fri, 14 Nov 2003 13:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKica-0002JC-00; Fri, 14 Nov 2003 13:24:40 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1AKicZ-0002Iz-00; Fri, 14 Nov 2003 13:24:39 -0500 Received: from vit (dyn128-155.ietf58.ietf.org [130.129.128.155]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hAEIOAZ19779; Fri, 14 Nov 2003 19:24:10 +0100 (CET) From: "Gunnar Hellstrom" To: "'Sipping@Ietf. Org'" , Cc: "Toip list" Subject: [mmusic] Inclusion of media type = "text" in SDP Date: Fri, 14 Nov 2003 12:24:12 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id hAEIOAZ19779 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is a request for a minor addition to draft-ietf-mmusic-sdp-new-15.tx= t to acknowledge use of the media type "text" in sessions. An RTP transport for real time character by character transmission of tex= t was defined a couple of years ago in RFC2793. It is now successfully used in conversational applications, usually combi= ned with voice and/or video to enable the participants in the session to communicate in any preferred medium. One important user group is deaf and hard-of-hearing people, but the feature is of course of value for all. In the past, most multimedia implementors have been eager to create interoperability in video and audio, while the text part has been left behind and iimplemented as manufacturer specific message-oriented "chat"-additions. It is time for a change, to raise all the three media o= f video, text and audio to the same status of interoperability and deployme= nt. That will give SIP based conversational services a real benefit. This is also needed for the transcoding work. By mistake no registration of "text" as an allowed media in the m=3D descriptor of SDP has yet taken place. This was discussed in the mmusic meeting today, and the conclusion was that since it is already a MIME top level medium, it is just a matter of including it in the sdp document to make it allowed. Therefore I suggest the addition of the word "text" in the following thre= e places in draft-ietf-mmusic-sdp-new-15.txt . In discussion with Colin, we came to the conclusion that this action woul= d be sufficient for acknowledging the text medium. --------in section 5.14 ---------------------------------------------- 5.14 Media Announcements ("m=3D") m=3D A session description may contain a number of media descriptions. Each media description starts with an "m=3D" field, and is terminated by either the next "m=3D" field or by the end of the session description. A media field has several sub-fields. The first sub-field is the media type. Currently defined media are "audio", "video", "text", "application", "data" and "control", though this list may be extended in future. -----further down, same section ----------- The fourth and subsequent sub-fields are media formats. For audio text and video, these SHOULD reference a MIME sub-type describing the format under the "audio", "text" and "video" top-level MIME types. ------In Appendix A------------------------------ ; sub-rules of 'm=3D' media =3D token ;typically "audio", "video", "text", "application" ;or "data" ------End of proposal-----------------------------------------------------------------= --- -------- Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 16 15:34:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07096 for ; Sun, 16 Nov 2003 15:34: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 1ALTZx-0004Uk-Bs for mmusic-archive@odin.ietf.org; Sun, 16 Nov 2003 15:33:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAGKX5DI017276 for mmusic-archive@odin.ietf.org; Sun, 16 Nov 2003 15:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALTZx-0004UZ-8C for mmusic-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 15:33:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07061 for ; Sun, 16 Nov 2003 15:32:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALTZv-0002fX-00 for mmusic-web-archive@ietf.org; Sun, 16 Nov 2003 15:33:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALTZv-0002fU-00 for mmusic-web-archive@ietf.org; Sun, 16 Nov 2003 15:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALTZs-0004Ts-VF; Sun, 16 Nov 2003 15:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALTZn-0004TW-FR for mmusic@optimus.ietf.org; Sun, 16 Nov 2003 15:32: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 PAA07055; Sun, 16 Nov 2003 15:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALTZl-0002fB-00; Sun, 16 Nov 2003 15:32:53 -0500 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx with esmtp (Exim 4.12) id 1ALTZl-0002eZ-00; Sun, 16 Nov 2003 15:32:53 -0500 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hAGKWNnc015101; Sun, 16 Nov 2003 12:32:23 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 16 Nov 2003 12:31:41 -0800 Received: from [17.202.35.52] (singeridsl2.apple.com [17.219.157.83]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id hAGKVrEY006415; Sun, 16 Nov 2003 12:31:56 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Sun, 16 Nov 2003 12:32:04 -0800 To: Gunnar Hellstrom , "'Sipping@Ietf. Org'" , mmusic@ietf.org From: Dave Singer Subject: Re: [mmusic] Inclusion of media type = "text" in SDP Cc: Toip list Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There is also the 3G timed text draft, of course,=20 and the upcoming MPEG and W3C work in timed text. At 12:24 PM -0600 11/14/03, Gunnar Hellstrom wrote: >This is a request for a minor addition to draft-ietf-mmusic-sdp-new-15.txt >to acknowledge use of the media type "text" in sessions. > >An RTP transport for real time character by character transmission of text >was defined a couple of years ago in RFC2793. >It is now successfully used in conversational applications, usually combine= d >with voice and/or video to enable the participants in the session to >communicate in any preferred medium. One important user group is deaf and >hard-of-hearing people, but the feature is of course of value for all. > >In the past, most multimedia implementors have been eager to create >interoperability in video and audio, while the text part has been left >behind and iimplemented as manufacturer specific message-oriented >"chat"-additions. It is time for a change, to raise all the three media of >video, text and audio to the same status of interoperability and deployment= =2E >That will give SIP based conversational services a real benefit. > >This is also needed for the transcoding work. > >By mistake no registration of "text" as an allowed media in the m=3D >descriptor of SDP has yet taken place. This was discussed in the mmusic >meeting today, and the conclusion was that since it is already a MIME top >level medium, it is just a matter of including it in the sdp document to >make it allowed. > >Therefore I suggest the addition of the word "text" in the following three >places in draft-ietf-mmusic-sdp-new-15.txt . >In discussion with Colin, we came to the conclusion that this action would >be sufficient for acknowledging the text medium. > > >--------in section 5.14 ---------------------------------------------- >5.14 Media Announcements ("m=3D") > > m=3D > > A session description may contain a number of media descriptions. > Each media description starts with an "m=3D" field, and is terminated > by either the next "m=3D" field or by the end of the session > description. A media field has several sub-fields. > > The first sub-field is the media type. Currently defined media are > "audio", "video", "text", "application", "data" and "control", though >this > list may be extended in future. > >-----further down, same section ----------- > > The fourth and subsequent sub-fields are media formats. For audio > text and video, these SHOULD reference a MIME sub-type describing the > format under the "audio", "text" and "video" top-level MIME types. > >------In Appendix A------------------------------ > >; sub-rules of 'm=3D' > media =3D token > ;typically "audio", "video", "text", >"application" > ;or "data" >------End of >proposal-------------------------------------------------------------------= - >-------- > >Regards > >Gunnar >------------------------------------------- >Gunnar Hellstr=F6m >Omnitor AB >Renathv=E4gen 2 >SE 121 37 Johanneshov >SWEDEN >+46 8 556 002 03 >Mob: +46 708 204 288 >www.omnitor.se >Gunnar.Hellstrom@Omnitor.se >-------------------------------------------- > > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic -- David Singer Apple Computer/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 16 18:45:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12035 for ; Sun, 16 Nov 2003 18: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 1ALWZp-0002la-14 for mmusic-archive@odin.ietf.org; Sun, 16 Nov 2003 18:45:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAGNj8dG010631 for mmusic-archive@odin.ietf.org; Sun, 16 Nov 2003 18:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALWZo-0002lO-RX for mmusic-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 18:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12027 for ; Sun, 16 Nov 2003 18:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALWZl-0004np-00 for mmusic-web-archive@ietf.org; Sun, 16 Nov 2003 18:45:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALWZl-0004nl-00 for mmusic-web-archive@ietf.org; Sun, 16 Nov 2003 18:45:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALWZi-0002kc-Dn; Sun, 16 Nov 2003 18:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALWYv-0002kC-VH for mmusic@optimus.ietf.org; Sun, 16 Nov 2003 18:44: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 SAA12007 for ; Sun, 16 Nov 2003 18:43:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALWYs-0004nB-00 for mmusic@ietf.org; Sun, 16 Nov 2003 18:44:10 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ALWYs-0004n7-00 for mmusic@ietf.org; Sun, 16 Nov 2003 18:44:10 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63642 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ALWYO-0001CA-00; Sun, 16 Nov 2003 23:43:40 +0000 Date: Sun, 16 Nov 2003 23:43:39 +0000 Subject: Re: [mmusic] Inclusion of media type = "text" in SDP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Gunnar Hellstrom" From: Colin Perkins In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Gunnar, On Friday, Nov 14, 2003, at 18:24 Europe/London, Gunnar Hellstrom wrote: > This is a request for a minor addition to > draft-ietf-mmusic-sdp-new-15.txt > to acknowledge use of the media type "text" in sessions. ... > Therefore I suggest the addition of the word "text" in the following > three > places in draft-ietf-mmusic-sdp-new-15.txt . > In discussion with Colin, we came to the conclusion that this action > would > be sufficient for acknowledging the text medium. > > > --------in section 5.14 ---------------------------------------------- > 5.14 Media Announcements ("m=") > > m= > > A session description may contain a number of media descriptions. > Each media description starts with an "m=" field, and is terminated > by either the next "m=" field or by the end of the session > description. A media field has several sub-fields. > > The first sub-field is the media type. Currently defined media are > "audio", "video", "text", "application", "data" and "control", > though > this > list may be extended in future. > > -----further down, same section ----------- > > The fourth and subsequent sub-fields are media formats. For audio > text and video, these SHOULD reference a MIME sub-type describing > the > format under the "audio", "text" and "video" top-level MIME types. > > ------In Appendix A------------------------------ > > ; sub-rules of 'm=' > media = token > ;typically "audio", "video", "text", > "application" > ;or "data" > ------End of proposal-- These will be in draft-ietf-mmusic-sdp-new-16. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 16 20:02:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13693 for ; Sun, 16 Nov 2003 20:02:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALXmH-0004ys-KJ for mmusic-archive@odin.ietf.org; Sun, 16 Nov 2003 20:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH125YF019131 for mmusic-archive@odin.ietf.org; Sun, 16 Nov 2003 20:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALXmH-0004yN-Cg for mmusic-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 20:02: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 UAA13683 for ; Sun, 16 Nov 2003 20:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALXmF-0005jx-00 for mmusic-web-archive@ietf.org; Sun, 16 Nov 2003 20:02:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALXmE-0005jr-00 for mmusic-web-archive@ietf.org; Sun, 16 Nov 2003 20:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALXmC-0004xE-E2; Sun, 16 Nov 2003 20:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALXlN-0004wH-9D for mmusic@optimus.ietf.org; Sun, 16 Nov 2003 20:01: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 UAA13642 for ; Sun, 16 Nov 2003 20:00:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALXlL-0005j7-00 for mmusic@ietf.org; Sun, 16 Nov 2003 20:01:07 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALXlK-0005gc-00 for mmusic@ietf.org; Sun, 16 Nov 2003 20:01:06 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Nov 2003 17:08:26 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAH10Zw5004744; Sun, 16 Nov 2003 17:00:35 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-706.cisco.com [10.21.82.194]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ68512; Sun, 16 Nov 2003 17:00:34 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 15 Nov 2003 17:02:15 -0800 Subject: Re: [MMUSIC] STUN vs Symmetric RTP From: Cullen Jennings To: Gamze Seckin , Message-ID: In-Reply-To: <787ED0EC136B854DB341E7662D666CD6540E9A@bels002.mediator.com> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit STUN is shipping in several vendors SIP phones. STUN like things that are not exactly STUN but work about the same way are are also done by many vendors. If you could only do one, I would do STUN before commedia but of course doing all the stuff in ICE (draft-ietf-mmusic-ice) would probably work out best. Cullen On 11/11/03 10:01 AM, "Gamze Seckin" wrote: > > Hi, > > I checked the rtsp nat traversal draft (draft-ietf-mmusic-rtsp-nat-01.txt) but > could not find a comprehensive comparison between STUN vs Symmetric RTP. > > Is anybody actually using STUN? > How about symmetric RTP? > > Which one would you recommend if you had to actually deploy it ? > Any pointers appreciated. > > > Br > > g > > ----------------------------------------------------------- > Gamze Seckin, Ph.D. > Director of Research > Vidiator Technology (US) Inc. > 411 108th Avenue NE. Suite 688 > Bellevue, WA 98004 USA. > www.vidiator.com > > Phone: 1.425.688.8811x2108 > Email: gamze@vidiator.com > > This e-mail message (including any attachment) is intended only for the > personal use of the recipient(s) named above. This message is confidential and > may be legally privileged. If you are not an intended recipient, you may not > review, copy or distribute this message. If you have received this > communication in error, please notify us immediately by e-mail and delete the > original message. Any views or opinions expressed in this message are those of > the author only. Furthermore, this message including any attachment does not > create any legally binding rights or obligations whatsoever, which may only be > created by the exchange of hard copy documents signed by a duly authorized > representative of Vidiator Technology (US) Inc. > ----------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 17 12:11:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22476 for ; Mon, 17 Nov 2003 12:11: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 1ALmu4-0001z6-P4 for mmusic-archive@odin.ietf.org; Mon, 17 Nov 2003 12:11:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHHB8oM007622 for mmusic-archive@odin.ietf.org; Mon, 17 Nov 2003 12:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmu4-0001yr-Kx for mmusic-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 12:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22419 for ; Mon, 17 Nov 2003 12:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmu3-0002C1-00 for mmusic-web-archive@ietf.org; Mon, 17 Nov 2003 12:11:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALmu2-0002By-00 for mmusic-web-archive@ietf.org; Mon, 17 Nov 2003 12:11:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmtx-0001y9-Qo; Mon, 17 Nov 2003 12:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmtq-0001xb-QK for mmusic@optimus.ietf.org; Mon, 17 Nov 2003 12:10: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 MAA22378 for ; Mon, 17 Nov 2003 12:10:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmtp-0002B1-00 for mmusic@ietf.org; Mon, 17 Nov 2003 12:10:53 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ALmto-00028P-00 for mmusic@ietf.org; Mon, 17 Nov 2003 12:10:52 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAHH9vca018277; Mon, 17 Nov 2003 12:10:03 -0500 (EST) Message-ID: <3FB900E1.8080304@dynamicsoft.com> Date: Mon, 17 Nov 2003 12:09:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Gamze Seckin , mmusic@ietf.org Subject: Re: [MMUSIC] STUN vs Symmetric RTP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > STUN is shipping in several vendors SIP phones. STUN like things that are > not exactly STUN but work about the same way are are also done by many > vendors. > > If you could only do one, I would do STUN before commedia but of course > doing all the stuff in ICE (draft-ietf-mmusic-ice) would probably work out > best. To add to that, if you do ICE, the client to client tests that use STUN would get you equivalent functionality to symmetric RTP. The benefit is that ICE will allow your client to work in lots of different cases, not just the limited ones where symmetric RTP works. In particular, if both clients are behidn NAT, symmetric RTP doesnt help. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 17 19:52:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16102 for ; Mon, 17 Nov 2003 19:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu67-0003F7-8C for mmusic-archive@odin.ietf.org; Mon, 17 Nov 2003 19:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI0q3tc012461 for mmusic-archive@odin.ietf.org; Mon, 17 Nov 2003 19:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu67-0003Es-3K for mmusic-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 19:52:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16091 for ; Mon, 17 Nov 2003 19:51:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALu65-0002Ys-00 for mmusic-web-archive@ietf.org; Mon, 17 Nov 2003 19:52:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALu64-0002Yo-00 for mmusic-web-archive@ietf.org; Mon, 17 Nov 2003 19:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu64-0003Du-8m; Mon, 17 Nov 2003 19:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu5X-0003CC-NW for mmusic@optimus.ietf.org; Mon, 17 Nov 2003 19:51: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 TAA16081; Mon, 17 Nov 2003 19:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALu5V-0002Ye-00; Mon, 17 Nov 2003 19:51:25 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALu5V-0002YY-00; Mon, 17 Nov 2003 19:51:25 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAI0orAt020501; Mon, 17 Nov 2003 16:50:53 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKA52949; Mon, 17 Nov 2003 16:50:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 17 Nov 2003 16:50:51 -0800 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN From: Cullen Jennings To: Pete Cordell , Mmusic , Midcom Message-ID: In-Reply-To: <004d01c3985b$b1f25340$0200000a@tkw> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If people have specific technical issues about the security of TURN that are not documented in the current draft - it would be really nice to know about them. I always hear there are some but I never seem to hear what exactly they are. I do understand Melinda's general concerns on if media relays should be done at all no matter how they are done. Thanks Cullen On 10/21/03 10:14 PM, "Pete Cordell" wrote: > What you say Christian is technically absolutely correct. > > However this communities appetite for implementing and labelling their > products with even -00 draft material suggests to me that many implementers > (and probably their customers) are not bothered by these subtleties of IETF > process. > > Certainly it would help to know whether informational or proposed standard > is > being sought for this draft. > > Pete. > > ============================================= > Pete Cordell > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: "Christian Huitema" > To: "Pete Cordell" ; "Melinda Shore" > > Cc: "Jonathan Rosenberg" ; "Peterson, Jon" > ; "Mmusic" ; > Sent: 20 October 2003 20:27 > Subject: RE: [midcom] Re: [MMUSIC] Status of TURN > > > Individual submissions are a well established part of the process, and > should be considered a fine way to make progress when a working group > would not. There is a catch, however. Individual contributions are very > seldom published as proposed standards -- they normally end up as either > experimental or informational. The criteria for publishing something as > informational ought to be, demonstration of at least some significant > interest in the community -- but not necessarily demonstration of > consensus. The bar for refusing publication in the presence of enough > interest has to be somewhat high -- basically, the group has to be > convinced that implementing the proposal as is would damage the > Internet. > > Obviously, publication as a proposed standard would require the > equivalent of WG consensus. I don't believe there is such consensus on > TURN. > > -- Christian Huitema > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 18 04:24:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11463 for ; Tue, 18 Nov 2003 04:24:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM25n-0003mh-Fp for mmusic-archive@odin.ietf.org; Tue, 18 Nov 2003 04:24:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI9OFqt014541 for mmusic-archive@odin.ietf.org; Tue, 18 Nov 2003 04:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM25m-0003mI-Fx for mmusic-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 04:24: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 EAA11414 for ; Tue, 18 Nov 2003 04:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM25j-00017s-00 for mmusic-web-archive@ietf.org; Tue, 18 Nov 2003 04:24:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM25j-00017p-00 for mmusic-web-archive@ietf.org; Tue, 18 Nov 2003 04:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM25e-0003kr-Bx; Tue, 18 Nov 2003 04:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM251-0003jb-Kv for mmusic@optimus.ietf.org; Tue, 18 Nov 2003 04:23: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 EAA11391 for ; Tue, 18 Nov 2003 04:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM24y-00017D-00 for mmusic@ietf.org; Tue, 18 Nov 2003 04:23:24 -0500 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx with esmtp (Exim 4.12) id 1AM24x-00016b-00 for mmusic@ietf.org; Tue, 18 Nov 2003 04:23:24 -0500 Received: from oleane ([194.250.212.114]) by smtp6.clb.oleane.net with SMTP id hAI9Mr6f001333 for ; Tue, 18 Nov 2003 10:22:54 +0100 Message-ID: <015301c3adb6$26d12640$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Tue, 18 Nov 2003 10:27:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0150_01C3ADBE.8841A1E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [MMUSIC] 2004 WiFi Voice Conference 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0150_01C3ADBE.8841A1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The 2004 WiFi Voice Conference will stand in Paris on May 25 to 28, = 2004.=20 The call for papers dead line has been extended until December 15, 2003. = Get more details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm We also remind you that registration is still open to the New Mobile = Technologies Forum (UWB, IPCN and IPv6 Mobile sessions) at: http://www.upperside.fr/newmobtech/newmobtech03intro.htm ------=_NextPart_000_0150_01C3ADBE.8841A1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The 2004 WiFi Voice=20 Conference will stand in Paris on May 25 to=20 28, 2004. 
The call for papers dead line has been = extended until=20 December 15, 2003.
Get more details at:
http://= www.upperside.fr/wifivoice04/wifivoice04intro.htm
 
We also remind you that registration is still open to the New Mobile Technologies Forum (UWB, IPCN and IPv6 = Mobile=20 sessions) at:
http://= www.upperside.fr/newmobtech/newmobtech03intro.htm
<= /DIV>
 
 
------=_NextPart_000_0150_01C3ADBE.8841A1E0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 19 08:00:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15123 for ; Wed, 19 Nov 2003 08:00: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 1AMRwD-0007XG-EJ for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 08:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJD057N028962 for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 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 1AMRwC-0007X3-SE for mmusic-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 08:00: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 HAA15096 for ; Wed, 19 Nov 2003 07:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRwB-0006Wh-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 08:00:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMRwB-0006Wd-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 08:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRwB-0007WW-9a; Wed, 19 Nov 2003 08:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRvu-0007Vp-3C for mmusic@optimus.ietf.org; Wed, 19 Nov 2003 07:59: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 HAA15075 for ; Wed, 19 Nov 2003 07:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRvt-0006WR-00 for mmusic@ietf.org; Wed, 19 Nov 2003 07:59:45 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AMRvs-0006WC-00 for mmusic@ietf.org; Wed, 19 Nov 2003 07:59:44 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id hAJCxDpI009512 for ; Wed, 19 Nov 2003 13:59:13 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAJCxDR7009317 for ; Wed, 19 Nov 2003 13:59:13 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAJCxDwG009316 for mmusic@ietf.org; Wed, 19 Nov 2003 13:59:13 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Nov 2003 13:59:13 +0100 From: Stig Venaas To: mmusic@ietf.org Message-ID: <20031119125913.GB9257@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [MMUSIC] some comments on IPV and ICE 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: , First of all, I haven't studied this topic much, so bare with me for any misunderstandings. I have some doubts regarding IPV (draft-camarillo-mmusic-alt-02.txt). As I understand it, IPV would be useful to ipv4-only or ipv6-only hosts, but has significant drawbacks for dual-stack hosts not supporting it. I believe that most IPv6 hosts today, are dual-stack and will continue to be so for some time. An exceptiom might be some new environments like 3G networks. I think it's better to add special requirements for the special cases, that is, require IPv6-only hosts to support a new solution. I think it's important to be able to express two different things in SDP. One is a number of addresses (possibly addresses of different address families) where the client may pick any one, the other is a number of addresses (again possibly different families) where the client is supposed to use all. Unless I've misunderstood something, the latter is fine, and the former can be done with ICE, except that there is a preferred address. That there's a preferred address isn't a problem I think. If indeed the alt attribute is useful in general, isn't it better to define this separately from ICE, and have ICE refer to that? Stig _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 19 08:18:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15596 for ; Wed, 19 Nov 2003 08:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSDa-0000MA-Ss for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 08:18:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJDI2VV001364 for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 08:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSDa-0000Lr-L1 for mmusic-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 08:18: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 IAA15581 for ; Wed, 19 Nov 2003 08:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSDZ-0006n9-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 08:18:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMSDY-0006n3-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 08:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSDZ-0000L3-0T; Wed, 19 Nov 2003 08:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSDI-0000Il-G2 for mmusic@optimus.ietf.org; Wed, 19 Nov 2003 08:17:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15561 for ; Wed, 19 Nov 2003 08:17:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSDH-0006mT-00 for mmusic@ietf.org; Wed, 19 Nov 2003 08:17:43 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AMSDG-0006mQ-00 for mmusic@ietf.org; Wed, 19 Nov 2003 08:17:43 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAJDHfI2010611; Wed, 19 Nov 2003 14:17:41 +0100 (MET) Received: from ericsson.com (rvi2-92-224.sw.ericsson.se [153.88.92.224]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFF5PT8C; Wed, 19 Nov 2003 14:17:40 +0100 Message-ID: <3FBB6D73.4080802@ericsson.com> Date: Wed, 19 Nov 2003 15:17:39 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo 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: en-us, en MIME-Version: 1.0 To: Stig Venaas CC: mmusic@ietf.org Subject: Re: [MMUSIC] some comments on IPV and ICE References: <20031119125913.GB9257@sverresborg.uninett.no> In-Reply-To: <20031119125913.GB9257@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > If indeed the alt attribute is useful in general, isn't it better > to define this separately from ICE, and have ICE refer to that? This is exactly what the draft does right now. You may be referring to an old version of that draft. Regarding your comment about dual-stack UAs, I do not see any problem related to the use of IPV. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 19 13:03:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00009 for ; Wed, 19 Nov 2003 13:03:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfR-0003nF-IU for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 13:03:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJI35L9014577 for mmusic-archive@odin.ietf.org; Wed, 19 Nov 2003 13:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfR-0003n2-F7 for mmusic-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 13:03: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 NAA29973 for ; Wed, 19 Nov 2003 13:02:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWfP-00059v-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 13:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWfP-00059s-00 for mmusic-web-archive@ietf.org; Wed, 19 Nov 2003 13:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfP-0003kY-JY; Wed, 19 Nov 2003 13:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfC-0003jP-Kg for mmusic@optimus.ietf.org; Wed, 19 Nov 2003 13:02: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 NAA29969; Wed, 19 Nov 2003 13:02:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWf7-00059R-00; Wed, 19 Nov 2003 13:02:45 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMWf6-00058T-00; Wed, 19 Nov 2003 13:02:45 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAJI2Dlf018001; Wed, 19 Nov 2003 13:02:13 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 19 Nov 2003 13:02:09 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 13:02:09 -0500 Message-ID: From: "Phelan, Tom" To: "'dccp@ietf.org'" Cc: "'avt@ietf.org'" , "'mmusic@ietf.org'" Date: Wed, 19 Nov 2003 13:02:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] DCCP Media Guide 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: , Hi, I've sent "Strategies for Media Applications Using DCCP" to the Internet-Drafts archive. While we're waiting for it to be added, it's also available at http://www.phelan-4.com/dccp/draft-phelan-dccp-media-00.txt. The plan is that this will soon evolve into a general DCCP User Guide. Abstract: This document discusses strategies for using DCCP as the transport protocol for streaming media applications. Of particular interest is how media streams can be adapted to the smoothly varying transmit rate requirements of CCID3, or TCP-Friendly Rate Control (TFRC). Also explored is the resulting network behavior of streams using these strategies and the fairness between these streams and TCP-based streams. Comments will be appreciated. In particular, I make the suggestion that media apps should transmit at up to twice their nominal maximum rate, when DCCP allows it, in order to provide protection from competing TCP applications. I know that the first time I heard someone make a similar suggestion I was horrified, but as I developed the issues it seemed to be necessary. Reactions to this will be appreciated. Tom P. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 02:33:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20759 for ; Thu, 20 Nov 2003 02:33: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 1AMjJt-000457-Mo for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 02:33:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7XfNo015687 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 02:33:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjJr-00044w-GH for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 02:33: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 CAA20742 for ; Thu, 20 Nov 2003 02:33:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjJo-0005SR-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 02:33:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjJo-0005SO-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 02:33:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjJK-00042m-W2; Thu, 20 Nov 2003 02:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjIZ-0003y2-OE for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 02:32: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 CAA20664; Thu, 20 Nov 2003 02:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjIW-0005RK-00; Thu, 20 Nov 2003 02:32:16 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMjII-0005Qf-00; Thu, 20 Nov 2003 02:32:02 -0500 Received: from dynamicsoft.com ([63.113.46.66]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAK7VZca019587; Thu, 20 Nov 2003 02:31:35 -0500 (EST) Message-ID: <3FBC6DD3.5000705@dynamicsoft.com> Date: Thu, 20 Nov 2003 02:31:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] DCCP Media Guide References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom, I don't think this solution will be acceptable to many of the network providers of interactive voip services. Many of them are insistent on using low rate codecs, like g.723, in order to reduce the costs of capacity in their networks. Doubling the rate would defeat the purpose of using these low rate codecs in the first place. -Jonathan R. Phelan, Tom wrote: > Comments will be appreciated. In particular, I make the suggestion that > media apps should transmit at up to twice their nominal maximum rate, when > DCCP allows it, in order to provide protection from competing TCP > applications. I know that the first time I heard someone make a similar > suggestion I was horrified, but as I developed the issues it seemed to be > necessary. Reactions to this will be appreciated. > > Tom P. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 10:37:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09692 for ; Thu, 20 Nov 2003 10:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqrk-0001uD-GH for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 10:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKFb8qP007317 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 10:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqrj-0001to-C2 for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 10:37: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 KAA09669 for ; Thu, 20 Nov 2003 10:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqrh-0004ke-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 10:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqrg-0004kZ-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 10:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqrf-0001r7-Vg; Thu, 20 Nov 2003 10:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqr0-0001pv-7E for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 10:36: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 KAA09625; Thu, 20 Nov 2003 10:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqqx-0004k7-00; Thu, 20 Nov 2003 10:36:19 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMqqx-0004jd-00; Thu, 20 Nov 2003 10:36:19 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKFZmlf021027; Thu, 20 Nov 2003 10:35:48 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 10:35:36 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 10:35:36 -0500 Message-ID: From: "Phelan, Tom" To: "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 10:35:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi Jonathan, Thanks for the comments. The actual proposal is to send up to double the nominal transmit rate when there's available bandwidth, and to reduce the rate as necessary if there isn't enough bandwidth. This doubling is to allow fair sharing of the chokepoint bandwidth (between DCCP media apps and TCP apps), and to avoid what appears to me to be the potential for bullying from TCP applications that want to suck up all the bandwidth they can. It doesn't preclude using low-rate codecs, or mean that the access link must support the double rate for the connection to function well. This recommendation was meant for best-effort environments, where the voice traffic receives no special treatment, and must compete with TCP apps for network resources. I can see how this would require a network that gave special treatment to voice packets to provision double the capacity, though. This fairness problem is difficult. All of the research I'm familiar with approaches it from the direction of other apps being fair to TCP. I'm not aware of any other methods for ensuring that non-TCP apps get their fair share when competing with TCP. If you (or anyone else) knows of something I'd appreciate the pointer. Tom P. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 20, 2003 2:32 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: Re: [MMUSIC] DCCP Media Guide > > > Tom, > > I don't think this solution will be acceptable to many of the network > providers of interactive voip services. Many of them are insistent on > using low rate codecs, like g.723, in order to reduce the costs of > capacity in their networks. Doubling the rate would defeat > the purpose > of using these low rate codecs in the first place. > > -Jonathan R. > > Phelan, Tom wrote: > > > > Comments will be appreciated. In particular, I make the > suggestion that > > media apps should transmit at up to twice their nominal > maximum rate, when > > DCCP allows it, in order to provide protection from competing TCP > > applications. I know that the first time I heard someone > make a similar > > suggestion I was horrified, but as I developed the issues > it seemed to be > > necessary. Reactions to this will be appreciated. > > > > Tom P. > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 11:06:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10847 for ; Thu, 20 Nov 2003 11:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJk-0003n2-LI for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 11:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKG64dE014567 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 11:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJk-0003ms-HK for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:06: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 LAA10804 for ; Thu, 20 Nov 2003 11:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrJh-0005Cb-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 11:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrJh-0005CY-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 11:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJj-0003mR-HA; Thu, 20 Nov 2003 11:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJ8-0003fZ-RM for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 11:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10786; Thu, 20 Nov 2003 11:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrJ5-0005CB-00; Thu, 20 Nov 2003 11:05:23 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMrJ4-0005BX-00; Thu, 20 Nov 2003 11:05:22 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27132; Thu, 20 Nov 2003 11:04:50 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17127; Thu, 20 Nov 2003 11:04:50 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 11:04:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B60F9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" , "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 11:04:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , To me, this is just nonsense. I can't imagine anyone deploying such a solution. This is forcing the problem to fit the solution, and it's not the right way to go. If you want it to work, the protocol has to take the characteristics of the flows as they are, and not as you would like them to be. Real time media, streaming or realtime, is either constant bit rate, or pretty close to it. That's how it works. Our challenge is to make the protocols work with this data, not change the data, especially silly ideas like doubling the bandwidth. We make video telephones. They nominally send 4 megabits. Would you like us to double that, under any circumstances? I thought not. Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Thursday, November 20, 2003 10:36 AM > To: 'Jonathan Rosenberg' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Jonathan, > > Thanks for the comments. The actual proposal is to send up > to double the > nominal transmit rate when there's available bandwidth, and > to reduce the > rate as necessary if there isn't enough bandwidth. This > doubling is to > allow fair sharing of the chokepoint bandwidth (between DCCP > media apps and > TCP apps), and to avoid what appears to me to be the > potential for bullying > from TCP applications that want to suck up all the bandwidth > they can. It > doesn't preclude using low-rate codecs, or mean that the > access link must > support the double rate for the connection to function well. > > This recommendation was meant for best-effort environments, > where the voice > traffic receives no special treatment, and must compete with > TCP apps for > network resources. I can see how this would require a > network that gave > special treatment to voice packets to provision double the > capacity, though. > > This fairness problem is difficult. All of the research I'm > familiar with > approaches it from the direction of other apps being fair to > TCP. I'm not > aware of any other methods for ensuring that non-TCP apps get > their fair > share when competing with TCP. If you (or anyone else) knows > of something > I'd appreciate the pointer. > > Tom P. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, November 20, 2003 2:32 AM > > To: Phelan, Tom > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > Tom, > > > > I don't think this solution will be acceptable to many of > the network > > providers of interactive voip services. Many of them are > insistent on > > using low rate codecs, like g.723, in order to reduce the costs of > > capacity in their networks. Doubling the rate would defeat > > the purpose > > of using these low rate codecs in the first place. > > > > -Jonathan R. > > > > Phelan, Tom wrote: > > > > > > > Comments will be appreciated. In particular, I make the > > suggestion that > > > media apps should transmit at up to twice their nominal > > maximum rate, when > > > DCCP allows it, in order to provide protection from competing TCP > > > applications. I know that the first time I heard someone > > make a similar > > > suggestion I was horrified, but as I developed the issues > > it seemed to be > > > necessary. Reactions to this will be appreciated. > > > > > > Tom P. > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 11:49:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13088 for ; Thu, 20 Nov 2003 11:49: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 1AMrzQ-0007W4-Cf for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 11:49:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGn8Ap028868 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 11:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrzQ-0007VX-4y for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13055 for ; Thu, 20 Nov 2003 11:48:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrzO-00062z-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 11:49:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrzO-00062w-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 11:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrzK-0007Tl-MD; Thu, 20 Nov 2003 11:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrys-0007SJ-Hu for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 11:48: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 LAA13032; Thu, 20 Nov 2003 11:48:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMryq-00062Z-00; Thu, 20 Nov 2003 11:48:32 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMryq-00062A-00; Thu, 20 Nov 2003 11:48:32 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKGm2lf025590; Thu, 20 Nov 2003 11:48:02 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 11:47:49 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 11:47:49 -0500 Message-ID: From: "Phelan, Tom" To: "'Rosen, Brian'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 11:47:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi Brian, Thanks for the comments. See inline ... Tom P. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, November 20, 2003 11:05 AM > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > To me, this is just nonsense. > I can't imagine anyone deploying such a solution. > > This is forcing the problem to fit the solution, and it's not > the right way to go. If you want it to work, the protocol > has to take the characteristics of the flows as they are, and not > as you would like them to be. Real time media, streaming or realtime, > is either constant bit rate, or pretty close to it. That's how it > works. Our challenge is to make the protocols work with this data, > not change the data, especially silly ideas like doubling the > bandwidth. > > We make video telephones. They nominally send 4 megabits. Would > you like us to double that, under any circumstances? > > I thought not. Would you prefer to be forced unnecessarily into packet loss and a lower encoding rate by greedy TCP applications? Or do you have another solution? I don't think I'm forcing the problem to fit the solution, just perhaps that the problem I'm trying to solve is different than you perceive. The problem that I'm trying to solve is how can an application that is content with a maximum bandwidth compete with TCP applications that are insatiably greedy, in a way that satisfies some concept of fairness in all directions? The solution that I see is to provide a buffer against TCP probing. This would involve sending more data than is nominally necessary. If the network has capacity for more than 4M bps, then why shouldn't a media app make use of it? A TCP app would. I must admit that my initial reactions to suggestions like this were very similar to yours. I encourage you to look at the draft for more detail on the issues that convinced me otherwise. > > Brian > > > -----Original Message----- > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > Sent: Thursday, November 20, 2003 10:36 AM > > To: 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Hi Jonathan, > > > > Thanks for the comments. The actual proposal is to send up > > to double the > > nominal transmit rate when there's available bandwidth, and > > to reduce the > > rate as necessary if there isn't enough bandwidth. This > > doubling is to > > allow fair sharing of the chokepoint bandwidth (between DCCP > > media apps and > > TCP apps), and to avoid what appears to me to be the > > potential for bullying > > from TCP applications that want to suck up all the bandwidth > > they can. It > > doesn't preclude using low-rate codecs, or mean that the > > access link must > > support the double rate for the connection to function well. > > > > This recommendation was meant for best-effort environments, > > where the voice > > traffic receives no special treatment, and must compete with > > TCP apps for > > network resources. I can see how this would require a > > network that gave > > special treatment to voice packets to provision double the > > capacity, though. > > > > This fairness problem is difficult. All of the research I'm > > familiar with > > approaches it from the direction of other apps being fair to > > TCP. I'm not > > aware of any other methods for ensuring that non-TCP apps get > > their fair > > share when competing with TCP. If you (or anyone else) knows > > of something > > I'd appreciate the pointer. > > > > Tom P. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, November 20, 2003 2:32 AM > > > To: Phelan, Tom > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > Tom, > > > > > > I don't think this solution will be acceptable to many of > > the network > > > providers of interactive voip services. Many of them are > > insistent on > > > using low rate codecs, like g.723, in order to reduce the > costs of > > > capacity in their networks. Doubling the rate would defeat > > > the purpose > > > of using these low rate codecs in the first place. > > > > > > -Jonathan R. > > > > > > Phelan, Tom wrote: > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > suggestion that > > > > media apps should transmit at up to twice their nominal > > > maximum rate, when > > > > DCCP allows it, in order to provide protection from > competing TCP > > > > applications. I know that the first time I heard someone > > > make a similar > > > > suggestion I was horrified, but as I developed the issues > > > it seemed to be > > > > necessary. Reactions to this will be appreciated. > > > > > > > > Tom P. > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 12:26:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14548 for ; Thu, 20 Nov 2003 12:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsZB-00029l-NG for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 12:26:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHQ5P0008283 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 12:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsZB-00029W-HM for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 12:26: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 MAA14538 for ; Thu, 20 Nov 2003 12:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsZ9-0006fl-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 12:26:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMsZ9-0006fi-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 12:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsZ9-00028N-IQ; Thu, 20 Nov 2003 12:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsYZ-00024k-5f for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 12:25: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 MAA14498; Thu, 20 Nov 2003 12:25:12 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsYX-0006f9-00; Thu, 20 Nov 2003 12:25:25 -0500 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 1AMsYW-0006f6-00; Thu, 20 Nov 2003 12:25:24 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id C907D2B4A2; Thu, 20 Nov 2003 18:25:23 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 5D10019C49; Thu, 20 Nov 2003 18:25:23 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 0899619C48; Thu, 20 Nov 2003 18:25:22 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA03974; Thu, 20 Nov 2003 18:25:22 +0100 (MET) Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: "Phelan, Tom" , "'Rosen, Brian'" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 20 Nov 2003 18:22:39 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 20/11/2003 18:26:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Brian, all, It may provide some help in understanding the situation to describe your exemple as follows: * you send video at 4 Mb/s, good. * it happens that you are competing with (a lot of ) TCP AND that you want to be fair to it: * so when that happens you decrease your rate to 2 Mb/s for "a while" because otherwise you are not fair. * but at some moment you will want to come back up to 4 Mb/s right ? => the point is that the **only way** to know if you "can" do that, is to try it.... regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: "'Rosen, Brian'" cc: "'dccp@ietf.org'" "'avt@ietf.org'" "'mmusic@ietf.org'" "Phelan, Tom" (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Sent by: Classification: mmusic-admin@ietf.org 20/11/2003 17:47 Hi Brian, Thanks for the comments. See inline ... Tom P. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, November 20, 2003 11:05 AM > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > To me, this is just nonsense. > I can't imagine anyone deploying such a solution. > > This is forcing the problem to fit the solution, and it's not > the right way to go. If you want it to work, the protocol > has to take the characteristics of the flows as they are, and not > as you would like them to be. Real time media, streaming or realtime, > is either constant bit rate, or pretty close to it. That's how it > works. Our challenge is to make the protocols work with this data, > not change the data, especially silly ideas like doubling the > bandwidth. > > We make video telephones. They nominally send 4 megabits. Would > you like us to double that, under any circumstances? > > I thought not. Would you prefer to be forced unnecessarily into packet loss and a lower encoding rate by greedy TCP applications? Or do you have another solution? I don't think I'm forcing the problem to fit the solution, just perhaps that the problem I'm trying to solve is different than you perceive. The problem that I'm trying to solve is how can an application that is content with a maximum bandwidth compete with TCP applications that are insatiably greedy, in a way that satisfies some concept of fairness in all directions? The solution that I see is to provide a buffer against TCP probing. This would involve sending more data than is nominally necessary. If the network has capacity for more than 4M bps, then why shouldn't a media app make use of it? A TCP app would. I must admit that my initial reactions to suggestions like this were very similar to yours. I encourage you to look at the draft for more detail on the issues that convinced me otherwise. > > Brian > > > -----Original Message----- > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > Sent: Thursday, November 20, 2003 10:36 AM > > To: 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Hi Jonathan, > > > > Thanks for the comments. The actual proposal is to send up > > to double the > > nominal transmit rate when there's available bandwidth, and > > to reduce the > > rate as necessary if there isn't enough bandwidth. This > > doubling is to > > allow fair sharing of the chokepoint bandwidth (between DCCP > > media apps and > > TCP apps), and to avoid what appears to me to be the > > potential for bullying > > from TCP applications that want to suck up all the bandwidth > > they can. It > > doesn't preclude using low-rate codecs, or mean that the > > access link must > > support the double rate for the connection to function well. > > > > This recommendation was meant for best-effort environments, > > where the voice > > traffic receives no special treatment, and must compete with > > TCP apps for > > network resources. I can see how this would require a > > network that gave > > special treatment to voice packets to provision double the > > capacity, though. > > > > This fairness problem is difficult. All of the research I'm > > familiar with > > approaches it from the direction of other apps being fair to > > TCP. I'm not > > aware of any other methods for ensuring that non-TCP apps get > > their fair > > share when competing with TCP. If you (or anyone else) knows > > of something > > I'd appreciate the pointer. > > > > Tom P. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, November 20, 2003 2:32 AM > > > To: Phelan, Tom > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > Tom, > > > > > > I don't think this solution will be acceptable to many of > > the network > > > providers of interactive voip services. Many of them are > > insistent on > > > using low rate codecs, like g.723, in order to reduce the > costs of > > > capacity in their networks. Doubling the rate would defeat > > > the purpose > > > of using these low rate codecs in the first place. > > > > > > -Jonathan R. > > > > > > Phelan, Tom wrote: > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > suggestion that > > > > media apps should transmit at up to twice their nominal > > > maximum rate, when > > > > DCCP allows it, in order to provide protection from > competing TCP > > > > applications. I know that the first time I heard someone > > > make a similar > > > > suggestion I was horrified, but as I developed the issues > > > it seemed to be > > > > necessary. Reactions to this will be appreciated. > > > > > > > > Tom P. > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 12:36:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14927 for ; Thu, 20 Nov 2003 12:36:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsip-0002mO-Jd for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 12:36:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHa3OQ010675 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 12:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsip-0002li-B1 for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 12:36: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 MAA14913 for ; Thu, 20 Nov 2003 12:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsin-0006oh-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 12:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMsin-0006oe-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 12:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsio-0002kw-2D; Thu, 20 Nov 2003 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsiJ-0002kO-W5 for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 12:35: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 MAA14901; Thu, 20 Nov 2003 12:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsiI-0006oT-00; Thu, 20 Nov 2003 12:35:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMsiH-0006oK-00; Thu, 20 Nov 2003 12:35:29 -0500 Received: from dynamicsoft.com ([63.113.46.99]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAKHZ1ca019902; Thu, 20 Nov 2003 12:35:02 -0500 (EST) Message-ID: <3FBCFB41.8030908@dynamicsoft.com> Date: Thu, 20 Nov 2003 12:34:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] DCCP Media Guide References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Phelan, Tom wrote: > Hi Jonathan, > > Thanks for the comments. The actual proposal is to send up to double the > nominal transmit rate when there's available bandwidth, and to reduce the > rate as necessary if there isn't enough bandwidth. This doubling is to > allow fair sharing of the chokepoint bandwidth (between DCCP media apps and > TCP apps), and to avoid what appears to me to be the potential for bullying > from TCP applications that want to suck up all the bandwidth they can. It > doesn't preclude using low-rate codecs, or mean that the access link must > support the double rate for the connection to function well. > > This recommendation was meant for best-effort environments, where the voice > traffic receives no special treatment, and must compete with TCP apps for > network resources. I can see how this would require a network that gave > special treatment to voice packets to provision double the capacity, though. What about networks where there is also a lot of UDP traffic? For example, these same networks providing voip traffic today. If I incrementally add dccp support, it seems like I will need to increase the provisioned capacity so I dont push out the UDP, no? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 12:59:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15967 for ; Thu, 20 Nov 2003 12:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt56-0004l6-W2 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 12:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHx4ju018291 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 12:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt56-0004kw-T2 for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 12:59: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 MAA15933 for ; Thu, 20 Nov 2003 12:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt55-0007DB-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 12:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMt54-0007D8-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 12: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 1AMt55-0004kD-7j; Thu, 20 Nov 2003 12:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt4I-0004ee-Fn for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 12:58: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 MAA15895; Thu, 20 Nov 2003 12:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt4G-0007Cf-00; Thu, 20 Nov 2003 12:58:12 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMt4F-0007Bm-00; Thu, 20 Nov 2003 12:58:11 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKHvflf029685; Thu, 20 Nov 2003 12:57:41 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 12:57:36 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:57:36 -0500 Message-ID: From: "Phelan, Tom" To: "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 12:57:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi Jonathan, See inline ... Tom P. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 20, 2003 12:35 PM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > Phelan, Tom wrote: > > > Hi Jonathan, > > > > Thanks for the comments. The actual proposal is to send up > to double the > > nominal transmit rate when there's available bandwidth, and > to reduce the > > rate as necessary if there isn't enough bandwidth. This > doubling is to > > allow fair sharing of the chokepoint bandwidth (between > DCCP media apps and > > TCP apps), and to avoid what appears to me to be the > potential for bullying > > from TCP applications that want to suck up all the > bandwidth they can. It > > doesn't preclude using low-rate codecs, or mean that the > access link must > > support the double rate for the connection to function well. > > > > This recommendation was meant for best-effort environments, > where the voice > > traffic receives no special treatment, and must compete > with TCP apps for > > network resources. I can see how this would require a > network that gave > > special treatment to voice packets to provision double the > capacity, though. > > What about networks where there is also a lot of UDP traffic? For > example, these same networks providing voip traffic today. If I > incrementally add dccp support, it seems like I will need to increase > the provisioned capacity so I dont push out the UDP, no? Yes, DCCP will behave towards UDP (and vice versa) pretty much the same as TCP behaves toward UDP. For streaming media apps following the guidelines in the DCCP Media Guide, it actually can be a little better than TCP versus UDP, because there is a maximum transmit rate. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 13:06:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16357 for ; Thu, 20 Nov 2003 13:06: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 1AMtBt-0005Mj-K7 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 13:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKI650u020619 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 13:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtBs-0005MN-QS for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 13:06: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 NAA16315 for ; Thu, 20 Nov 2003 13:05:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtBq-0007MP-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 13:06:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMtBq-0007MM-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 13:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtBr-0005Kz-Dx; Thu, 20 Nov 2003 13:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtB1-0005EJ-8K for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 13:05: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 NAA16230; Thu, 20 Nov 2003 13:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtAy-0007LF-00; Thu, 20 Nov 2003 13:05:08 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMtAy-0007KR-00; Thu, 20 Nov 2003 13:05:08 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKI4clf000069; Thu, 20 Nov 2003 13:04:38 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 13:04:32 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 13:04:32 -0500 Message-ID: From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" , "Phelan, Tom" , "'Rosen, Brian'" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 13:04:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi Phillipe, The situation I'm worried about is a little different than you describe. Say you have a 10M bps link, over which there's a 4M bps video stream and a long-lived TCP app. The TCP app will take the remaining 6M bps, and then push for more, which might cause the video stream to lose packets. The video stream then drops to 2M bps, and the TCP app expands to 8M bps. This hardly seems fair. The video app can protect itself from this by transmitting enough more than 4M bps to buffer itself against the TCP probes. In this case we'd come to a relatively steady state where both apps are sending roughly 5M bps. This seems reasonably fair to me, since the TCP app gets what it would get if it were competing with other TCP apps, and the video app gets to send at its full rate. Tom P. > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, November 20, 2003 12:23 PM > To: Phelan, Tom; 'Rosen, Brian' > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Brian, all, > > It may provide some help in understanding the situation > to describe your exemple as follows: > > * you send video at 4 Mb/s, good. > > * it happens that you are competing with (a lot of ) TCP > > AND that you want to be fair to it: > > * so when that happens you decrease your rate to 2 Mb/s for "a while" > because otherwise you are not fair. > > * but at some moment you will want to come back up to 4 Mb/s right ? > > => the point is that the **only way** to know if you "can" > do that, is to try it.... > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > > > > > > To: > "'Rosen, Brian'" > > cc: > "'dccp@ietf.org'" > > > "'avt@ietf.org'" > > > "'mmusic@ietf.org'" > > "Phelan, Tom" (bcc: > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > Subject: > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > Sent by: > Classification: > > mmusic-admin@ietf.org > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > Hi Brian, > > Thanks for the comments. See inline ... > > Tom P. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, November 20, 2003 11:05 AM > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > To me, this is just nonsense. > > I can't imagine anyone deploying such a solution. > > > > This is forcing the problem to fit the solution, and it's not > > the right way to go. If you want it to work, the protocol > > has to take the characteristics of the flows as they are, and not > > as you would like them to be. Real time media, streaming > or realtime, > > is either constant bit rate, or pretty close to it. That's how it > > works. Our challenge is to make the protocols work with this data, > > not change the data, especially silly ideas like doubling the > > bandwidth. > > > > We make video telephones. They nominally send 4 megabits. Would > > you like us to double that, under any circumstances? > > > > I thought not. > > Would you prefer to be forced unnecessarily into packet loss > and a lower > encoding rate by greedy TCP applications? Or do you have > another solution? > > I don't think I'm forcing the problem to fit the solution, > just perhaps that > the problem I'm trying to solve is different than you > perceive. The problem > that I'm trying to solve is how can an application that is > content with a > maximum bandwidth compete with TCP applications that are > insatiably greedy, > in a way that satisfies some concept of fairness in all directions? > > The solution that I see is to provide a buffer against TCP > probing. This > would involve sending more data than is nominally necessary. > If the network > has capacity for more than 4M bps, then why shouldn't a media > app make use > of it? A TCP app would. > > I must admit that my initial reactions to suggestions like > this were very > similar to yours. I encourage you to look at the draft for > more detail on > the issues that convinced me otherwise. > > > > > Brian > > > > > -----Original Message----- > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > Sent: Thursday, November 20, 2003 10:36 AM > > > To: 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > Hi Jonathan, > > > > > > Thanks for the comments. The actual proposal is to send up > > > to double the > > > nominal transmit rate when there's available bandwidth, and > > > to reduce the > > > rate as necessary if there isn't enough bandwidth. This > > > doubling is to > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > media apps and > > > TCP apps), and to avoid what appears to me to be the > > > potential for bullying > > > from TCP applications that want to suck up all the bandwidth > > > they can. It > > > doesn't preclude using low-rate codecs, or mean that the > > > access link must > > > support the double rate for the connection to function well. > > > > > > This recommendation was meant for best-effort environments, > > > where the voice > > > traffic receives no special treatment, and must compete with > > > TCP apps for > > > network resources. I can see how this would require a > > > network that gave > > > special treatment to voice packets to provision double the > > > capacity, though. > > > > > > This fairness problem is difficult. All of the research I'm > > > familiar with > > > approaches it from the direction of other apps being fair to > > > TCP. I'm not > > > aware of any other methods for ensuring that non-TCP apps get > > > their fair > > > share when competing with TCP. If you (or anyone else) knows > > > of something > > > I'd appreciate the pointer. > > > > > > Tom P. > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > To: Phelan, Tom > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Tom, > > > > > > > > I don't think this solution will be acceptable to many of > > > the network > > > > providers of interactive voip services. Many of them are > > > insistent on > > > > using low rate codecs, like g.723, in order to reduce the > > costs of > > > > capacity in their networks. Doubling the rate would defeat > > > > the purpose > > > > of using these low rate codecs in the first place. > > > > > > > > -Jonathan R. > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > suggestion that > > > > > media apps should transmit at up to twice their nominal > > > > maximum rate, when > > > > > DCCP allows it, in order to provide protection from > > competing TCP > > > > > applications. I know that the first time I heard someone > > > > make a similar > > > > > suggestion I was horrified, but as I developed the issues > > > > it seemed to be > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > Tom P. > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 16:54:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00735 for ; Thu, 20 Nov 2003 16:54: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 1AMwkW-0007if-4X for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 16:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLs4p7029672 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 16:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwkW-0007iV-0j for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:54:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00728 for ; Thu, 20 Nov 2003 16:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwkT-0004Mh-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 16:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwkS-0004Mb-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 16:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwkT-0007hM-HX; Thu, 20 Nov 2003 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMOVw-0005kX-HW for mmusic@optimus.ietf.org; Wed, 19 Nov 2003 04:20:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09828 for ; Wed, 19 Nov 2003 04:20:31 -0500 (EST) From: vandana.yesoda@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMOVt-0003Yv-00 for mmusic@ietf.org; Wed, 19 Nov 2003 04:20:41 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMOVr-0003Yf-00 for mmusic@ietf.org; Wed, 19 Nov 2003 04:20:40 -0500 Received: from ecvwall7.wipro.com (ecvwall7.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id hAJ9K8UR015183 for ; Wed, 19 Nov 2003 14:50:08 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ecvwall7 with InterScan Messaging Security Suite; Wed, 19 Nov 2003 14:54:09 +0530 Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 14:48:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AE7E.1610B134" Date: Wed, 19 Nov 2003 14:48:25 +0530 Message-ID: <3C48D0DE93819942B475859DCF1B19C98D5BE8@blr-ec-msg01.wipro.com> Thread-Topic: draft-ietf-mmusic-confarch-03.txt Thread-Index: AcOufnAKoeZLGbUhSOijc/qErSzuqA== To: X-OriginalArrivalTime: 19 Nov 2003 09:18:25.0935 (UTC) FILETIME=[1646B1F0:01C3AE7E] Subject: [MMUSIC] draft-ietf-mmusic-confarch-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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE7E.1610B134 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I tried to get the following file from internet and using mailserv@etf.org. =20 draft-ietf-mmusic-confarch-03.txt =20 Can any one send me this file? =20 Thanks 'n Rgds Vandana =20 ------_=_NextPart_001_01C3AE7E.1610B134 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I tried to get the following file from internet and = using mailserv@etf.org.<= /font>

 

draft-ietf-mmusic-confarch-0= 3.txt

 

Can any one send me this = file?

 

Thanks 'n = Rgds

Vandana

 

=00 ------_=_NextPart_001_01C3AE7E.1610B134-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 16:54:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00769 for ; Thu, 20 Nov 2003 16:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwkX-0007j4-6E for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 16:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLs55a029690 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 16:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwkX-0007in-13 for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:54: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 QAA00727 for ; Thu, 20 Nov 2003 16:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwkT-0004Me-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 16:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwkS-0004Ma-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 16:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwkT-0007hU-UP; Thu, 20 Nov 2003 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuVX-0002xs-G2 for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 14:30: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 OAA19784; Thu, 20 Nov 2003 14:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuVU-0000nJ-00; Thu, 20 Nov 2003 14:30:24 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMuVT-0000nG-00; Thu, 20 Nov 2003 14:30:23 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAKJU8LL005206; Thu, 20 Nov 2003 12:30:12 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hAKJLxF7031929; Thu, 20 Nov 2003 13:21:59 -0600 Message-ID: <3FBD1558.C10047DF@motorola.com> Date: Thu, 20 Nov 2003 13:26:16 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phelan, Tom" CC: philippe.gentric@philips.com, "'Rosen, Brian'" , avt@ietf.org, dccp@ietf.org, mmusic@ietf.org, TSV WG list Subject: Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide References: 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Tom, It seems to me that you are basically: 1) questioning the fairness of TCP itself and, 2) you want to do something in the app level to outmaneuver TCP so as to achieve your term of fairness. I am not convinced this is the right thing to do with DCCP. I remember similar issue was discussed on tsvwg list (I am cc'ing it). Maybe people in tsvwg can share their thoughts on this as well. regards, -Qiaobing "Phelan, Tom" wrote: > Hi Phillipe, > > The situation I'm worried about is a little different than you describe. > Say you have a 10M bps link, over which there's a 4M bps video stream and a > long-lived TCP app. The TCP app will take the remaining 6M bps, and then > push for more, which might cause the video stream to lose packets. The > video stream then drops to 2M bps, and the TCP app expands to 8M bps. This > hardly seems fair. > > The video app can protect itself from this by transmitting enough more than > 4M bps to buffer itself against the TCP probes. In this case we'd come to a > relatively steady state where both apps are sending roughly 5M bps. This > seems reasonably fair to me, since the TCP app gets what it would get if it > were competing with other TCP apps, and the video app gets to send at its > full rate. > > Tom P. > > > -----Original Message----- > > From: philippe.gentric@philips.com > > [mailto:philippe.gentric@philips.com] > > Sent: Thursday, November 20, 2003 12:23 PM > > To: Phelan, Tom; 'Rosen, Brian' > > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Brian, all, > > > > It may provide some help in understanding the situation > > to describe your exemple as follows: > > > > * you send video at 4 Mb/s, good. > > > > * it happens that you are competing with (a lot of ) TCP > > > > AND that you want to be fair to it: > > > > * so when that happens you decrease your rate to 2 Mb/s for "a while" > > because otherwise you are not fair. > > > > * but at some moment you will want to come back up to 4 Mb/s right ? > > > > => the point is that the **only way** to know if you "can" > > do that, is to try it.... > > > > regards, > > > > > > Philippe Gentric > > Chief Architect > > Philips Software > > philippe.gentric@philips.com > > http://www.software.philips.com > > > > > > > > > > > > > > > > > > To: > > "'Rosen, Brian'" > > > > cc: > > "'dccp@ietf.org'" > > > > > > "'avt@ietf.org'" > > > > > > "'mmusic@ietf.org'" > > > > "Phelan, Tom" (bcc: > > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > > > Subject: > > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > Sent by: > > Classification: > > > > mmusic-admin@ietf.org > > > > > > > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Brian, > > > > Thanks for the comments. See inline ... > > > > Tom P. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, November 20, 2003 11:05 AM > > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > To me, this is just nonsense. > > > I can't imagine anyone deploying such a solution. > > > > > > This is forcing the problem to fit the solution, and it's not > > > the right way to go. If you want it to work, the protocol > > > has to take the characteristics of the flows as they are, and not > > > as you would like them to be. Real time media, streaming > > or realtime, > > > is either constant bit rate, or pretty close to it. That's how it > > > works. Our challenge is to make the protocols work with this data, > > > not change the data, especially silly ideas like doubling the > > > bandwidth. > > > > > > We make video telephones. They nominally send 4 megabits. Would > > > you like us to double that, under any circumstances? > > > > > > I thought not. > > > > Would you prefer to be forced unnecessarily into packet loss > > and a lower > > encoding rate by greedy TCP applications? Or do you have > > another solution? > > > > I don't think I'm forcing the problem to fit the solution, > > just perhaps that > > the problem I'm trying to solve is different than you > > perceive. The problem > > that I'm trying to solve is how can an application that is > > content with a > > maximum bandwidth compete with TCP applications that are > > insatiably greedy, > > in a way that satisfies some concept of fairness in all directions? > > > > The solution that I see is to provide a buffer against TCP > > probing. This > > would involve sending more data than is nominally necessary. > > If the network > > has capacity for more than 4M bps, then why shouldn't a media > > app make use > > of it? A TCP app would. > > > > I must admit that my initial reactions to suggestions like > > this were very > > similar to yours. I encourage you to look at the draft for > > more detail on > > the issues that convinced me otherwise. > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > > Sent: Thursday, November 20, 2003 10:36 AM > > > > To: 'Jonathan Rosenberg' > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Hi Jonathan, > > > > > > > > Thanks for the comments. The actual proposal is to send up > > > > to double the > > > > nominal transmit rate when there's available bandwidth, and > > > > to reduce the > > > > rate as necessary if there isn't enough bandwidth. This > > > > doubling is to > > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > > media apps and > > > > TCP apps), and to avoid what appears to me to be the > > > > potential for bullying > > > > from TCP applications that want to suck up all the bandwidth > > > > they can. It > > > > doesn't preclude using low-rate codecs, or mean that the > > > > access link must > > > > support the double rate for the connection to function well. > > > > > > > > This recommendation was meant for best-effort environments, > > > > where the voice > > > > traffic receives no special treatment, and must compete with > > > > TCP apps for > > > > network resources. I can see how this would require a > > > > network that gave > > > > special treatment to voice packets to provision double the > > > > capacity, though. > > > > > > > > This fairness problem is difficult. All of the research I'm > > > > familiar with > > > > approaches it from the direction of other apps being fair to > > > > TCP. I'm not > > > > aware of any other methods for ensuring that non-TCP apps get > > > > their fair > > > > share when competing with TCP. If you (or anyone else) knows > > > > of something > > > > I'd appreciate the pointer. > > > > > > > > Tom P. > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > > To: Phelan, Tom > > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > Tom, > > > > > > > > > > I don't think this solution will be acceptable to many of > > > > the network > > > > > providers of interactive voip services. Many of them are > > > > insistent on > > > > > using low rate codecs, like g.723, in order to reduce the > > > costs of > > > > > capacity in their networks. Doubling the rate would defeat > > > > > the purpose > > > > > of using these low rate codecs in the first place. > > > > > > > > > > -Jonathan R. > > > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > > suggestion that > > > > > > media apps should transmit at up to twice their nominal > > > > > maximum rate, when > > > > > > DCCP allows it, in order to provide protection from > > > competing TCP > > > > > > applications. I know that the first time I heard someone > > > > > make a similar > > > > > > suggestion I was horrified, but as I developed the issues > > > > > it seemed to be > > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > > > Tom P. > > > > > > > > > > > > _______________________________________________ > > > > > > mmusic mailing list > > > > > > mmusic@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > > Chief Technology Officer Parsippany, NJ > > > > 07054-2711 > > > > > dynamicsoft > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.jdrosen.net PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 17:16:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03003 for ; Thu, 20 Nov 2003 17:16:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5p-0000uM-J1 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 17:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMG5HA003483 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 17:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5p-0000tv-6f for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 17:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02957 for ; Thu, 20 Nov 2003 17:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMx5m-00059d-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 17:16:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMx5m-00059a-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 17:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5l-0000rA-RE; Thu, 20 Nov 2003 17:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx4o-0000nV-05 for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 17:15: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 RAA02892; Thu, 20 Nov 2003 17:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMx4k-00058N-00; Thu, 20 Nov 2003 17:14:58 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMx4j-00057U-00; Thu, 20 Nov 2003 17:14:58 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09118; Thu, 20 Nov 2003 17:14:24 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13114; Thu, 20 Nov 2003 17:14:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 17:14:24 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6102@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Caitlin Bestler'" , Qiaobing Xie Cc: mmusic@ietf.org, TSV WG list , "Phelan, Tom" , avt@ietf.org, dccp@ietf.org, philippe.gentric@philips.com Subject: RE: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 17:14:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , The reason to "avoid" TCP friendly rate control is, at least so far, because there is no way yet proposed to do it without destroying the usability of the RTP flow. Part of the problem is that the only "rate control" that works is to negotiate an acceptable rate in the signalling before the stream starts. There really isn't any other way to change the rate, at least for interactive streams. For non-interactive streams, you can always buffer more, which allows you some short term variation. I don't think that any of the proposed mechanisms would actually work even in that case, but maybe there is a way to do something. Non interactive streams need CBR averaged over the buffer time. That can be up to seconds in some cases, hundreds of milliseconds in other cases, but over that interval, your goodput must equate to the transmit offer rate times the interval (some small loss rate acceptable). It would be nice if there was a way. I haven't seen one yet. Brian > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, November 20, 2003 5:02 PM > To: Qiaobing Xie > Cc: mmusic@ietf.org; 'Rosen, Brian'; TSV WG list; Phelan, Tom; > avt@ietf.org; dccp@ietf.org; philippe.gentric@philips.com > Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP > Media Guide > > > > On Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote: > > > Hi, Tom, > > > > It seems to me that you are basically: 1) questioning the > fairness of > > TCP itself > > and, 2) you want to do something in the app level to > outmaneuver TCP > > so as to > > achieve your term of fairness. > > > > I am not convinced this is the right thing to do with DCCP. > > > > I remember similar issue was discussed on tsvwg list (I am > cc'ing it). > > Maybe > > people in tsvwg can share their thoughts on this as well. > > > The fairness of TCP itself could use some questioning -- but I do not > believe that is a reason to evade TCP friendly rate control. > > Eventually, there should be a solution for proper support of > predictably > variable rate flows that have fixed delivery requirements. But that > solution > should be developed considering TCP, SCTP and DCCP as a whole. > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 17:20:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03279 for ; Thu, 20 Nov 2003 17:20: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 1AMx9g-0001M4-U2 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 17:20:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMK4qP005125 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 17:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx9f-0001KW-CC for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 17:20: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 RAA03243 for ; Thu, 20 Nov 2003 17:19:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMx9c-0005HP-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 17:20:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMx9c-0005HM-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 17:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx9d-0001Ip-UF; Thu, 20 Nov 2003 17:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwsh-00005g-W5 for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 17:02: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 RAA02091; Thu, 20 Nov 2003 17:02:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwsf-0004qI-00; Thu, 20 Nov 2003 17:02:29 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AMwse-0004pe-00; Thu, 20 Nov 2003 17:02:28 -0500 Received: from [192.168.0.101] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6A1D2246142; Thu, 20 Nov 2003 17:02:31 -0500 (EST) In-Reply-To: <3FBD1558.C10047DF@motorola.com> References: <3FBD1558.C10047DF@motorola.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, "'Rosen, Brian'" , TSV WG list , "Phelan, Tom" , avt@ietf.org, dccp@ietf.org, philippe.gentric@philips.com From: Caitlin Bestler Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 16:01:47 -0600 To: Qiaobing Xie X-Mailer: Apple Mail (2.606) 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 Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote: > Hi, Tom, > > It seems to me that you are basically: 1) questioning the fairness of > TCP itself > and, 2) you want to do something in the app level to outmaneuver TCP > so as to > achieve your term of fairness. > > I am not convinced this is the right thing to do with DCCP. > > I remember similar issue was discussed on tsvwg list (I am cc'ing it). > Maybe > people in tsvwg can share their thoughts on this as well. The fairness of TCP itself could use some questioning -- but I do not believe that is a reason to evade TCP friendly rate control. Eventually, there should be a solution for proper support of predictably variable rate flows that have fixed delivery requirements. But that solution should be developed considering TCP, SCTP and DCCP as a whole. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 20 17:22:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03338 for ; Thu, 20 Nov 2003 17:22:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxBa-0001Vy-FR for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 17:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMM2aA005816 for mmusic-archive@odin.ietf.org; Thu, 20 Nov 2003 17:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxBa-0001Vj-9F for mmusic-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 17:22: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 RAA03327 for ; Thu, 20 Nov 2003 17:21:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxBX-0005JN-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 17:21:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMxBX-0005JK-00 for mmusic-web-archive@ietf.org; Thu, 20 Nov 2003 17: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 1AMxBZ-0001Tz-8l; Thu, 20 Nov 2003 17: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 1AMxBX-0001Tg-2F for mmusic@optimus.ietf.org; Thu, 20 Nov 2003 17:21: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 RAA03324 for ; Thu, 20 Nov 2003 17:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxBU-0005JH-00 for mmusic@ietf.org; Thu, 20 Nov 2003 17:21:56 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AMxBU-0005Ib-00 for mmusic@ietf.org; Thu, 20 Nov 2003 17:21:56 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60433 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AMxAz-0002ad-00; Thu, 20 Nov 2003 22:21:25 +0000 Date: Thu, 20 Nov 2003 22:21:23 +0000 Subject: Re: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: To: vandana.yesoda@wipro.com From: Colin Perkins In-Reply-To: <3C48D0DE93819942B475859DCF1B19C98D5BE8@blr-ec-msg01.wipro.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.553) 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Wednesday, Nov 19, 2003, at 09:18 Europe/London,=20 vandana.yesoda@wipro.com wrote: > I tried to get the following file from internet and using=20 > mailserv@etf.org.=A0 > draft-ietf-mmusic-confarch-03.txt > Can any one send me this file? That draft expired 3 years ago, and is likely only of historical=20 interest now. You can find a copy at=20 http://www.ietf.org/proceedings/00jul/I-D/mmusic-confarch-03.txt --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 21 05:05:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07814 for ; Fri, 21 Nov 2003 05:05: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 1AN89o-0003RJ-Ii for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 05:04:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALA4usH013216 for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 05:04:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN89m-0003Qz-PY for mmusic-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 05:04: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 FAA07794 for ; Fri, 21 Nov 2003 05:04:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN89j-0007PM-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 05:04:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN89i-0007P0-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 05:04:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN88w-0003Ks-Jp; Fri, 21 Nov 2003 05:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN881-0003JD-LM for mmusic@optimus.ietf.org; Fri, 21 Nov 2003 05:03: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 FAA07750 for ; Fri, 21 Nov 2003 05:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN87y-0007Nz-00 for mmusic@ietf.org; Fri, 21 Nov 2003 05:03:02 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AN87x-0007N2-00 for mmusic@ietf.org; Fri, 21 Nov 2003 05:03:01 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id hALA2VpI020816; Fri, 21 Nov 2003 11:02:31 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hALA2VR7014002; Fri, 21 Nov 2003 11:02:31 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hALA2VfF014001; Fri, 21 Nov 2003 11:02:31 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 21 Nov 2003 11:02:31 +0100 From: Stig Venaas To: Gonzalo Camarillo Cc: mmusic@ietf.org Subject: Re: [MMUSIC] some comments on IPV and ICE Message-ID: <20031121100230.GC13937@sverresborg.uninett.no> References: <20031119125913.GB9257@sverresborg.uninett.no> <3FBB6D73.4080802@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBB6D73.4080802@ericsson.com> User-Agent: Mutt/1.4.1i 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: , Thanks Gonzalo, but I still think there are problems, see below. On Wed, Nov 19, 2003 at 03:17:39PM +0200, Gonzalo Camarillo wrote: [...] > Regarding your comment about dual-stack UAs, I do not see any problem > related to the use of IPV. Wouldn't dual-stack UAs that don't support IPV try to use both media descriptions and try to establish two connections/streams? Isn't that also why it in section 5 of IPV says: It is STRONGLY RECOMMENDED that dual-stack IPv6/IPv4 hosts implement the IPV semantics. Dual-stack hosts that failed to implement IPV would need more RTTs to establish a session with a single-stack host. When acting as answerers, they would establish more media streams than needed. This could increase the session bandwidth in the first instants of the session, until the remote end could issue a new offer with only one m= line. Since there's alreay a large number of systems that are dual-stack, and there probably will be even more in the future, I think one should try to avoid such a requirement. I understand that the IPV solution is useful to single-stack systems, but I'm afraid it will create too many problems for existing dual-stack systems. Stig _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 21 05:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08875 for ; Fri, 21 Nov 2003 05:36: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 1AN8dx-0006JX-7V for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 05:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALAa5GI024267 for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 05: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 1AN8dx-0006JK-2v for mmusic-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 05: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 FAA08853 for ; Fri, 21 Nov 2003 05:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8dt-000066-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 05:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN8ds-000063-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 05:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8dv-0006Ii-7i; Fri, 21 Nov 2003 05:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8dd-0006Hw-Qs for mmusic@optimus.ietf.org; Fri, 21 Nov 2003 05: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 FAA08830 for ; Fri, 21 Nov 2003 05:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8da-00005I-00 for mmusic@ietf.org; Fri, 21 Nov 2003 05:35:42 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AN8dZ-000053-00 for mmusic@ietf.org; Fri, 21 Nov 2003 05:35:41 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALAZfSs016237; Fri, 21 Nov 2003 11:35:41 +0100 (MET) Received: from ericsson.com (rvi2-92-168.sw.ericsson.se [153.88.92.168]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id X16VWX0D; Fri, 21 Nov 2003 11:34:49 +0100 Message-ID: <3FBDEA7B.60300@ericsson.com> Date: Fri, 21 Nov 2003 12:35:39 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo 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: en-us, en MIME-Version: 1.0 To: Stig Venaas CC: mmusic@ietf.org Subject: Re: [MMUSIC] some comments on IPV and ICE References: <20031119125913.GB9257@sverresborg.uninett.no> <3FBB6D73.4080802@ericsson.com> <20031121100230.GC13937@sverresborg.uninett.no> In-Reply-To: <20031121100230.GC13937@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I got the same comment during the MMUSIC presentation. I have added a section that defines a SIP option-tag and that explains what can happen in you do not use it (basically it explains what you also point out in your mail.) I intend to release a new version of the draft pretty soon. I hope it will address all the comments that I have received from the group. Thanks for your comments, Gonzalo Stig Venaas wrote: > Thanks Gonzalo, but I still think there are problems, see below. > > On Wed, Nov 19, 2003 at 03:17:39PM +0200, Gonzalo Camarillo wrote: > [...] > >>Regarding your comment about dual-stack UAs, I do not see any problem >>related to the use of IPV. > > > Wouldn't dual-stack UAs that don't support IPV try to use both > media descriptions and try to establish two connections/streams? > > Isn't that also why it in section 5 of IPV says: > > It is STRONGLY RECOMMENDED that dual-stack IPv6/IPv4 hosts implement > the IPV semantics. Dual-stack hosts that failed to implement IPV > would need more RTTs to establish a session with a single-stack host. > When acting as answerers, they would establish more media streams > than needed. This could increase the session bandwidth in the first > instants of the session, until the remote end could issue a new offer > with only one m= line. > > Since there's alreay a large number of systems that are dual-stack, > and there probably will be even more in the future, I think one > should try to avoid such a requirement. > > I understand that the IPV solution is useful to single-stack systems, > but I'm afraid it will create too many problems for existing dual-stack > systems. > > Stig -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 21 06:53:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10826 for ; Fri, 21 Nov 2003 06:53: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 1AN9qU-0001ly-1c for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 06:53:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALBr5kw006808 for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 06:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9qT-0001lj-Tj for mmusic-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 06:53: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 GAA10775 for ; Fri, 21 Nov 2003 06:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9qP-00012h-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 06:53:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN9qP-00012e-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 06:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9qQ-0001jJ-CO; Fri, 21 Nov 2003 06:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9pX-0001iP-UQ for mmusic@optimus.ietf.org; Fri, 21 Nov 2003 06:52: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 GAA10763; Fri, 21 Nov 2003 06:51:52 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9pT-00012S-00; Fri, 21 Nov 2003 06:52:03 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AN9pS-00012P-00; Fri, 21 Nov 2003 06:52:02 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 1586661363; Fri, 21 Nov 2003 12:51:56 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 4FF7819C52; Fri, 21 Nov 2003 12:51:55 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id D869019C4D; Fri, 21 Nov 2003 12:51:54 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id MAA23374; Fri, 21 Nov 2003 12:51:54 +0100 (MET) Subject: RE: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: "Rosen, Brian" Cc: avt@ietf.org, dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 21 Nov 2003 12:49:14 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 21/11/2003 12:53:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Brian, you wrote: >The reason to "avoid" TCP friendly rate control is, at least so far, >because there is no way yet proposed to do it without destroying the >usability of the RTP flow. I aggree this is a chalenge and especially I think that the availability of codecs for which the rate can be rapidly changed over wide ranges is key. >Part of the problem is that the only "rate control" that works is to >negotiate an acceptable rate in the signalling before the stream starts. >There really isn't any other way to change the rate, at least for >interactive streams. This is where progress must be done: there is a need for signaling that the rate must change, during the streaming. >For non-interactive streams, you can always buffer more, which allows >you some short term variation. I don't think that any of the proposed >mechanisms would actually work even in that case, but maybe there is >a way to do something. Stream switching is a solution. regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Nov 21 10:45:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18551 for ; Fri, 21 Nov 2003 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 1ANDT3-0006fV-Qz for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 10:45:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFj9xi025632 for mmusic-archive@odin.ietf.org; Fri, 21 Nov 2003 10:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDT3-0006fL-LM for mmusic-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 10:45: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 KAA18497 for ; Fri, 21 Nov 2003 10:44:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDT1-0003vY-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 10:45:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANDT0-0003vU-00 for mmusic-web-archive@ietf.org; Fri, 21 Nov 2003 10:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSy-0006aN-MU; Fri, 21 Nov 2003 10:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSl-0006V3-8S for mmusic@optimus.ietf.org; Fri, 21 Nov 2003 10:44: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 KAA18480; Fri, 21 Nov 2003 10:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDSi-0003vC-00; Fri, 21 Nov 2003 10:44:48 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ANDSh-0003v9-00; Fri, 21 Nov 2003 10:44:48 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALFilSs004253; Fri, 21 Nov 2003 16:44:47 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFF6ZG50; Fri, 21 Nov 2003 16:44:46 +0100 Message-ID: <3FBE32EC.5000400@ericsson.com> Date: Fri, 21 Nov 2003 16:44:44 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org, TSV WG list , avt@ietf.org, dccp@ietf.org CC: "Phelan, Tom" References: <3FBD1558.C10047DF@motorola.com> <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> In-Reply-To: <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] DCCP Media Guide - STOP crossposting 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, Please don't crosspost to all these lists. It creates problems for the list managers and will fragment the discussion. As long as we are discussing issues related to media and DCCP please keep these topics on the AVT mailing list. Other DCCP related issues goes on the DCCP list. Best Regards 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 Sun Nov 23 03:26:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16470 for ; Sun, 23 Nov 2003 03:26:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANpZM-0000sb-VV for mmusic-archive@odin.ietf.org; Sun, 23 Nov 2003 03:26:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAN8QCI0003380 for mmusic-archive@odin.ietf.org; Sun, 23 Nov 2003 03:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANpZM-0000sR-A4 for mmusic-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 03:26: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 DAA16467 for ; Sun, 23 Nov 2003 03:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANpZJ-0000QL-00 for mmusic-web-archive@ietf.org; Sun, 23 Nov 2003 03:26:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANpZJ-0000QH-00 for mmusic-web-archive@ietf.org; Sun, 23 Nov 2003 03:26:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANpZD-0000rv-9k; Sun, 23 Nov 2003 03:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANpYr-0000rG-6O for mmusic@optimus.ietf.org; Sun, 23 Nov 2003 03:25: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 DAA16462 for ; Sun, 23 Nov 2003 03:25:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANpYo-0000QD-00 for mmusic@ietf.org; Sun, 23 Nov 2003 03:25:38 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1ANpYi-0000PT-00 for mmusic@ietf.org; Sun, 23 Nov 2003 03:25:37 -0500 Received: by accord-ntsrv3.polycom.co.il with Internet Mail Service (5.5.2656.59) id ; Sun, 23 Nov 2003 10:24:53 +0200 Message-ID: From: "Even, Roni" To: "'vandana.yesoda@wipro.com'" , mmusic@ietf.org Subject: RE: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Date: Sun, 23 Nov 2003 10:24:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B19B.44B33BB0" 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: , 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_01C3B19B.44B33BB0 Content-Type: text/plain; charset="ISO-8859-1" Hi, If you are interested in conferencing architecture look at http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-conferencing-framework -01.txt http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-conferencing-framework -01.txt Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: vandana.yesoda@wipro.com [mailto:vandana.yesoda@wipro.com] Sent: Wednesday, November 19, 2003 11:18 AM To: mmusic@ietf.org Subject: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Hi, I tried to get the following file from internet and using mailserv@etf.org . draft-ietf-mmusic-confarch-03.txt Can any one send me this file? Thanks 'n Rgds Vandana ------_=_NextPart_001_01C3B19B.44B33BB0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
If you=20 are interested in conferencing architecture look at
http://www.softarmor.com/wgdb/docs/draft-ietf-sippi= ng-conferencing-framework-01.txt
http://www.softarmor.com/wgdb/docs/draft-ietf-sippi= ng-conferencing-framework-01.txt
 
Roni

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

Roni Even

Polycom Israel

Tel: +972-3-9251200

Cell: = +972-55-481099

email:roni.even@polycom.co.il

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

-----Original Message-----
From: = vandana.yesoda@wipro.com=20 [mailto:vandana.yesoda@wipro.com]
Sent: Wednesday, November = 19, 2003=20 11:18 AM
To: mmusic@ietf.org
Subject: [MMUSIC]=20 draft-ietf-mmusic-confarch-03.txt

Hi,

 

I tried to get the = following file=20 from internet and using mailserv@etf.org.=

 

draft-ietf-mmusic-confarch-03.txt

 

Can any one send me = this=20 file?

 =20

Thanks 'n=20 Rgds

Vandana

 

------_=_NextPart_001_01C3B19B.44B33BB0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 23 05:13:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17934 for ; Sun, 23 Nov 2003 05:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANrEl-0007Ac-74 for mmusic-archive@odin.ietf.org; Sun, 23 Nov 2003 05:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANAD3q5027563 for mmusic-archive@odin.ietf.org; Sun, 23 Nov 2003 05:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANrEl-0007AU-1K for mmusic-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 05:13: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 FAA17928 for ; Sun, 23 Nov 2003 05:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANrEh-0001Gq-00 for mmusic-web-archive@ietf.org; Sun, 23 Nov 2003 05:12:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANrEh-0001Gn-00 for mmusic-web-archive@ietf.org; Sun, 23 Nov 2003 05: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 1ANrEj-00079x-2S; Sun, 23 Nov 2003 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 1ANrDp-00079i-Ma for mmusic@optimus.ietf.org; Sun, 23 Nov 2003 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 FAA17916 for ; Sun, 23 Nov 2003 05:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANrDm-0001GU-00 for mmusic@ietf.org; Sun, 23 Nov 2003 05:12:02 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1ANrDl-0001GN-00 for mmusic@ietf.org; Sun, 23 Nov 2003 05:12:01 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hANAC0128043; Sun, 23 Nov 2003 11:12:00 +0100 (CET) From: "Gunnar Hellstrom" To: , , "Even, Roni" Cc: "Toip list" Subject: RE: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Date: Sun, 23 Nov 2003 11:11:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3B1B2.9D522FD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C3B1B2.9D522FD0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id hANAC0128043 Content-Transfer-Encoding: quoted-printable A good draft! Just in order to keep the awareness alive that we have three common real time streaming media to handle in conferences, ( video, text and audio ) = I have added a couple of proposed examples of media policies regarding the text medium that was missing. Otherwise the draft is general and valid for these three media and more. 4.6 Conference Policy -------snip------ ---------- note proposed additions about the text medium in the examples below----assuming that the basic display of text from each participant displayed under video from that participant is the common understanding already established in other specifications----------------- Some examples of media policies include: o The video output is the picture of the loudest speaker (video follows audio). o The audio from each participant will be mixed with equal weight, and distributed to all other participants. o The video from a participant can be associated with a text generati= ng participant, so that when this video is output, the text from the text source is also displayed. (useful for real time subtitling) =2E o The audio, text and video that is distributed is the one selected b= y the floor control server. o The text from all participants is displayed in one common area in traditional IRC style. -----------------------------------------end of proposal-----------------------------------------------------------------= --- ------------------------------------ Regards Gunnar Hellstr=F6m ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of Even, Roni Sent: Sunday, November 23, 2003 9:25 AM To: 'vandana.yesoda@wipro.com'; mmusic@ietf.org Subject: RE: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Hi, If you are interested in conferencing architecture look at http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-conferencing-framew= ork -01.txt http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-conferencing-framew= ork -01.txt Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: vandana.yesoda@wipro.com [mailto:vandana.yesoda@wipro.com] Sent: Wednesday, November 19, 2003 11:18 AM To: mmusic@ietf.org Subject: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Hi, I tried to get the following file from internet and using mailserv@etf.org. draft-ietf-mmusic-confarch-03.txt Can any one send me this file? Thanks 'n Rgds Vandana ------=_NextPart_000_000F_01C3B1B2.9D522FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A good=20 draft!
 
Just=20 in order to keep the awareness alive that we have three common real time = streaming media to handle in conferences, ( video, text and audio ) I = have added=20 a couple of proposed examples of media policies regarding the text = medium that=20 was missing.
Otherwise the draft is general and valid for = these=20 three media and more.
 
 

4.6 = Conference=20 Policy
-------snip------
---------- note proposed = additions about=20 the text medium in the examples below----assuming that the basic display = of text=20 from each participant displayed under video from that participant is the = common=20 understanding already established in other=20 specifications-----------------

   Some examples of media policies=20 include:

   o  The video output is the picture of = the=20 loudest speaker (video
      follows=20 audio).

   o  The audio from each participant will = be=20 mixed with equal weight,
      and = distributed to=20 all other participants.
 
   o  The = video from=20 a participant can be = associated=20 with a text generating participant,
      so = that when=20 this video is output, the text from the text source is also=20 displayed.
      (useful for real time=20 subtitling) 
.

   = o  The=20 audio, text and video that = is=20 distributed is the one selected by the
      = floor=20 control server.

   o  The text from=20 all participants is displayed in one common area in traditional IRC=20 style.
-----------------------------------------end = of=20 proposal-----------------------------------------------------------------= ---------------------------------------
Regards
Gunnar=20 Hellstr=F6m

-------------------------------------------
Gunnar=20 Hellstr=F6m
Omnitor AB
Renathv=E4gen 2
SE 121 37=20 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204=20 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
-----------------= ---------------------------
 =20

-----Original Message-----
From: = mmusic-admin@ietf.org=20 [mailto:mmusic-admin@ietf.org]On Behalf Of Even, = Roni
Sent:=20 Sunday, November 23, 2003 9:25 AM
To: = 'vandana.yesoda@wipro.com';=20 mmusic@ietf.org
Subject: RE: [MMUSIC]=20 draft-ietf-mmusic-confarch-03.txt

Hi,
If=20 you are interested in conferencing architecture look = at
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping= -conferencing-framework-01.txt
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping= -conferencing-framework-01.txt
 
Roni

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

Roni Even

Polycom Israel

Tel: = +972-3-9251200

Cell: = +972-55-481099

email:roni.even@polycom.co.il

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

-----Original Message-----
From: = vandana.yesoda@wipro.com=20 [mailto:vandana.yesoda@wipro.com]
Sent: Wednesday, = November 19,=20 2003 11:18 AM
To: mmusic@ietf.org
Subject: = [MMUSIC]=20 draft-ietf-mmusic-confarch-03.txt

Hi,

 

I tried to get the = following=20 file from internet and using mailserv@etf.org.<= /FONT>

 

draft-ietf-mmusic-confarch-03.txt

 

Can any one send me = this=20 file?

 =20

Thanks 'n=20 Rgds

Vandana

 

= ------=_NextPart_000_000F_01C3B1B2.9D522FD0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 23 07:46:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20112 for ; Sun, 23 Nov 2003 07:46: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 1ANtcv-0003J5-LM for mmusic-archive@odin.ietf.org; Sun, 23 Nov 2003 07:46:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANCk9hh012705 for mmusic-archive@odin.ietf.org; Sun, 23 Nov 2003 07:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtcv-0003Iq-HP for mmusic-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 07:46:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20109 for ; Sun, 23 Nov 2003 07:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANtcu-0002Uv-00 for mmusic-web-archive@ietf.org; Sun, 23 Nov 2003 07:46:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANtct-0002Us-00 for mmusic-web-archive@ietf.org; Sun, 23 Nov 2003 07:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtcn-0003IA-TE; Sun, 23 Nov 2003 07:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCvg-0004bg-WB for mmusic@optimus.ietf.org; Fri, 21 Nov 2003 10:10: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 KAA16615; Fri, 21 Nov 2003 10:10:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANCve-0003SL-00; Fri, 21 Nov 2003 10:10:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ANCve-0003S5-00; Fri, 21 Nov 2003 10:10:38 -0500 Received: from mramalho-w2k.cisco.com (dhcp-wtn-161-44-35-83.cisco.com [161.44.35.83]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALFA2xh026311; Fri, 21 Nov 2003 10:10:03 -0500 (EST) Message-Id: <4.3.2.7.2.20031121093326.00b6e458@mira-sjc5-e.cisco.com> X-Sender: mramalho@mira-sjc5-e.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 10:10:02 -0500 To: "Phelan, Tom" From: "Michael A. Ramalho" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Cc: "'Rosen, Brian'" , "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 11:47 AM 11/20/2003 -0500, Phelan, Tom wrote: >I don't think I'm forcing the problem to fit the solution, just perhaps that >the problem I'm trying to solve is different than you perceive. The problem >that I'm trying to solve is how can an application that is content with a >maximum bandwidth compete with TCP applications that are insatiably greedy, >in a way that satisfies some concept of fairness in all directions? > >The solution that I see is to provide a buffer against TCP probing. This >would involve sending more data than is nominally necessary. If the network >has capacity for more than 4M bps, then why shouldn't a media app make use >of it? A TCP app would. I think this snippet captures the essence of the argument. An "insatiably greedy" TCP application has an infinite amount of data to send. And "fairness" in "TCP-land" is ONLY FAIRNESS IN INSTANTANEOUS BANDWIDTH ALLOCATION (across TCP/DCCP/SCTP connections/associations). This is historically how TCP has been viewed. But wait ... if you delay the "infinite amount of data" in the TCP socket .... what bad happens? Nothing, it just takes longer (from a "work conservation viewpoint") to send the data. Did TCP suffer? Well ... it got less work per unit time ... but nothing really bad occurred for the "insatiable TCP" case. Most real-time data is DELAY SENSITIVE. To real-time data ... it would be "fair" to delay some of the TCP data during it's bursts (like some video codecs have when a high-entropy scene change occurs). That is because TCP can afford to "wait a little longer" to get it's data across. The bursts are usually bounded in time (a talkspurt, a scene change, etc.) ... and TCP can usually afford to wait through these bursts. From the real-time application's perspective they are being "good citizens" by not using bandwidth when they don't need to (during VAD/silence or no video scene changes). Can't the TCP apps step aside for a moment and acknowledge their good citizenship? To be fair ... we really need to re-evaluate the issue of "fairness" capturing more than just an INSTANTANEOUS BANDWIDTH ALLOCATION dimension. Is it "fair" to slow down TCP more than present mechanisms allow? For a "insatiably greedy" TCP connection the answer may be yes. For a TCP session with a reasonably bounded amount of data the answer maybe no - because there is a linear relationship with how long the data will take to get to the other side and the slowdown rate. This is a really tough problem. Why this post? Simply because I'd desire each camp to widen their vision of what is "fair/right/best" from their own myopic point of view. TCP'ers should try to capture the spirit of Brian's comment ... that "forcing the problem to fit [TCP's view of] a solution" is not appropriate. And that is, in fact, what I perceive all the well-intentioned "TCP rate control" crowd to be doing here. Please widen your perspective of the problem. Then comment. Don't expect people like Brian to be happy with the "you must fit in to TCPs view of the world" when most of their real-time applications are already being good citizens (by not sending "all they can" when they don't have to). Do you like being further punished because you weren't greedy when you could have been? Michael Ramalho _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Nov 24 11:16:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14629 for ; Mon, 24 Nov 2003 11:16: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 1AOJNi-0005lo-05 for mmusic-archive@odin.ietf.org; Mon, 24 Nov 2003 11:16:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGG9Bx022177 for mmusic-archive@odin.ietf.org; Mon, 24 Nov 2003 11:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJNh-0005lc-3r for mmusic-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 11:16: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 LAA14626 for ; Mon, 24 Nov 2003 11:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJNc-0007aS-00 for mmusic-web-archive@ietf.org; Mon, 24 Nov 2003 11:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOJNc-0007aO-00 for mmusic-web-archive@ietf.org; Mon, 24 Nov 2003 11:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJNZ-0005kX-TM; Mon, 24 Nov 2003 11:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO60r-0005bC-67 for mmusic@optimus.ietf.org; Sun, 23 Nov 2003 20:59: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 UAA07396 for ; Sun, 23 Nov 2003 20:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO60o-0002jP-00 for mmusic@ietf.org; Sun, 23 Nov 2003 20:59:38 -0500 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AO60n-0002jK-00 for mmusic@ietf.org; Sun, 23 Nov 2003 20:59:37 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hAO1wxGW023265 for ; Sun, 23 Nov 2003 20:59:08 -0500 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3FA53961005F7EA2; Sun, 23 Nov 2003 20:56:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B22E.8A51B228" Subject: RE: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Date: Sun, 23 Nov 2003 20:59:05 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A058E7C94@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Thread-Index: AcOxql9CtfoAsIEzTNe0h7sFo/fAmwAgkuLg From: "Roy, Radhika R, ALABS" To: "Gunnar Hellstrom" , , , "Even, Roni" Cc: "Toip list" 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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B22E.8A51B228 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Gunnar. =20 I am adding more. Kindly see inline [RRR]. =20 Best regards, Radhika -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: Sunday, November 23, 2003 5:12 AM To: mmusic@ietf.org; vandana.yesoda@wipro.com; Even, Roni Cc: Toip list Subject: RE: [MMUSIC] draft-ietf-mmusic-confarch-03.txt A good draft! =20 Just in order to keep the awareness alive that we have three common real = time streaming media to handle in conferences, ( video, text and audio ) = I have added a couple of proposed examples of media policies regarding = the text medium that was missing.=20 Otherwise the draft is general and valid for these three media and more. =20 =20 4.6 Conference Policy -------snip------ ---------- note proposed additions about the text medium in the examples = below----assuming that the basic display of text from each participant = displayed under video from that participant is the common understanding = already established in other specifications----------------- Some examples of media policies include: o The video output is the picture of the loudest speaker (video follows audio). o The audio from each participant will be mixed with equal weight, and distributed to all other participants. [Roy, Radhika R, ALSO] If the real-time text is used as an alternative = of audio from any participant, the mixing and distribution should also = be taken into account appropriately. =20 o The video from a participant can be associated with a text = generating participant, so that when this video is output, the text from the text source = is also displayed. (useful for real time subtitling)=20 . o The audio, text and video that is distributed is the one selected = by the floor control server. [Roy, Radhika R, ALSO] If real-time text is used as an alternative of = audio from any participant, the selection and distribution of the media = should also be taken into account appropriately by the floor control = server. o The text from all participants is displayed in one common area in = traditional IRC style. -----------------------------------------end of = proposal-----------------------------------------------------------------= --------------------------------------- Regards Gunnar Hellstr=F6m ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- =20 -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of = Even, Roni Sent: Sunday, November 23, 2003 9:25 AM To: 'vandana.yesoda@wipro.com'; mmusic@ietf.org Subject: RE: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Hi, If you are interested in conferencing architecture look at http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-conferencing-framew= ork-01.txt http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-conferencing-framew= ork-01.txt =20 Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: vandana.yesoda@wipro.com [mailto:vandana.yesoda@wipro.com] Sent: Wednesday, November 19, 2003 11:18 AM To: mmusic@ietf.org Subject: [MMUSIC] draft-ietf-mmusic-confarch-03.txt Hi, =20 I tried to get the following file from internet and using = mailserv@etf.org. =20 draft-ietf-mmusic-confarch-03.txt =20 Can any one send me this file? =20 Thanks 'n Rgds Vandana =20 ------_=_NextPart_001_01C3B22E.8A51B228 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 agree with Gunnar.
 
I am=20 adding more. Kindly see inline [RRR].
 
Best=20 regards,
Radhika
-----Original Message-----
From: Gunnar Hellstrom=20 [mailto:gunnar.hellstrom@omnitor.se]
Sent: Sunday, November = 23, 2003=20 5:12 AM
To: mmusic@ietf.org; vandana.yesoda@wipro.com; Even, = Roni
Cc: Toip list
Subject: RE: [MMUSIC]=20 draft-ietf-mmusic-confarch-03.txt

A=20 good draft!
 
Just=20 in order to keep the awareness alive that we have three common real = time=20 streaming media to handle in conferences, ( video, text and audio ) I = have=20 added a couple of proposed examples of media policies regarding the = text=20 medium that was missing.
Otherwise the draft is general and valid = for these=20 three media and more.
 
 

4.6 = Conference=20 Policy
-------snip------
---------- note proposed = additions about=20 the text medium in the examples below----assuming that the basic = display of=20 text from each participant displayed under video from that participant = is the=20 common understanding already established in other=20 specifications-----------------

   Some examples of media policies=20 include:

   o  The video output is the picture = of the=20 loudest speaker (video
      follows=20 audio).

   o  The audio from each participant = will be=20 mixed with equal weight,
      and = distributed to=20 all other participants.
[Roy, Radhika R, ALSO] If the real-time = text is used=20 as an alternative of audio from any participant, the mixing and=20 distribution should also be taken into account=20 appropriately.
 
   o  The = video from=20 a participant can be = associated with a text generating participant,
      = so that=20 when this video is output, the text from the text source is also=20 displayed.
      (useful for real = time=20 subtitling) 
.

   = o  The=20 audio, text and video = that is=20 distributed is the one selected by = the
      floor=20 control server.
[Roy, Radhika R, ALSO]  If = real-time text is=20 used as an alternative of audio from any participant, = the selection=20 and distribution of the media should also be taken into account = appropriately=20 by the floor control server.

   o  = The=20 text from all participants is displayed in one = common area=20 in traditional IRC style.
-----------------------------------------end = of=20 = proposal-----------------------------------------------------------------= ---------------------------------------
Regards
Gunnar Hellstr=F6m

-------------------------------------------
Gunnar=20 Hellstr=F6m
Omnitor AB
Renathv=E4gen 2
SE 121 37=20 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204=20 = 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
-----------------= ---------------------------
 =20

-----Original Message-----
From: = mmusic-admin@ietf.org=20 [mailto:mmusic-admin@ietf.org]On Behalf Of Even, = Roni
Sent:=20 Sunday, November 23, 2003 9:25 AM
To: = 'vandana.yesoda@wipro.com';=20 mmusic@ietf.org
Subject: RE: [MMUSIC]=20 draft-ietf-mmusic-confarch-03.txt

Hi,
If=20 you are interested in conferencing architecture look = at
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping= -conferencing-framework-01.txt
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping= -conferencing-framework-01.txt
 
Roni

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

Roni Even

Polycom Israel

Tel: = +972-3-9251200

Cell: = +972-55-481099

email:roni.even@polycom.co.il

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

-----Original Message-----
From: = vandana.yesoda@wipro.com=20 [mailto:vandana.yesoda@wipro.com]
Sent: Wednesday, = November 19,=20 2003 11:18 AM
To: mmusic@ietf.org
Subject: = [MMUSIC]=20 draft-ietf-mmusic-confarch-03.txt

Hi,

 

I tried to get the = following=20 file from internet and using mailserv@etf.org.<= /FONT>

 

draft-ietf-mmusic-confarch-03.txt

 

Can any one send me = this=20 file?

 =20

Thanks 'n=20 Rgds

Vandana

 

=
------_=_NextPart_001_01C3B22E.8A51B228-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Nov 25 19:37:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19515 for ; Tue, 25 Nov 2003 19:37:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOndB-0004pL-DC for mmusic-archive@odin.ietf.org; Tue, 25 Nov 2003 19:34:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ0Y99c018554 for mmusic-archive@odin.ietf.org; Tue, 25 Nov 2003 19:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOndB-0004pB-9o for mmusic-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 19:34: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 TAA19434 for ; Tue, 25 Nov 2003 19:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOnd9-0003Vl-00 for mmusic-web-archive@ietf.org; Tue, 25 Nov 2003 19:34:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOnd8-0003Vf-00 for mmusic-web-archive@ietf.org; Tue, 25 Nov 2003 19:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnd3-0004oW-9R; Tue, 25 Nov 2003 19:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOncu-0004o9-7E for mmusic@optimus.ietf.org; Tue, 25 Nov 2003 19:33: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 TAA19424; Tue, 25 Nov 2003 19:33:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOncs-0003VG-00; Tue, 25 Nov 2003 19:33:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AOncr-0003US-00; Tue, 25 Nov 2003 19:33:50 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 25 Nov 2003 16:33:02 -0800 Received: from mbaugher-w2k07.cisco.com (sjc-vpn1-41.cisco.com [10.21.96.41]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAQ0XDrY019735; Tue, 25 Nov 2003 16:33:14 -0800 (PST) Message-Id: <6.0.0.22.2.20031125160613.03fd89d8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 25 Nov 2003 16:33:12 -0800 To: ono.kumiko@lab.ntt.co.jp, mary.barnes@nortelnetworks.com, tachimoto.shinya@lab.ntt.co.jp From: Mark Baugher Cc: sipping@ietf.org, mmusic@ietf.org, cyrus@ntt-at.com, fandreas@cisco.com, dwing@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] e2m, m2m security drafts 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: , hi I have read the three drafts dealing with end-to-middle and middle-to-middle security, both requirements and mechanisms. http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-00.txt http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-01.txt http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-00.txt As you may know, we developed SDP security descriptions to describe a key and security parameters for a media session. We need to have end-to-end authentication and encryption of this information and secure multiparts looks like a promising approach to our security-description needs. So, I'll have a lot of comments and questions on these drafts. In this note, I'll limit myself to one question and one comment. 1. Section 5.1 of http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-00.txt shows an example of an encrypted SDP in an INVITE but the key to this encrypted SDP is selectively shared with some proxies so they can view the encrypted data. There is undoubtedly some information in the SDP that a proxy needs to view and some that it does not need to view, such as the end-to-end keying material. Can we accommodate this requirement in the current proposals? That is, could we keep the keying material encrypted end-to-end while allowing a proxy to view other parts of the SDP message? 2. Have you considered writing a core specification like RFC 1847 and allow for one or more profiles such as S/MIME (today) and PGP MIME (in the future)? I understand that S/MIME is the designated SIP solution, but it might be wise to allow for future extensions. Thanks for doing this work. Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 26 04:46:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29806 for ; Wed, 26 Nov 2003 04:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwFS-0007Lw-A0 for mmusic-archive@odin.ietf.org; Wed, 26 Nov 2003 04:46:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ9kEru028260 for mmusic-archive@odin.ietf.org; Wed, 26 Nov 2003 04:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwFR-0007Lj-Vn for mmusic-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 04:46: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 EAA29658 for ; Wed, 26 Nov 2003 04:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwFO-0002Th-00 for mmusic-web-archive@ietf.org; Wed, 26 Nov 2003 04:46:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOwFO-0002Te-00 for mmusic-web-archive@ietf.org; Wed, 26 Nov 2003 04:46:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwFK-0007Kn-4Y; Wed, 26 Nov 2003 04:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwEI-0007JQ-Cs for mmusic@optimus.ietf.org; Wed, 26 Nov 2003 04:45: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 EAA29636; Wed, 26 Nov 2003 04:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwEF-0002Sv-00; Wed, 26 Nov 2003 04:44:59 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AOwEE-0002Ss-00; Wed, 26 Nov 2003 04:44:58 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAQ9ipUC006787; Wed, 26 Nov 2003 18:44:51 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAQ9iopo005550; Wed, 26 Nov 2003 18:44:51 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAQ9io8H018032; Wed, 26 Nov 2003 18:44:50 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA27756; Wed, 26 Nov 2003 18:44:49 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id SAA15517; Wed, 26 Nov 2003 18:44:49 +0900 (JST) Date: Wed, 26 Nov 2003 18:44:40 +0900 From: Kumiko Ono To: Mark Baugher , mary.barnes@nortelnetworks.com, tachimoto.shinya@lab.ntt.co.jp Cc: sipping@ietf.org, mmusic@ietf.org, cyrus@ntt-at.com, fandreas@cisco.com, dwing@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.07beta6 (WinNT,501) In-Reply-To: <6.0.0.22.2.20031125160613.03fd89d8@mira-sjc5-6.cisco.com> References: <6.0.0.22.2.20031125160613.03fd89d8@mira-sjc5-6.cisco.com> Message-Id: <2EC3B401E99BAEono.kumiko@lab.ntt.co.jp> Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: e2m, m2m security drafts 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 Mark, Thanks for your comments. Inline- wrote: >1. Section 5.1 of >http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security- >00.txt >shows an example of an encrypted SDP in an INVITE but the key to this >encrypted SDP is selectively shared with some proxies so they can view the >encrypted data. There is undoubtedly some information in the SDP that a >proxy needs to view and some that it does not need to view, such as the >end-to-end keying material. Can we accommodate this requirement in the >current proposals? That is, could we keep the keying material encrypted >end-to-end while allowing a proxy to view other parts of the SDP message? Yes, definitely. Section 3.1 of the requirement draft says that "The solution MUST work even with SIP end-to-end encryption for confidentiality service enabled". To clarify this requirement, I would say: - It MUST work even with end-to-end encryption of some data. That is, encrypted data can be shared with the end user and selected proxies. - It MUST NOT violate end-to-end encryption when the encrypted data does not need to be shared with any proxies. >2. Have you considered writing a core specification like RFC 1847 and allow >for one or more profiles such as S/MIME (today) and PGP MIME (in the >future)? I understand that S/MIME is the designated SIP solution, but it >might be wise to allow for future extensions. Hmm... in the future, such extensions might be needed. However, I have not considered that yet. I think there are still more work to use S/MIME practically in SIP. Thanks a lot, Kumiko -- Kumiko Ono NTT Network Service Systems Labs. Tel +81 422 59 4508/Fax +81 422 60 4012 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 26 09:19:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07612 for ; Wed, 26 Nov 2003 09:19: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 1AP0VU-0004PY-Dd for mmusic-archive@odin.ietf.org; Wed, 26 Nov 2003 09:19:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEJ4md016952 for mmusic-archive@odin.ietf.org; Wed, 26 Nov 2003 09:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0VU-0004PL-A1 for mmusic-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 09:19: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 JAA07579 for ; Wed, 26 Nov 2003 09:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0VS-000664-00 for mmusic-web-archive@ietf.org; Wed, 26 Nov 2003 09:19:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0VS-000661-00 for mmusic-web-archive@ietf.org; Wed, 26 Nov 2003 09:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0VS-0004Nu-BA; Wed, 26 Nov 2003 09:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0VF-0004N0-Rr for mmusic@optimus.ietf.org; Wed, 26 Nov 2003 09:18: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 JAA07570 for ; Wed, 26 Nov 2003 09:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0VE-00065r-00 for mmusic@ietf.org; Wed, 26 Nov 2003 09:18:48 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AP0VD-00065N-00 for mmusic@ietf.org; Wed, 26 Nov 2003 09:18:47 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAQEHRE26528 for ; Wed, 26 Nov 2003 08:17:44 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XMMDJ>; Wed, 26 Nov 2003 14:17:26 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF2B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'jo@acm.org'" , csp@csperkins.org Cc: "'mmusic@ietf.org'" Date: Wed, 26 Nov 2003 14:17:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-new-15 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: , At IETF58 requests were made for a final review of this document before resubmitting to the IESG. These comments are made as a result of that request. If mmusic participants wish to enter into discussion on any of these, you snip out the remainder of the comments so that mail threads do not become burdened with text that is not under discussion. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 Comments on draft-ietf-mmusic-sdp-new-15 ---------------------------------------- 1) Introduction: section 1. 2nd paragraph. In: When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other real-time sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. the words "or other real-time sessions" imply that SDP is limited to describing real-time sessions. SDP is proposed to be used to describe message sessions, which are immediate delivery, but which are not traditionally known as real-time. It is proposed to delete the words "real-time", leaving "or other sessions" with the word "session" being the defined term. 2) Terminology: section 2. The term "session advertisment" is never used in the document. The word "advertisment" is used in the document, but in descriptive terms that does not really justify the use of a defined term. It is suggested we delete the definition "session advertisment" from section 2. 3) Terminology. I section 2, the term "session announcement" is defined, but this term is not consistently used through the document. There are a number of places where the text within the document should be enhanced to use this term as below. However in other cases, rather than using the term "session announcement", it would appear that the other term "session description" would be more appropriate to use, see also below. a) section 3.1, title: "Multicast announcement" --> "Multicast session announcement". b) section 3.1, 2nd paragraph: One protocol commonly used to implement such a distributed directory is the Session Announcement Protocol, SAP [8]. SDP provides the recommended session description format for such announcements. should become: One protocol commonly used to implement such a distributed directory is the Session Announcement Protocol, SAP [8]. SDP provides the recommended session description format for such _session_ announcements. c) section 3.4, 2nd paragraph: SAP announcements do not suffer from this mismatch. should become: Session announcements made using SAP do not suffer from this mismatch. d) section 4.5, 1st paragraph: When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated. should become: When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter _session_ announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated. e) Section 5. 1st paragraph. Text: ...Also, since announcements may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed announcements which could be detected easily and discarded. This also allows rapid discarding of encrypted announcements for which a receiver does not have the correct key. should become: ...Also, since announcements may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed _session_ announcements which could be detected easily and discarded. This also allows rapid discarding of encrypted _session_ announcements for which a receiver does not have the correct key. f) Section 5. 6th paragraph. Text: The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore any announcement that contains a type letter that it does not understand... should become: The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore any _session description_ that contains a type letter that it does not understand... g) Section 5.2. text: is a version number for this announcement. It is needed for proxy announcements to detect which of several announcements for the same session is the most recent... should become: is a version number for this _session description_. It is needed for proxy announcements to detect which of several announcements for the same session is the most recent... Incidentally I am not sure what "proxy announcements" are, so have not proposed a revision here. This sentence could do with revision to more clearly explain what is meant. h) Section 5.4, text: The "i=" field is information about the session. There may be at most one session-level "i=" field per session description, and at most one "i=" field per media. Although it may be omitted, this is NOT RECOMMENDED for session announcements, and user interfaces for composing sessions should require text to be entered. If it is present it must contain ISO 10646 characters (but see also the "a=charset" attribute below). Assume that what is meant here is SAP rather than announcements. The text should therefore be modified to: The "i=" field is information about the session. There may be at most one session-level "i=" field per session description, and at most one "i=" field per media. Although it may be omitted, this is NOT RECOMMENDED for SAP, and user interfaces for composing sessions should require text to be entered. If it is present it must contain ISO 10646 characters (but see also the "a=charset" attribute below). However, surely if this is a SAP requirement, it should be in RFC 2974 and therefore this sentence should be deleted from this document as outside the scope. i) Section 5.7. text: A session announcement MUST contain either at least one "c=" field in each media description (see below) or a single "c=" field at the session-level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. should become: A session description MUST contain either at least one "c=" field in each media description (see below) or a single "c=" field at the session-level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. j) Section 5.10. text: Thus, the above announcement could also have been written: should become: Thus, the above _session_ announcement could also have been written: k) Section 5.11. text: If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years worth of adjustments in one announcement. should become: If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years worth of adjustments in one _session_ announcement. l) Section 5.13. text: Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of announcements in general and of attributes in particular. should become: Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular. 4) Section 4, 2nd paragraph. Current text reads: The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. A multimedia session, for these purposes, is defined as a set of media streams that exist for some duration of time. Media streams can be many-to-many. The times during which the session is active need not be continuous. We already have a definition of "multimedia" session in section 2, and this purported definition here uses different words. It is proposed to delete the duplicated definition as follows: The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. Media streams can be many-to-many. The times during which the session is active need not be continuous. 5) Section 4.6. The text: The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding [3] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalization only applies to free-text fields (session name and background information), and not to SDP as a whole. allows users of SIP to not use UTF-8. SIP (see RFC 3261) is defined to use UTF-8, but apparently does not specify how included SDP in message bodies should be encoded. It would appear to me that all SDP uses in SIP message bodies should also be encoded in UTF-8. Is this lack of specification a fault of the SIP specification, or is it appropriate to add words to sdp-new stating that: Where an application using SDP makes no further specification of the character set to be used, the ISO 10646 character sets in the UTF-8 encoding [3] MUST be used. 6) Section 5. 1st paragraph. In the text: ... However, since SDP may be used in environments where the maximum permissable size of a session description is limited (e.g. SAP announcements; SIP transported in UDP), the encoding is deliberately compact... As SIP transport using SDP is currently considered to be less than ideal, it is probably not a good idea to identify it as an example. Therefore delete the words "SIP transported in UDP". 7) Section 5.6. Phone numbers. Firstly the correct terminology is not: Phone numbers SHOULD be given in the conventional international format: preceded by a "+" and the international country code. but rather: Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164) preceded by a "+". Secondly, I do not see why this use of international number is a SHOULD. Is this to allow the provision of numbers in an entirely different numbering plan, or the use of rfc2806bis, or what. If there is some reason for only a recommendation, rather than mandatory use, then I would have expected a sentence explaining it. Thirdly, for the requirement: There must be a space or a hyphen ("-") between the country code and the rest of the phone number. I do not see a need for this requirement. It is not needed to parse the number, and it means that numbers in the specified international format for text representation, ITU-T Recommendation E.123 cannot be used without modification. I suggest that E.123 representation of international public telecommunication numbers should be valid for the phone number string. This also requires the deletion of the associated comment in the BNF in appendix A, i.e. ;there must be a space or hyphen between ;the international code and the rest of ;the number. 8) Section 5.6. E-mail addresses. Text: The alternative RFC822 name quoting convention is also allowed for both email addresses and phone numbers. For example: RFC 822 has been made obsolete by RFC 2822. Is there some reason for quoting RFC 822 rather than RFC 2822. 9) Section 5.6, text: Both email addresses and phone numbers can have an optional free text string associated with them, normally giving the name of the person who may be contacted. This should be enclosed in parenthesis if it is present. For example: e=j.doe@example.com (Jane Doe) From the BNF, the parenthesis are mandatory for the enclosure of the free text field. Therefore this should be revised to: Both email addresses and phone numbers can have an optional free text string associated with them, normally giving the name of the person who may be contacted. This MUST be enclosed in parenthesis if it is present. For example: e=j.doe@example.com (Jane Doe) 10) Section 5.7, 6th paragraph: For IP4 and IP6 addresses, the connection address is defined as follows: these are values within the field, rather than the names of IP numbering schemes, thus I proposes: Where the
is IP4 or IP6, the connection address is defined as follows: 11) Section 5.8. I am not convinced that the wording relating to X- naming is adequate. I understood this was somewhat deprecated and this could be more emphasised. Currently use of X- for anything would be conformant to this specification and I am not sure that was intended. I think we should certainly get rid of the MAY quoted below. Tool writers MAY define experimental bandwidth modifiers by prefixing their modifier with "X-". For example: Maybe this would be better rephrased as A prefix "X-" is defined for bandwidth modifier names. This is intended for experimental purposes only. For example: 12) Section 5.14 defines a number of media types. Are these already top-level MIME content types, as defined in 9.2.1, or are these to be registered by IANA as new media types? Either section 5.14 or section 9.2.1 needs enhancement to reflect what IANA are requested to do with these. 13) Section 6. This section lists a large number of attribute definitions, most of which do not appear to be defined elsewhere. Section 9.2.4 says new attributes should be registered with IANA. Are IANA expected to pick attribute registrations from clause 6, and all these are therefore intended to be registered, or not. Text needs to be added to either section 6, or section 9.2.4 giving more detail of this process. Note that if any of these attributes are defined in other documents rather than here, I would suggest an informative reference against the attribute giving the details of where it is defined. 14) Section 5.14 and section 9.2.2. In section 9.2.2, the references to "proto" field seem to be references to the "protocol" field and or a element, and or "transport protocol" defined in section 5.14. Certainly "proto" is not used as a field name anywhere else in the document ecept in the BNF. Field names should be aligned one way or the other. 15) Section 9.2.5. Does this document register the bandwidth modifiers CT and AS defined in section 5.8. If so this should be clearly stated in this section. 16) Section 9.2.6. Does this document register the network type IN as defined in section 5.2 and 5.7. If so, this should be clearly stated in this section. 17) Appendix A. Would the top level construct not be better defined as "session-description" rather than "announcement". Not all SDP data constructs are announcements. 18) Appendix A. There is considerable misalignment between the BNF field names and those in the main document. For example "v=" is "proto-version" in the BNF, and "protocol version" in the main document (section 5.1). I would suggest changing this to "protocol-version" in the BNF. "o=" is "origin-field" in the BNF and "origin" in the main document (section 5.2). I would suggest we use "Origin Field" in the title of 5.2. Section 5.2 gives the expansion of "origin" as o=
The BNF gives: origin-field = "o=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF Further unnecessary misalignment of names. In this case I would change the BNF to origin-field = "o=" username SP session-id SP session-version SP network-type SP address-type SP unicast-address CRLF with appropriate modification of dependent expansions, and the 5.2 text to o=
and so on for alignment through the rest of the BNF. 19) Appendix A. In the expansion for "proto" the following comment is added ;typically "RTP/AVP" or "udp" for IP4 This document is meant to cover IPv4 and IPv6. Why is this comment IPv4 specific, and why is TCP not mentioned as one of the typical values. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Nov 26 17:57:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01740 for ; Wed, 26 Nov 2003 17:57: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 1AP8al-0000MT-7t for mmusic-archive@odin.ietf.org; Wed, 26 Nov 2003 17:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQMv3EX001383 for mmusic-archive@odin.ietf.org; Wed, 26 Nov 2003 17:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8al-0000ME-3r for mmusic-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 17:57: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 RAA01715 for ; Wed, 26 Nov 2003 17:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP8ai-0006Ct-00 for mmusic-web-archive@ietf.org; Wed, 26 Nov 2003 17:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP8ah-0006Cq-00 for mmusic-web-archive@ietf.org; Wed, 26 Nov 2003 17:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8aj-0000LU-Fy; Wed, 26 Nov 2003 17:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8Zv-0000Kl-RC for mmusic@optimus.ietf.org; Wed, 26 Nov 2003 17:56:11 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01663 for ; Wed, 26 Nov 2003 17:55:56 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AP8Ww-0003AN-H8; Wed, 26 Nov 2003 17:53:06 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: mmusic@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Wed, 26 Nov 2003 17:53:06 -0500 Subject: [MMUSIC] Last Call: 'A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)' to Proposed Standard 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: , The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-12-10. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-05.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 27 09:53:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08293 for ; Thu, 27 Nov 2003 09:53:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNWP-0004YF-Pw for mmusic-archive@odin.ietf.org; Thu, 27 Nov 2003 09:53:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARErXhh017495 for mmusic-archive@odin.ietf.org; Thu, 27 Nov 2003 09:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNWP-0004Y6-F1 for mmusic-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 09:53: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 JAA08287 for ; Thu, 27 Nov 2003 09:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APNWN-0001G9-00 for mmusic-web-archive@ietf.org; Thu, 27 Nov 2003 09:53:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APNWN-0001G1-00 for mmusic-web-archive@ietf.org; Thu, 27 Nov 2003 09:53:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNVu-0004PG-2x; Thu, 27 Nov 2003 09:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNVI-0004OS-FN for mmusic@optimus.ietf.org; Thu, 27 Nov 2003 09:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08261 for ; Thu, 27 Nov 2003 09:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APNVG-0001Ff-00 for mmusic@ietf.org; Thu, 27 Nov 2003 09:52:22 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1APNVF-0001Fc-00 for mmusic@ietf.org; Thu, 27 Nov 2003 09:52:22 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAREqKI2021393 for ; Thu, 27 Nov 2003 15:52:20 +0100 (MET) Received: from ericsson.com (sealwp01-47.sw.ericsson.se [153.88.142.47]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW87WZH1; Thu, 27 Nov 2003 15:52:29 +0100 Message-ID: <3FC60F95.6050800@ericsson.com> Date: Thu, 27 Nov 2003 15:52:05 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Telecon 18.00 the 3rd of December with agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Next week on Wednesday (3rd of December) it is time for a RTSP telecon again. Please send a me a mail if you intend to participate. If you have comments on the agenda, please drop me a mail. Telecon details: Phone number +46 8 71 99500 Participant PIN 67700 Date 12/03/2003 (MM/DD/YYYY) Start Time 18:00 (HH:MM) (CET) Duration 90 minutes Cheers Magnus Westerlund Agenda 1. Opening of meeting and Administrative - Scribe 2. RTSP Core 2.1 Core specification bugs under developement. a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Await review from the WG. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Needs text d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - The explicit rules will be removed, possibility will be left open. Needs to be edited in. e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Needs a clarifying definition of Live - Need to check to possibility for TiVo cases. f. http://rtsp.org/bug531189 - How does REDIRECT method work - Conclusion from Minneapolis needs to be edited in: Server MAY drop the connection after it has recieved 200 OK response on a REDIRECT. g. http://rtsp.org/bug770522 - Request to response time is not limited. - Sean has written up text. - Conclusion from Minneapolis: Sean's writeup seems reasonable. Change the timelimit to 2 seconds and make sure that wording is there to indicate server should do this immediately if it know it's going to take a long time. Need motivation example. h. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - Has been removed from spec, awaiting review. i. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Awaiting review from the WG. j. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - Text sent to mailing list, we will dicuss this, please read https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg02030.html k. http://rtsp.org/bug810666 - Removal of SETUP in play state - Clarify in specification that it is unspecified. l. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes - Conclusion from Minneapolis: Should look at address classes in the SDP to figure what protocol to use (need to add SDP section of RTSP). Look at c= line syntax. Multiple c lines can be use in media field? SIP resolution was that multiple c lines should not be used to express multiple connection address. m. http://rtsp.org/bug795314 - Caching of OPTIONS request - conclusion from Minneapolis: Will be declared unspecified. n. http://rtsp.org/bug850256 - When must RTP-Info be included? o. http://rtsp.org/bug850265 - Removed features are unspecified, not forbidden p. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces. - Awaiting write up. q. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one chapter? r. http://rtsp.org/bug829528 - Usage of Grouping of media lines with RTSP. 2.2 Tracking of items not require actions currently. These items are for future processing when appropriate. A. http://rtsp.org/bug810681 - The updated specification version number - Awaiting investigation results regarding changes by Aravind. - Question of intentions. 3. RTSP Specifiction Extensions 3.1 End of Media http://rtsp.org/bug810678 - How to indicate end of media stream - We need to document in the RTSP specification regarding RTP what happens when a source times out a SSRC or receives a RTCP BYE for a source. - Using BYE is not suitable way to indicate the end of the stream. The motivation for this can be seen in Thomas proposal. - The creation of a new proposal. 3.2 RTSP and NAT issues - Requirements Priorities: 1. Server is deployed in open network. 2. Server behind firewall next. 3. If a client is not dual hosted, it should not have to deal with additional protocols. 4. Must have defense against DOS 5. Security. 6. MUST deal with symmetric nat. 7. ALG. The firewall traversal should not interfere with ALGs. 8. Advise to ALG writers not to screw it up. Review and clarify. - Protocol extension proposals What proposals do we have, and which people are sheeparding. - Update to RTSP and NAT WG draft * ALG recommendation 4. Next meeting 5. Meeting closed. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Nov 27 23:26:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01073 for ; Thu, 27 Nov 2003 23:26: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 1APaCn-0000SG-Vq for mmusic-archive@odin.ietf.org; Thu, 27 Nov 2003 23:26:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAS4Q9U2001749 for mmusic-archive@odin.ietf.org; Thu, 27 Nov 2003 23: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 1APaCn-0000S7-Qd for mmusic-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 23:26: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 XAA01061 for ; Thu, 27 Nov 2003 23:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APaCl-0002V7-00 for mmusic-web-archive@ietf.org; Thu, 27 Nov 2003 23:26:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APaCl-0002V4-00 for mmusic-web-archive@ietf.org; Thu, 27 Nov 2003 23:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APaCe-0000RQ-QI; Thu, 27 Nov 2003 23:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APaCb-0000R5-7v for mmusic@optimus.ietf.org; Thu, 27 Nov 2003 23:25: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 XAA01054 for ; Thu, 27 Nov 2003 23:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APaCZ-0002Ux-00 for mmusic@ietf.org; Thu, 27 Nov 2003 23:25:55 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1APaCY-0002Uu-00 for mmusic@ietf.org; Thu, 27 Nov 2003 23:25:54 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 27 Nov 2003 20:25:22 -0800 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Thu, 27 Nov 2003 20:25:21 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Thu, 27 Nov 2003 20:24:23 -0800 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 1APaBQ-0007NJ-00 for ; Thu, 27 Nov 2003 20:24:44 -0800 Date: Thu, 27 Nov 2003 20:23:23 -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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on capefear.real.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #108 - 4 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: , 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-850256 ] When must RTP-Info be included? (SourceForge.net) 2. [ rtspspec-Bugs-850265 ] Removed features are unspecified, not forbidden (SourceForge.net) 3. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net) 4. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 27 Nov 2003 06:06:29 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included? Bugs item #850256, was opened at 2003-11-27 15:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: When must RTP-Info be included? Initial Comment: At the RTSP discussion at IETF 58 there where some discussion in regards if RTP-Info really can be presented in all Play Responses when the media streams are RTP. The argument was Live media. The current specification (05) requires this. Are there really a reason for changing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 27 Nov 2003 06:25:59 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850265 ] Removed features are unspecified, not forbidden Bugs item #850265, was opened at 2003-11-27 15:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850265&group_id=23194 Category: Editorial Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Removed features are unspecified, not forbidden Initial Comment: In cases where feature has existed or could be defined, but the core specification does not define them, this should be clearly indicated in the text. A convention definition of unspecified can be added. Then used in the interesting places in the text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850265&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 27 Nov 2003 06:38:10 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter Bugs item #850267, was opened at 2003-11-27 15:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Gather all ABNF in syntax chapter Initial Comment: - All ABNF needs to be gathered in the syntax chapter. - Ensure that it is in 2234 form - When necessary put references into text when the ABNF gets moved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 27 Nov 2003 06:40:40 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter Bugs item #850267, was opened at 2003-11-27 15:38 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&group_id=23194 >Category: Editorial >Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Gather all ABNF in syntax chapter Initial Comment: - All ABNF needs to be gathered in the syntax chapter. - Ensure that it is in 2234 form - When necessary put references into text when the ABNF gets moved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850267&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 Sat Nov 29 00:15:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23608 for ; Sat, 29 Nov 2003 00:15: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 1APxRn-0005MT-7l for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 00:15:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAT5FBsd020606 for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 00:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APxRm-0005MH-8j for mmusic-web-archive@optimus.ietf.org; Sat, 29 Nov 2003 00:15: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 AAA23600 for ; Sat, 29 Nov 2003 00:14:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APxRj-0007OV-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 00:15:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APxRi-0007OQ-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 00:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APxRd-0005LZ-QW; Sat, 29 Nov 2003 00:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APxQx-0005LD-Rd for mmusic@optimus.ietf.org; Sat, 29 Nov 2003 00:14: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 AAA23581 for ; Sat, 29 Nov 2003 00:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APxQv-0007OH-00 for mmusic@ietf.org; Sat, 29 Nov 2003 00:14:17 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1APxQu-0007OE-00 for mmusic@ietf.org; Sat, 29 Nov 2003 00:14:16 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 28 Nov 2003 21:13:44 -0800 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, 28 Nov 2003 21:13:44 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Fri, 28 Nov 2003 21:13:31 -0800 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 1APxQU-00065k-00 for ; Fri, 28 Nov 2003 21:13:50 -0800 Date: Fri, 28 Nov 2003 21:12:53 -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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on capefear.real.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #109 - 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: , 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-850256 ] When must RTP-Info be included? (SourceForge.net) 2. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 27 Nov 2003 22:18:31 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included? Bugs item #850256, was opened at 2003-11-27 23:06 Message generated for change (Comment added) made by kjh1905m You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: When must RTP-Info be included? Initial Comment: At the RTSP discussion at IETF 58 there where some discussion in regards if RTP-Info really can be presented in all Play Responses when the media streams are RTP. The argument was Live media. The current specification (05) requires this. Are there really a reason for changing this? ---------------------------------------------------------------------- Comment By: Jaehwan, Kim (kjh1905m) Date: 2003-11-28 15:18 Message: Logged In: YES user_id=365760 IMHO, it is enough that we focus on 2 cases: 1) the beginning of the live service 2) live PAUSE/Resume because we don't believe live streaming session supports random access. 1) The beginning of the live service At this moment, there is no way for a player to see if the session is live or not. But if there is no RTP-Info, the player can start its session by the following way: When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains. 2) Live PAUSE/Resume Currently, we use monotonic rtptimestamp increament for random access. However, if a player requests PAUSE and Resume after a couple of minute, then rtptimestamp has to have the time gap. Without RTP-Info, how can the player remove the rtptimestamp gap? How can it continue the live session without any timegap? If RTSP Range header field also doesn't exist, a player can do that. From the begginning, the player should remember the first rtptimestamp and after the resume, we can just subtract the first from the lastest rtptimestamp. And then, we can calculate the real presentation time from it, comparing with the real PAUSE time gap. But this behavior of a player is different from general on- demand service having RTP-Info. Therefore, we need to chek our if the player can do that the both cases, RTP-Info and no for live. It means a general VOD player might not continue to work after live PAUSE. Feel free to give me an advise regarding this matter if I am wrong. Thank you! Jae-Hwan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 27 Nov 2003 23:59:12 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included? Bugs item #850256, was opened at 2003-11-27 15:06 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Nobody/Anonymous (nobody) Summary: When must RTP-Info be included? Initial Comment: At the RTSP discussion at IETF 58 there where some discussion in regards if RTP-Info really can be presented in all Play Responses when the media streams are RTP. The argument was Live media. The current specification (05) requires this. Are there really a reason for changing this? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-11-28 08:59 Message: Logged In: YES user_id=302620 The argument why a server could not present a RTP-Info header in a PLAY response was due to that the distribution server might not be aware of inter media synchronization of the media streams it forwards. If that is the case there exist the possibility to perform intermedia synchronization with RTCP. In regards to Jae-Whan's comments: Regarding "1) The beginning of the live service" the first comment is that there is no way of knowing that a session is live. This we have addressed through the definition that any open range in the SDP a=range attribute shall be considered Live. "When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains." I don't see how this relates to the intermedia synchronization problem. A client can't rely on that all media streams first packet will represent the same point in time and would therefore result in bad synchronization between the media. In regards to 2: In a live session if you are continuing after a couple of minutes there is no reason for removing the timestamp gap. In a live media session the media will have advanced during the paused time, therefore there does not seem to be any reason to synchronize the media prior to the pause to the one after the pause. Therefore the player should in a live case flush the buffers when it resumes play after a pause. Thus the lack of RTP-Info in this case would have no effect. As the RTP timestamp continues correctly during the paused time the intermedia synchronization established prior to pausing will still be valid I think the main problem of not always requiring RTP-Info is the intermedia synchronization. RTCP can be used, however the time until RTCP has been received for all media may be on order of seconds, thus possibly resulting in that playback has to be commeneced without synchronization. ---------------------------------------------------------------------- Comment By: Jaehwan, Kim (kjh1905m) Date: 2003-11-28 07:18 Message: Logged In: YES user_id=365760 IMHO, it is enough that we focus on 2 cases: 1) the beginning of the live service 2) live PAUSE/Resume because we don't believe live streaming session supports random access. 1) The beginning of the live service At this moment, there is no way for a player to see if the session is live or not. But if there is no RTP-Info, the player can start its session by the following way: When a player gets the first rtp packet, it should store the rtptimestamp and has to subtract it from the remains. 2) Live PAUSE/Resume Currently, we use monotonic rtptimestamp increament for random access. However, if a player requests PAUSE and Resume after a couple of minute, then rtptimestamp has to have the time gap. Without RTP-Info, how can the player remove the rtptimestamp gap? How can it continue the live session without any timegap? If RTSP Range header field also doesn't exist, a player can do that. From the begginning, the player should remember the first rtptimestamp and after the resume, we can just subtract the first from the lastest rtptimestamp. And then, we can calculate the real presentation time from it, comparing with the real PAUSE time gap. But this behavior of a player is different from general on- demand service having RTP-Info. Therefore, we need to chek our if the player can do that the both cases, RTP-Info and no for live. It means a general VOD player might not continue to work after live PAUSE. Feel free to give me an advise regarding this matter if I am wrong. Thank you! Jae-Hwan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 29 13:13:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22483 for ; Sat, 29 Nov 2003 13:13:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9ab-0003W2-EX for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 13:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATID5hU013508 for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 13:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9ab-0003Vn-9G for mmusic-web-archive@optimus.ietf.org; Sat, 29 Nov 2003 13:13: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 NAA22471 for ; Sat, 29 Nov 2003 13:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ9aZ-0000dS-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 13:13:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQ9aZ-0000dP-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 13:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9aX-0003VM-D8; Sat, 29 Nov 2003 13:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9aP-0003V8-1V for mmusic@optimus.ietf.org; Sat, 29 Nov 2003 13:12: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 NAA22464 for ; Sat, 29 Nov 2003 13:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ9aM-0000dF-00 for mmusic@ietf.org; Sat, 29 Nov 2003 13:12:50 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AQ9aM-0000cF-00 for mmusic@ietf.org; Sat, 29 Nov 2003 13:12:50 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hATIBBxA015484 for ; Sat, 29 Nov 2003 10:11:11 -0800 (PST) Received: from jamba (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 <0HP400004L6NF6@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Sat, 29 Nov 2003 10:11:11 -0800 (PST) Date: Sat, 29 Nov 2003 10:11:45 -0800 From: Geetha Srikantan To: mmusic@ietf.org Cc: Geetha.Srikantan@Sun.COM Message-id: <1070129504.10409.12.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] b= in sdp-new-15 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 A few questions and suggestions about b= lines: Section 5.8 of this draft mentions that alternative units can be used to specify the bandwidth value. Is there a mechanism to communicate the units within SDP? It would help to clarify this in the text. When using the CT modifier for RTP, is there any recommendation on whether to use peak bandwidth or average bandwidth for each session in the conference? A guideline would help. Can the AS modifier be used at the session level? From the text here it sounds like it applies to the media-level, however in previous RTSP discussions I gathered that AS can refer to session level also - I'm still a little confused about this. thanks geetha -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 29 13:16:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22555 for ; Sat, 29 Nov 2003 13:16: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 1AQ9dU-0003eh-3G for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 13:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATIG4Mr014042 for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 13:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9dT-0003eN-QK for mmusic-web-archive@optimus.ietf.org; Sat, 29 Nov 2003 13:16: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 NAA22549 for ; Sat, 29 Nov 2003 13:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ9dR-0000fZ-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 13:16:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQ9dR-0000fW-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 13:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9dS-0003c2-NN; Sat, 29 Nov 2003 13:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ9dQ-0003av-IO for mmusic@optimus.ietf.org; Sat, 29 Nov 2003 13:16: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 NAA22546 for ; Sat, 29 Nov 2003 13:15:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ9dO-0000fT-00 for mmusic@ietf.org; Sat, 29 Nov 2003 13:15:58 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AQ9dO-0000f8-00 for mmusic@ietf.org; Sat, 29 Nov 2003 13:15:58 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hATIFSxA016414 for ; Sat, 29 Nov 2003 10:15:28 -0800 (PST) Received: from jamba (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 <0HP400038LDRF6@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Sat, 29 Nov 2003 10:15:27 -0800 (PST) Date: Sat, 29 Nov 2003 10:16:01 -0800 From: Geetha Srikantan To: mmusic@ietf.org Cc: Geetha.Srikantan@Sun.COM Message-id: <1070129761.10409.18.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] a=rtpmap in sdp-new-15 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 page 24, the example shown: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 Does this mean all three payloads can appear simultaneously on the same port 49230? thanks geetha -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Nov 29 14:30:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24289 for ; Sat, 29 Nov 2003 14:30:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAn6-0006Ul-0H for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 14:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATJU3UD024961 for mmusic-archive@odin.ietf.org; Sat, 29 Nov 2003 14:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAn5-0006UW-RK for mmusic-web-archive@optimus.ietf.org; Sat, 29 Nov 2003 14:30: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 OAA24265 for ; Sat, 29 Nov 2003 14:29:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQAn3-0001dv-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 14:30:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQAn2-0001ds-00 for mmusic-web-archive@ietf.org; Sat, 29 Nov 2003 14:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAn3-0006Tp-PQ; Sat, 29 Nov 2003 14:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAmu-0006TM-1c for mmusic@optimus.ietf.org; Sat, 29 Nov 2003 14:29: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 OAA24261 for ; Sat, 29 Nov 2003 14:29:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQAmr-0001do-00 for mmusic@ietf.org; Sat, 29 Nov 2003 14:29:49 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AQAmq-0001dk-00 for mmusic@ietf.org; Sat, 29 Nov 2003 14:29:49 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61156 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AQAmL-0002q0-00; Sat, 29 Nov 2003 19:29:17 +0000 Date: Sat, 29 Nov 2003 19:29:15 +0000 From: Colin Perkins To: Geetha Srikantan Cc: mmusic@ietf.org Subject: Re: [MMUSIC] a=rtpmap in sdp-new-15 Message-Id: <20031129192915.3644b69a.csp@csperkins.org> In-Reply-To: <1070129761.10409.18.camel@jamba> References: <1070129761.10409.18.camel@jamba> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Geetha Srikantan writes: > On page 24, the example shown: > > m=audio 49230 RTP/AVP 96 97 98 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > a=rtpmap:98 L16/11025/2 > > Does this mean all three payloads can appear simultaneously on the same > port 49230? It means that all three payloads can be used in the RTP session on port 49230, switching between them as appropriate. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Nov 30 16:51:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14067 for ; Sun, 30 Nov 2003 16:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZT6-0001zi-Uj for mmusic-archive@odin.ietf.org; Sun, 30 Nov 2003 16:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAULp4CQ007660 for mmusic-archive@odin.ietf.org; Sun, 30 Nov 2003 16:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZT6-0001zT-QG for mmusic-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 16:51: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 QAA14043 for ; Sun, 30 Nov 2003 16:50:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQZT4-00062a-00 for mmusic-web-archive@ietf.org; Sun, 30 Nov 2003 16:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQZT4-00062W-00 for mmusic-web-archive@ietf.org; Sun, 30 Nov 2003 16:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZT3-0001vO-2q; Sun, 30 Nov 2003 16:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZSH-0001qn-NT for mmusic@optimus.ietf.org; Sun, 30 Nov 2003 16:50: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 QAA14013 for ; Sun, 30 Nov 2003 16:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQZSF-000629-00 for mmusic@ietf.org; Sun, 30 Nov 2003 16:50:11 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AQZSF-00061i-00 for mmusic@ietf.org; Sun, 30 Nov 2003 16:50:11 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62569 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AQZRj-0004TT-00; Sun, 30 Nov 2003 21:49:39 +0000 Date: Sun, 30 Nov 2003 21:49:38 +0000 From: Colin Perkins To: "Drage, Keith (Keith)" Cc: jo@acm.org, mmusic@ietf.org Message-Id: <20031130214938.07600758.csp@csperkins.org> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF2B@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00439EF2B@en0033exch001u.uk.lucent.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (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] Re: Comments on draft-ietf-mmusic-sdp-new-15 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 Keith, --> "Drage, Keith (Keith)" writes: > At IETF58 requests were made for a final review of this document before > resubmitting to the IESG. > > These comments are made as a result of that request. > > If mmusic participants wish to enter into discussion on any of these, you > snip out the remainder of the comments so that mail threads do not become > burdened with text that is not under discussion. Thanks, your review is greatly appreciated. I'll work on addressing these for the next version. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic