From mailnull@www1.ietf.org Thu Jan 2 04:16:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01371 for ; Thu, 2 Jan 2003 04:16:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h029PAL06605 for mmusic-archive@odin.ietf.org; Thu, 2 Jan 2003 04:25:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h029P8J06602 for ; Thu, 2 Jan 2003 04:25:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01362 for ; Thu, 2 Jan 2003 04:16:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h029OYJ06546; Thu, 2 Jan 2003 04:24:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h029NHJ06516 for ; Thu, 2 Jan 2003 04:23:17 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01343 for ; Thu, 2 Jan 2003 04:14:32 -0500 (EST) From: juha-pekka.luoma@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h029Gq025640 for ; Thu, 2 Jan 2003 11:16:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 2 Jan 2003 11:16:19 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Jan 2003 11:16:19 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Jan 2003 11:16:18 +0200 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" Subject: [MMUSIC] New I-D on IMG Unidirectional Point-to-Multipoint Transport Date: Thu, 2 Jan 2003 11:16:18 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400DAA210@trebe004.europe.nokia.com> Thread-Topic: [MMUSIC] New I-D on IMG Unidirectional Point-to-Multipoint Transport Thread-Index: AcKyP5tkKswDQR4tEdetkQCw0Bc/XA== To: X-OriginalArrivalTime: 02 Jan 2003 09:16:19.0125 (UTC) FILETIME=[9C174650:01C2B23F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h029NqJ06517 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: 8bit Content-Transfer-Encoding: 8bit Hi all, I have submitted the first version of the Internet-Draft "MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport", available via http://ietf.org/internet-drafts/draft-luoma-mmusic-img-muppet-00.txt. The idea is to borrow the best of SAP(v2) and Reliable Multicast Transport, and specify what is needed to neatly glue it all together for the transport part of IMG announcements. This contribution is based on the I-Ds draft-nomura-mmusic-pguide-requirements-00.txt and draft-nomura-mmusic-pguide-framework-00.txt announced earlier on this mailing list. The document is still incomplete, ideas are very welcome at all stages. All the best for the new year! Juha-Pekka Luoma Nokia Research Center Tampere, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jan 2 21:08:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19984 for ; Thu, 2 Jan 2003 21:08:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h032HMC09734 for mmusic-archive@odin.ietf.org; Thu, 2 Jan 2003 21:17:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032HMJ09731 for ; Thu, 2 Jan 2003 21:17:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19981 for ; Thu, 2 Jan 2003 21:08:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032DJJ09604; Thu, 2 Jan 2003 21:13:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032CKJ09568 for ; Thu, 2 Jan 2003 21:12:20 -0500 Received: from csnet1.cs.tsinghua.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19924 for ; Thu, 2 Jan 2003 21:03:15 -0500 (EST) Received: (qmail 30633 invoked by uid 0); 2 Jan 2003 17:57:35 -0000 Received: from unknown (HELO CSNET) (166.111.68.23) by csnet1.cs.tsinghua.edu.cn with SMTP; 2 Jan 2003 17:57:35 -0000 Message-ID: <001601c2b2cc$e1aeff90$02c8a8c0@CSNET> From: "yywei" To: Date: Fri, 3 Jan 2003 10:07:34 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C2B30F.EFB6C850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [MMUSIC] post maillist 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_0013_01C2B30F.EFB6C850 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 cG9zdCBtYWlsbGlzdA0K ------=_NextPart_000_0013_01C2B30F.EFB6C850 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5wb3N0IG1haWxsaXN0PC9GT05U PjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0013_01C2B30F.EFB6C850-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jan 3 08:44:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08972 for ; Fri, 3 Jan 2003 08:44:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03Drk926124 for mmusic-archive@odin.ietf.org; Fri, 3 Jan 2003 08:53:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03DrkJ26121 for ; Fri, 3 Jan 2003 08:53:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08953 for ; Fri, 3 Jan 2003 08:44:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03DrMJ26098; Fri, 3 Jan 2003 08:53:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03DqtJ26051 for ; Fri, 3 Jan 2003 08:52:55 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08922 for ; Fri, 3 Jan 2003 08:43:36 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h03Dki0O022833; Fri, 3 Jan 2003 08:46:44 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301031346.h03Dki0O022833@purple.nge.isi.edu> To: mmusic@ietf.org, Joerg Ott Subject: Re: [MMUSIC] Working group last call: draft-ietf-mmusic-sdpng-trans-02.txt In-Reply-To: Your message of "Wed, 18 Dec 2002 16:57:53 EST." <200212182157.gBILvr113300@chiron.nge.isi.edu> Date: Fri, 03 Jan 2003 08:46:44 -0500 From: Colin Perkins 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: , A reminder that this last call period ends in a week. If you have any comments on the SDPng transition draft, please send them to the list. Colin --> Colin Perkins writes: >Folks, > >This is to announce a working group last call for comments on the SDPng >Transition draft . If you have any >final comments on this draft, please send them to the mailing list by 10 >January 2003. At that time, we propose to request that this be published >as an informational RFC. > >Colin >_______________________________________________ >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 mailnull@www1.ietf.org Sun Jan 5 15:18:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10163 for ; Sun, 5 Jan 2003 15:18:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05KSah18647 for mmusic-archive@odin.ietf.org; Sun, 5 Jan 2003 15:28:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05KSaJ18644 for ; Sun, 5 Jan 2003 15:28:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10152 for ; Sun, 5 Jan 2003 15:18:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05KSCJ18623; Sun, 5 Jan 2003 15:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05KMvJ18526 for ; Sun, 5 Jan 2003 15:22:57 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10111 for ; Sun, 5 Jan 2003 15:12:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sun, 05 Jan 2003 12:14:17 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Sun, 05 Jan 2003 12:14:17 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2/8.12.2) with ESMTP id h05KF8UI020556 for ; Sun, 5 Jan 2003 12:15:08 -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 18VHAq-00039o-00 for ; Sun, 05 Jan 2003 12:15:08 -0800 Date: Sun, 05 Jan 2003 12:14:15 -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-Status: No, hits=2.0 required=5.0 tests=KNOWN_MAILING_LIST,NO_REAL_NAME,SPAM_PHRASE_02_03 version=2.42 X-Spam-Level: ** X-UIDL: ed8fe516758c7c2e2d996897ebe0d3df To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #69 - 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-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sat, 04 Jan 2003 18:01:25 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved Bugs item #662436, was opened at 2003-01-04 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194 Category: General Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Rob Lanphier (robla) Summary: RTP/AVP/TCP w/o interleaved Initial Comment: If a Transport line specifies RTP/AVP/TCP and does not also use the interleaved parameter, the transport setup details seem undocumented (maybe I'm not looking in the right place ...). I'm thinking of the level of detail the comedia I-D provides for TCP: which side accept()s and which side connect()s, how many connections to set up, framing, etc. Are there pre-existing implementations that use this transport mode? I happened to stumble onto this in writing the TCP appendix for the MWPP "implementation guidelines" ... which may spawn off a generic I-D specifying how to use comedia with RTP (framing, specifying the fmt tokens after TCP, etc). So, one option is to add RTP/AVP/TCP w/o interleaving details to that I-D, if adding it to to the RTSP I-D isn't desirable for some reason ... john lazzaro -- lazzaro@cs.berkeley.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 6 13:40:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09907 for ; Mon, 6 Jan 2003 13:40:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Iowl04909 for mmusic-archive@odin.ietf.org; Mon, 6 Jan 2003 13:50:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IowJ04906 for ; Mon, 6 Jan 2003 13:50:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09885 for ; Mon, 6 Jan 2003 13:40:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IoGJ04862; Mon, 6 Jan 2003 13:50:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06InMJ04810 for ; Mon, 6 Jan 2003 13:49:22 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09842 for ; Mon, 6 Jan 2003 13:38:29 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h06IZIP12414; Mon, 6 Jan 2003 13:35:18 -0500 Message-Id: <5.1.1.6.0.20030103094038.00b37198@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 06 Jan 2003 13:39:30 -0500 To: mmusic@ietf.org From: David Yon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] comedia-fix-00 comments Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a rather long and rambling commentary, so let me summarize the major points up front: - The scaling issue is misstated. - The security issues raised are not actually solved by comedia-fix, but can be mitigated more simply. - The proposed mechanism for session correlation has serious side-effects that are not addressed. - The connection/session lifetime decoupling is a major paradigm shift, and also has some serious side-effects. Details below, arranged by comedia-fix sections: 3.1 Port Multiplicity on Servers This section is incorrect. Even without a means to correlate incoming connections to sessions, the mapping of allocated port numbers to clients is not 1:1. I'm surprised to see this statement in the draft since I thought I had explained that in detail at earlier meetings. The size of the port space need only be as large as the NUMBER OF PENDING OFFERS made to potential clients. This is not the scaling problem described in comedia-fix (and not really a scaling problem at all, IMO), and the draft should be updated to reflect this. 3.2 No Connection Re-Use This references 3.1 and restates the incorrect scaling assumption. This scenario seems to be the only problem for which connection/session lifetime decoupling is presented as a solution. I cover this in more detail below, but the short answer is that any economy of design derived from this solution is offset by burdening other, more common scenarios with undesirable restrictions. 3.3 Security The Man-in-the-Middle attack can be mitigated by simply disallowing multiple connections to the advertised IP/port during the offer period. If more than one arrives, then the endpoint assumes an attack and does a session teardown. (yes, this requires updating the language in comedia to reflect this new scenario) The firewall trust issue can be addressed by a chain of trust, can it not? I.e., presumably the firewall authenticates/trusts a SIP proxy which in turn authenticates/trusts each of the UA's. The instruction to open/close pinholes is made by the SIP proxy to the firewall as a result of the message traffic the proxy is relaying, not by any sort of stateful packet inspection by the firewall. As for the "there's no ALG yet" argument for residential gateways: I submit yet again that without including the source address/port, comedia will preclude an ALG from ever being written. 4.1 Endpoint-ID This concerns me greatly. During the extended period when comedia was in development, I longed for just a "hook" that would allow for reliable connection correlation. But alas, since we are signaling media streams that use an open-ended set of protocols, such a hook did not exist. My working assumption was that shoe-horning additional information into an arbitrary protocol was outside the bounds of what SDP could impose. Guess I was wrong. :-) The suggestion in comedia-fix (to use a header at the start of the connection) jumbles the protocol stack, and as such may cause some unintended consequences. At the heart of the issue is "what is it that we are signaling here?". If we are signaling RTP/AVP over TCP, then we violate the spec with the initial ID transmission. If we are signaling RTP/AVP over TLS, where does the ID transmission go, as part of the TLS stream or prior to the TLS handshake? In either case we end up with a stream that is neither (a) 100% RTP/AVP and/or (b) 100% TLS. This problem can manifest itself in implementation complications as well as middlebox problems. Take TLS for example: let's say we put the endpoint ID ahead of the TLS handshake. The OpenSSL folks were kind enough to provide C developers a simple API where you prepend "ssl_" in front of the normal BSD socket calls, and for the most part you can write code for SSL/TLS in the same manner as raw TCP sockets. But with an endpoint ID, suddenly I the developer have to do a more complicated scheme where I (a) connect a TCP socket, (b) send/receive the endpoint ID, then (c) construct an SSL session based on the connected socket. This of course presumes that the language-specific API to SSL is flexible enough for the developer to juggle the order of the protocol stack in this manner. Other API's (Java, Perl, VB, etc.) may not be so forgiving. While I'm not a streaming media expert, I imagine that the situation for streaming media libraries may be worse. Then there are the considerations for a decomposed gateway topology. By multiplexing signalling information into the media stream, suddenly you force the a tight coupling between the signalling and media transport infrastructures by intermixing signalling tokens with the media stream. For middlebox problems, consider the stateful packet inspection firewall. The idea of course is to enforce a policy by protocol rather than by connectivity. So SMTP, HTTP, FTP, and DNS are allowed, but nothing else, and it doesn't matter what ports or addresses are used. In theory the sysadmin should also be able to specify SIP, TLS, RTP/AVP, and IM protocols in this list and allow those forward-looking end-users to utilize this fancy new SIP stuff. With comedia-fix, every protocol that is signaled will not, in fact, *be* the protocol described in the SDP. So when the firewall watches the media stream, it doesn't see a stream that fits any of the protocol structures it recognizes, and therefore disallows the stream. Another case is where TLS is provided by an external accelerator box to offload the compute load of the server---same issue. 4.2 Decoupled lifetimes This has a number of side-effects. First, it essentially forces a single-port architecture on both of the endpoints, as the only other option is the "this-doesn't-scale" 1:1 client-to-port-number mapping. With comedia as it stands today, the lifetime of the listener port is decoupled from the lifetime of the session that is begat from that listener. No longer the case with comedia-fix. Second, it forces endpoints to use "both" where one could have opted for just "active" or "passive". The problem here is that if one endpoint specified "passive", and the media connection drops, it has no way to legally reinstate the connection if it needs to send data to the other endpoint. In essence, comedia-fix "raises the stakes" as to what is an appropriate connection mode to negotiate. In comedia, the only thing at stake was the ability to bring up the intial connection. In comedia-fix, we add the issue of recovering from the scenario that the remote endpoint will drop the connection. Third, as described in comedia-fix, NAT's can cause a similar outage to #2 even if each endpoint specifies "both". The decoupled lifetime, to my knowledge, is unprecedented. In developing comedia I tried to apply the litmus test of "how is this scenario handled in connectionless media, and how do connections differ?". I don't believe that decoupled lifetimes fares very well here. Remember that while "traditional" SDP media transports may be connectionless, they aren't stateless. So the corollary to decoupling connection lifetime from session lifetime is akin to allowing RTP/AVP streams to be stopped, reset, then restarted, all without any additional activity on the signalling channel. Again, I'm not an expert here, but I imagine that this would be considered outside the spec today. I also don't understand the rationale behind the statement: "If one side wishes to force the other to reconnect, it merely drops the connection. When the other side has data to send, it will establish a new connection." The "reconnect" attribute was never intended to "force" reconnects. Rather, it was intended as a way to recover from an *unintended* disconnection in such as a way as to preserve the existing session state. Is there ever a reason that an endpoint would tear down the connection solely to inconvenience the other endpoint with the task of re-establishing it? (insert half-smiley here, since that's the impression one gets from the language in comedia-fix) I guess I'm having trouble understanding why it is so important that the lifetime be decoupled. The only argument put forth is the multiplexing-bridge scenario. If we really are using a multiplexed tunnel to bridge two networks, what's the harm in making the tunneling connection "sticky"? On the flip side, since there is a multiplexing function occurring in an intermediary, shouldn't there be a mechanism for determining the lifetime of the feeds into the mux that just makes this problem go away? How today, do the endpoints in this scenario know when to do an initial INVITE, then do the final BYE? Or, a more blunt way of saying this: "Why is this comedia's problem?" This strikes me as a lot of bending-over-backwards to accommodate a network transport architecture that should be transparent to the signaling protocol used by the endpoints. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 6 20:45:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21174 for ; Mon, 6 Jan 2003 20:45:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h071uH100568 for mmusic-archive@odin.ietf.org; Mon, 6 Jan 2003 20:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h071uHJ00565 for ; Mon, 6 Jan 2003 20:56:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20193 for ; Mon, 6 Jan 2003 19:39:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070oAJ29235; Mon, 6 Jan 2003 19:50:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070liJ29145 for ; Mon, 6 Jan 2003 19:47:44 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20164 for ; Mon, 6 Jan 2003 19:36:45 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h070easw015970; Mon, 6 Jan 2003 19:40:37 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX42906; Mon, 6 Jan 2003 19:44:56 -0500 (EST) Message-ID: <3E1A21DA.4070005@cisco.com> Date: Mon, 06 Jan 2003 19:39:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: mmusic@ietf.org Subject: Re: [MMUSIC] comedia-fix-00 comments References: <5.1.1.6.0.20030103094038.00b37198@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Haven't seen you post for a long time. I thought maybe you had dropped off the face of the earth. I guess not. :-) I've been discussing this with Jonathan and Ben. We will no doubt be back to you before long with specific responses. Meanwhile I want to clarify one thing: David Yon wrote: > > During the extended period when comedia was > in development, I longed for just a "hook" that would allow for reliable > connection correlation. But alas, since we are signaling media streams > that use an open-ended set of protocols, such a hook did not exist. My > working assumption was that shoe-horning additional information into an > arbitrary protocol was outside the bounds of what SDP could impose. > Guess I was wrong. :-) Back when I first got involved with comedia I shared the same desire for the "hook". Since I came in in the middle of the development, I took it as a requirement that "shoe-horning additional information into an arbitrary protocol was outside the bounds of what SDP could impose." Accepting that limitation led to the existing comedia. However, for the curent exercise, we started with the requirements for simple, with a protocol that is being designed concurrently. That gives us more flexibility. Then, starting with comedia, we tried to generalize, but relaxing the restrictions to fit the needs of simple. With relaxed restrictions that "hook" can be available, so other solutions are possible. Of course, relaxing the restrictions potentially invalidates potential uses of comedia as it was. We have discussed various ways of dealing with this: - make the "fixed" comedia be a new draft that coexists with the "old" comedia - modify the "old" comedia draft so that it specifies two alternative ways of working - one compatible with the old restrictions, one with the new restrictions - simply modify comedia to support the new assumptions, accepting the invalidation of some formerly valid cases None of us knew whether there are any existing applications of comedia, so we couldn't assess the impact of invalidating them. We decided to simply float the proposal and see what kind of responses we got. Based on that we could decide which path to take. You have provided us with at least one data point - that somebody cares about the "old" version. Do you know of current applications of it? Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jan 7 08:30:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12294 for ; Tue, 7 Jan 2003 08:30:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07DesW20151 for mmusic-archive@odin.ietf.org; Tue, 7 Jan 2003 08:40:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DerJ20148 for ; Tue, 7 Jan 2003 08:40:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12176 for ; Tue, 7 Jan 2003 08:29:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DeWJ20134; Tue, 7 Jan 2003 08:40:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DdxJ20058 for ; Tue, 7 Jan 2003 08:39:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11981; Tue, 7 Jan 2003 08:28:43 -0500 (EST) Message-Id: <200301071328.IAA11981@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Jan 2003 08:28:43 -0500 Subject: [MMUSIC] I-D ACTION:draft-rosenberg-mmusic-comedia-fix-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Changes to Connection Oriented Media Handling in the Session Description Protocol (SDP) Author(s) : J. Rosenberg Filename : draft-rosenberg-mmusic-comedia-fix-00.txt Pages : 19 Date : 2003-1-6 This document describes changes that are proposed to draft-ietf-mmusic-sdp-comedia-04, which describes the handling of connection oriented media in the Session Description Protocol (SDP). These changes are motivated by problems encountered in using comedia to support instant messaging sessions in the SIMPLE working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-mmusic-comedia-fix-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-mmusic-comedia-fix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145253.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jan 7 09:22:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14691 for ; Tue, 7 Jan 2003 09:22:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07EWjs23468 for mmusic-archive@odin.ietf.org; Tue, 7 Jan 2003 09:32:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07EWiJ23465 for ; Tue, 7 Jan 2003 09:32:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14657 for ; Tue, 7 Jan 2003 09:18:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ETKJ23234; Tue, 7 Jan 2003 09:29:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ESeJ23167 for ; Tue, 7 Jan 2003 09:28:40 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14643 for ; Tue, 7 Jan 2003 09:17:25 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h07EE0P31390; Tue, 7 Jan 2003 09:14:00 -0500 Message-Id: <5.1.1.6.0.20030107083654.03447098@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 07 Jan 2003 09:02:43 -0500 To: Paul Kyzivat From: David Yon Subject: Re: [MMUSIC] comedia-fix-00 comments Cc: mmusic@ietf.org In-Reply-To: <3E1A21DA.4070005@cisco.com> References: <5.1.1.6.0.20030103094038.00b37198@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 07:39 PM 1/6/2003, Paul Kyzivat wrote: >David, > >Haven't seen you post for a long time. I thought maybe you had dropped off >the face of the earth. I guess not. :-) My primary interest in MMUSIC was comedia, and since it looked like it was on track to RFC-land, I've been laying low. Silly me. :-) >Back when I first got involved with comedia I shared the same desire for >the "hook". Since I came in in the middle of the development, I took it as >a requirement that "shoe-horning additional information into an arbitrary >protocol was outside the bounds of what SDP could impose." > >Accepting that limitation led to the existing comedia. > >However, for the curent exercise, we started with the requirements for >simple, with a protocol that is being designed concurrently. That gives us >more flexibility. Then, starting with comedia, we tried to generalize, but >relaxing the restrictions to fit the needs of simple. With relaxed >restrictions that "hook" can be available, so other solutions are possible. One thing that occurs to me---especially if you are dealing with a new protocol---is perhaps to make the hook generic in terms of the SDP but specific to each media type. I.e., many existing protocols have something in their initial handshake that can be used to uniquely identify the stream. Our protocol at Dialout.Net has such a thing, presumably SIMPLE has or could add one, and I thought there was discussion very early in comedia's development that RTP has a candidate (SSID?). This would be much less intrusive than comedia-fix's proposal (which is my big beef with endpoint-ID), yet would accommodate session correlation at least for those protocols that have suitable comedia hooks. Here's a strawman: - The hook is optional, to account for protocols that do not have an existing hook, or if their hook has not been standardized. - The syntax would be similar to the endpoint-ID proposal (but maybe named "media ID" or something that ties it to the media). - The hook must be simple, preferably a 32-bit integer, or at most definable as integer or short ASCII string. - The hook is defined on a per-protocol basis. The ones we can think of today we put into comedia, later ones get defined in a one-page RFC. This still tightly couples signalling with media more than I would like (see my decomposed gateway argument), but I could live with it. >Of course, relaxing the restrictions potentially invalidates potential >uses of comedia as it was. We have discussed various ways of dealing with this: >- make the "fixed" comedia be a new draft that coexists with the "old" comedia > >- modify the "old" comedia draft so that it specifies two alternative ways >of working - one compatible with the old restrictions, one with the new >restrictions > >- simply modify comedia to support the new assumptions, accepting the >invalidation of some formerly valid cases I think it depends on where we end up with this. If the changes end up being less radical than what's in comedia-fix, then I think another spin of comedia makes sense. >None of us knew whether there are any existing applications of comedia, so >we couldn't assess the impact of invalidating them. We decided to simply >float the proposal and see what kind of responses we got. Based on that we >could decide which path to take. > >You have provided us with at least one data point - that somebody cares >about the "old" version. Do you know of current applications of it? We are not widely deployed enough to care about backward compatibility yet, but I have gotten several emails over the past year from folks asking me questions about comedia. So from my perspective changing comedia is not a problem in principle, but I do have some strong opinions about the side-effects of any changes---as you saw in the last email. :-) Again, let's see where we end up. If the changes aren't too radical then we'll just respin. I may be out of sync, but I believe most folks understand that implementations based on working drafts can be rendered obsolete. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jan 7 10:25:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14689 for ; Tue, 7 Jan 2003 09:22:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07EWiq23453 for mmusic-archive@odin.ietf.org; Tue, 7 Jan 2003 09:32:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07EWiJ23450 for ; Tue, 7 Jan 2003 09:32:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14655 for ; Tue, 7 Jan 2003 09:18:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ETAJ23198; Tue, 7 Jan 2003 09:29:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ESWJ23159 for ; Tue, 7 Jan 2003 09:28:32 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14638 for ; Tue, 7 Jan 2003 09:17:17 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h07EE1P31393; Tue, 7 Jan 2003 09:14:02 -0500 Message-Id: <5.1.1.6.0.20030107090246.03445d08@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 07 Jan 2003 09:20:00 -0500 To: mmusic@ietf.org From: David Yon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] comedia-fix and the whole source address/port boondoggle 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: , comedia-fix again raises the argument against embedding the source address/port information in the SDP. That is something that I still feel strongly about, and work has progressed that makes use of it, although not as a fail-safe session correlation mechanism. We've found that it's useful as a DoS counter-measure, using the following design: - An intermediate proxy on our network acts as a STUN-like inverse-NAT translator to at least recover the likely address from where the media will originate, and rewrites the SDP if necessary. - Our gateways, when under load, sort the incoming connection pending queue based on source addresses that they expect to arrive. The idea is that when under DoS attack, connections sourced from uninvited addresses are not dealt with until the queue of invited addresses has been serviced. This is especially critical when the media is carried over TLS, and in our case we do not commence with the TLS handshake until either the connection has been correlated or until servicing the connection does not overload the gateway. The side-effect of a failed/incorrect inverse-NAT rewrite only occurs under heavy load, and is not fatal. But without the source address information, there is no way to implement such a scheme. I believe that comedia adequately spells out the limitations imposed by various topologies (i.e., NAT), and the source address/port is still worth keeping. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jan 7 15:19:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27174 for ; Tue, 7 Jan 2003 15:19:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07KUZ915693 for mmusic-archive@odin.ietf.org; Tue, 7 Jan 2003 15:30:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KUZJ15690 for ; Tue, 7 Jan 2003 15:30:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27144 for ; Tue, 7 Jan 2003 15:19:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KULJ15670; Tue, 7 Jan 2003 15:30:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KSmJ15583 for ; Tue, 7 Jan 2003 15:28:48 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27104 for ; Tue, 7 Jan 2003 15:17:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 07 Jan 2003 12:19:15 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Tue, 07 Jan 2003 12:19:15 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2/8.12.2) with ESMTP id h07KIFUI023872 for ; Tue, 7 Jan 2003 12:18:15 -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 18W0Az-0006V0-00 for ; Tue, 07 Jan 2003 12:18:17 -0800 Date: Tue, 07 Jan 2003 12:17:28 -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-Status: No, hits=2.0 required=5.0 tests=KNOWN_MAILING_LIST,NO_REAL_NAME,SPAM_PHRASE_02_03 version=2.42 X-Spam-Level: ** X-UIDL: caaaf897629daf7b47a5f2002b406e91 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #70 - 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-663715 ] Requirement levels for Transport:SSRC needs clarification (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 07 Jan 2003 06:31:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification Bugs item #663715, was opened at 2003-01-07 15:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=663715&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Requirement levels for Transport:SSRC needs clarification Initial Comment: The SSRC parameter in the transport header has a few unclarities. - Why should a client be allowed to propose a SSRC to the server? - If allowed as current text indicates, what is the requirement level on the server to follow the proposed value. MAY or SHOULD. First I would like to know the motivation a client has to suggest a SSRC. This can probably not be removed but unless there is good reasons for it I think the requirement on a server to follow the request is MAY. With a good motivation the level is SHOULD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=663715&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 8 17:59:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11862 for ; Wed, 8 Jan 2003 17:59:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08NAgh30520 for mmusic-archive@odin.ietf.org; Wed, 8 Jan 2003 18:10:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NAfJ30517 for ; Wed, 8 Jan 2003 18:10:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11832 for ; Wed, 8 Jan 2003 17:58:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NAQJ30488; Wed, 8 Jan 2003 18:10:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N9rJ30444 for ; Wed, 8 Jan 2003 18:09:53 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11769 for ; Wed, 8 Jan 2003 17:57:58 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18WPCE-0002aU-00 for ; Wed, 08 Jan 2003 15:01:14 -0800 Date: Wed, 8 Jan 2003 15:01:14 -0800 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030108230114.GA9521@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [MMUSIC] RTSP draft changes from telecon 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: , --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I volunteered to make some changes to draft-02 during the last telecon (see http://www.rtsp.org/2002/telecon/minutes11Dec.html). It's been a while and my memory is a bit fuzzy, so please verify the following is correct (especially Rob and Magnus): 1. Fill in section 11.3.5 (304 response). Reference section 12.23 and 12.9. 2. Modify 10.10 (REDIRECT) to clarify the following behavior: If a REDIRECT contains a Session: header, it is end-to-end and applies to the given session only. If a REDIRECT does not contain a Session: header, it is single-hop (eg.= =20 handled by the proxy, if applicable) and applies to the control (tcp) connection. --=20 I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, "Dijkstra would not have liked this", well that would be enough immortality for me. --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+HK26qznSmcYu2m8RAkIHAJ9uqDZKaXpT4oPbslOJ+bdPviGMCwCeJ8T1 RYo7C6oz/fPLDwkJdp+UXpc= =tUaL -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jan 9 03:33:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03746 for ; Thu, 9 Jan 2003 03:33:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h098ijR05534 for mmusic-archive@odin.ietf.org; Thu, 9 Jan 2003 03:44:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098iiJ05531 for ; Thu, 9 Jan 2003 03:44:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03735 for ; Thu, 9 Jan 2003 03:32:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098iBJ05483; Thu, 9 Jan 2003 03:44:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098hgJ05453 for ; Thu, 9 Jan 2003 03:43:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03708 for ; Thu, 9 Jan 2003 03:31:34 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h098YoAv019061; Thu, 9 Jan 2003 09:34:51 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNLQLGJ; Thu, 9 Jan 2003 09:34:50 +0100 Message-ID: <3E1D342A.2030808@era.ericsson.se> Date: Thu, 09 Jan 2003 09:34:50 +0100 X-Sybari-Trust: d4e2c81f 1864f774 d5511081 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon References: <20030108230114.GA9521@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, Seems correct to my memory. Tom Marshall wrote: >I volunteered to make some changes to draft-02 during the last telecon >(see >http://www.rtsp.org/2002/telecon/minutes11Dec.html). It's been a while >and >my memory is a bit fuzzy, so please verify the following is correct >(especially Rob and Magnus): > >1. Fill in section 11.3.5 (304 response). Reference section 12.23 and >12.9. > >2. Modify 10.10 (REDIRECT) to clarify the following behavior: > > If a REDIRECT contains a Session: header, it is end-to-end and applies > to the given session only. > > If a REDIRECT does not contain a Session: header, it is single-hop >(eg. > handled by the proxy, if applicable) and applies to the control (tcp) > connection. > > > The last sentence about a REDIRECT's applicability to the control connection I can't remember discussing. However I do agree with you that it is a logical step to move the control connection. If a server is totally shutting down it will anyway need to close the TCP connections, so having at least SHOULD requirement on closing the connection seems fine by me. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jan 9 15:25:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25297 for ; Thu, 9 Jan 2003 15:25:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09KbXC23697 for mmusic-archive@odin.ietf.org; Thu, 9 Jan 2003 15:37:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KbXJ23694 for ; Thu, 9 Jan 2003 15:37:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25283 for ; Thu, 9 Jan 2003 15:25:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KagJ23019; Thu, 9 Jan 2003 15:36:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KZkJ22982 for ; Thu, 9 Jan 2003 15:35:46 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25260 for ; Thu, 9 Jan 2003 15:23:23 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18WjGA-0003vA-00; Thu, 09 Jan 2003 12:26:38 -0800 Date: Thu, 9 Jan 2003 12:26:38 -0800 From: Tom Marshall To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon Message-ID: <20030109202638.GD14191@real.com> References: <20030108230114.GA9521@real.com> <3E1D342A.2030808@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kvUQC+jR9YzypDnK" Content-Disposition: inline In-Reply-To: <3E1D342A.2030808@era.ericsson.se> User-Agent: Mutt/1.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: , --kvUQC+jR9YzypDnK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >1. Fill in section 11.3.5 (304 response). Reference section 12.23 and > >12.9. I started writing this section and came across some issues: 1. When 304 is sent in response to a DESCRIBE, what exactly is meant by "not modified"? Does this response guarantee that the resource is not modified, or merely that the description of the resource is not modified? Here are two examples: (1) a newer copy of a resource has been placed on the server, but the resource description for the updated copy is identical, and (2) a live resource. In both cases, the resource description may be identical to the previously returned copy, but the resource contents will not. Is 304 appropriate? 2. Same issue with SETUP, but in reverse. Does 304 necessarily imply that the resource description is identical? 3. The RTSP state machine mandates that a 3xx response to a request changes the state to Init. This is fairly logical for the other 3xx codes, as they are used for redirection. Should 304 also follow this rule? Suppose that a client has a Session and is PLAYing a resource. The client then issues a DESCRIBE on that same resource, specifying the existing Session and an If-Modified-Since header. The server returns a 304 response. What happens to the Session? Should it be considered torn down? Should the server stop sending data packets? Further, suppose that the same scenario as (3) above plays out but the server returns 302 instead. What happens to the session, and should the server stop sending data packets? > >2. Modify 10.10 (REDIRECT) to clarify the following behavior: > > > > If a REDIRECT contains a Session: header, it is end-to-end and applies > > to the given session only. > > > > If a REDIRECT does not contain a Session: header, it is single-hop > >(eg.=20 > > handled by the proxy, if applicable) and applies to the control (tcp) > > connection. > > > The last sentence about a REDIRECT's applicability to the control=20 > connection I can't remember discussing. However I do agree with you that= =20 > it is a logical step to move the control connection. If a server is=20 > totally shutting down it will anyway need to close the TCP connections,= =20 > so having at least SHOULD requirement on closing the connection seems=20 > fine by me. I thought we had agreed on these semantics toward the end of the telecon.= =20 It seems that, in any case, we are in agreement. If there are any objections to the above semantics, please make them known asap. --=20 I used to think I was a child; now I think I am an adult -- not because I no longer do childish things, but because those I call adults are no more mature than I am. --kvUQC+jR9YzypDnK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Hdr+qznSmcYu2m8RAmOkAJ9SLiTSBrnqxdP3cKzPW8QKjIM/ugCbB7hk d5FxyBAY18+1jFE9TFEp5Xk= =dZp1 -----END PGP SIGNATURE----- --kvUQC+jR9YzypDnK-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 13 03:24:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04157 for ; Mon, 13 Jan 2003 03:24:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D8bgs04193 for mmusic-archive@odin.ietf.org; Mon, 13 Jan 2003 03:37:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8bgJ04190 for ; Mon, 13 Jan 2003 03:37:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04151 for ; Mon, 13 Jan 2003 03:23:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8bRJ04011; Mon, 13 Jan 2003 03:37:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8Z8J03472 for ; Mon, 13 Jan 2003 03:35:08 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04123 for ; Mon, 13 Jan 2003 03:21:05 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0D8OMKV002382; Mon, 13 Jan 2003 09:24:23 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNC3ZS3; Mon, 13 Jan 2003 09:24:22 +0100 Message-ID: <3E2277B6.4070802@era.ericsson.se> Date: Mon, 13 Jan 2003 09:24:22 +0100 X-Sybari-Trust: 67e5031e 1864f774 db1b383b 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon References: <20030109202638.GD14191@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, Some comments Tom Marshall wrote: >>>1. Fill in section 11.3.5 (304 response). Reference section 12.23 >>> >>> >and > > >>>12.9. >>> >>> > >I started writing this section and came across some issues: > >1. When 304 is sent in response to a DESCRIBE, what exactly is meant by >"not >modified"? Does this response guarantee that the resource is not >modified, >or merely that the description of the resource is not modified? Here >are >two examples: (1) a newer copy of a resource has been placed on the >server, >but the resource description for the updated copy is identical, and (2) >a >live resource. In both cases, the resource description may be identical >to >the previously returned copy, but the resource contents will not. Is >304 >appropriate? > In my opinion the 304 answer to a DESCRIBE request must be related to if the session description is changed. The session content that the session description relates to is not part of the question. If the media content changes it should be published as a new resources with an new URI. > >2. Same issue with SETUP, but in reverse. Does 304 necessarily imply >that >the resource description is identical? > > What is your suggestion for the semantics of receiving a 304 to a SETUP request? I have earlier asked what happens when one do SETUP to change parameters and it does not work correctly, see bug 513737: https://sourceforge.net/tracker/?group_id=23194&atid=377744&func=detail&aid=513737 >3. The RTSP state machine mandates that a 3xx response to a request >changes >the state to Init. This is fairly logical for the other 3xx codes, as >they >are used for redirection. Should 304 also follow this rule? Suppose >that a >client has a Session and is PLAYing a resource. The client then issues >a >DESCRIBE on that same resource, specifying the existing Session and an >If-Modified-Since header. The server returns a 304 response. What >happens >to the Session? Should it be considered torn down? Should the server >stop >sending data packets? > > I think 304 needs to be excluded from this behavior. Is it not in fact that a 304 response is the result of that the session state has not been changed? >Further, suppose that the same scenario as (3) above plays out but the >server returns 302 instead. What happens to the session, and should the >server stop sending data packets? > > The scenario you think of is a DESCRIBE request with session header relating to a active session. That DESCRIBE request results in a 302 response. However as DESCRIBE does not effect the session state (see table 6). Also currently session header is not applicable for DESCRIBE requests (See table 4). > > >>>2. Modify 10.10 (REDIRECT) to clarify the following behavior: >>> >>>If a REDIRECT contains a Session: header, it is end-to-end and >>> >>> >applies > > >>>to the given session only. >>> >>>If a REDIRECT does not contain a Session: header, it is single-hop >>>(eg. >>>handled by the proxy, if applicable) and applies to the control >>> >>> >(tcp) > > >>>connection. >>> >>> >>> >>The last sentence about a REDIRECT's applicability to the control >>connection I can't remember discussing. However I do agree with you >> >> >that > > >>it is a logical step to move the control connection. If a server is >>totally shutting down it will anyway need to close the TCP >> >> >connections, > > >>so having at least SHOULD requirement on closing the connection seems >>fine by me. >> >> > >I thought we had agreed on these semantics toward the end of the >telecon. >It seems that, in any case, we are in agreement. If there are any >objections to the above semantics, please make them known asap. > > > Yes, I think you are correct, just had some problem remembering that. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 13 05:03:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06509 for ; Mon, 13 Jan 2003 05:03:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DAGe611934 for mmusic-archive@odin.ietf.org; Mon, 13 Jan 2003 05:16:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DAGeJ11931 for ; Mon, 13 Jan 2003 05:16:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06498 for ; Mon, 13 Jan 2003 05:02:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DAGXJ11919; Mon, 13 Jan 2003 05:16:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DAFSJ11883 for ; Mon, 13 Jan 2003 05:15:28 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06488 for ; Mon, 13 Jan 2003 05:01:22 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0DA4fAv027923 for ; Mon, 13 Jan 2003 11:04:41 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1G2P2D; Mon, 13 Jan 2003 11:04:41 +0100 Message-ID: <3E228F39.3060808@era.ericsson.se> Date: Mon, 13 Jan 2003 11:04:41 +0100 X-Sybari-Trust: bca5348b 1864f774 db1b383b 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP telecon 22 of january - 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 In a little more than a week it is time for the next RTSP telecon. All participants in last meeting will automatically receive conference details in a few days. Others who wants to participate please send a request to me. --------------------------------- Agenda 22nd of January 2003 18.00-19.30 CET (GMT+1) - Follow up on last telecon * 304 and REDIRECT "*" text proposal. - Extension mechanism Read the parts in the draft that describes the different parts of the mechanism. For discussion: the whole solution * Feature tags - play.basic - registration * Require header * Proxy-require header - Shall it really require server to support these? See SIP, RFC 3261 which uses Proxy-Require only for proxies. * Supported header - As in SIP? - Which methods, see table 4 & 5? * Unsupported header - Options * Use of "Supported" header. * "*" URL and proxies - Editorship of the draft - In case we have time: * Use of destination parameter in Transport header: http://rtsp.org/bug507347 * RTSP and NATs What solutions exist to make RTSP traverse NATs without ALG. http://rtsp.org/bug513888 - STUN? See - ALG recommendations? - Next meeting --------------------------------- Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 13 07:56:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10018 for ; Mon, 13 Jan 2003 07:56:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DD9fL22907 for mmusic-archive@odin.ietf.org; Mon, 13 Jan 2003 08:09:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD9eJ22904 for ; Mon, 13 Jan 2003 08:09:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09989 for ; Mon, 13 Jan 2003 07:55:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD92J22870; Mon, 13 Jan 2003 08:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD4jJ22056 for ; Mon, 13 Jan 2003 08:04:45 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09848 for ; Mon, 13 Jan 2003 07:50:34 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id B7F6F8F528; Mon, 13 Jan 2003 13:53:48 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA24686; Mon, 13 Jan 2003 13:53:47 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA23343; Mon, 13 Jan 2003 13:53:45 +0100 (MET) Subject: Re: [MMUSIC] RTSP through NATs To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 13 Jan 2003 13:48:08 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/01/2003 13:54:46 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: , Magnus, I will not be able to follow this teleconference, however here is some input on RTSP & NATs we have implemented STUN as a way to make RTSP with RTP/UDP transport work through NATS. It works really fine (with a minor problem for long pauses). Actually when comparing with ALGs I would rather strongly advocate for STUN, to the point of discouraging ALG usage (as a cure for NAT) to make a long story short it scales much better and does not require *any* control on the NATs (vs install/run ALG). regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: IETF MMUSIC WG cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: [MMUSIC] RTSP telecon 22 of january - Agenda Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 13/01/2003 11:04 Hi In a little more than a week it is time for the next RTSP telecon. All participants in last meeting will automatically receive conference details in a few days. Others who wants to participate please send a request to me. --------------------------------- Agenda 22nd of January 2003 18.00-19.30 CET (GMT+1) - Follow up on last telecon * 304 and REDIRECT "*" text proposal. - Extension mechanism Read the parts in the draft that describes the different parts of the mechanism. For discussion: the whole solution * Feature tags - play.basic - registration * Require header * Proxy-require header - Shall it really require server to support these? See SIP, RFC 3261 which uses Proxy-Require only for proxies. * Supported header - As in SIP? - Which methods, see table 4 & 5? * Unsupported header - Options * Use of "Supported" header. * "*" URL and proxies - Editorship of the draft - In case we have time: * Use of destination parameter in Transport header: http://rtsp.org/bug507347 * RTSP and NATs What solutions exist to make RTSP traverse NATs without ALG. http://rtsp.org/bug513888 - STUN? See - ALG recommendations? - Next meeting --------------------------------- Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ 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 mailnull@www1.ietf.org Mon Jan 13 13:51:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19728 for ; Mon, 13 Jan 2003 13:51:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJ5fk13999 for mmusic-archive@odin.ietf.org; Mon, 13 Jan 2003 14:05:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ5fJ13996 for ; Mon, 13 Jan 2003 14:05:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19716 for ; Mon, 13 Jan 2003 13:51:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ5OJ13983; Mon, 13 Jan 2003 14:05:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ4UJ13935 for ; Mon, 13 Jan 2003 14:04:30 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19687 for ; Mon, 13 Jan 2003 13:50:13 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18Y9iE-0007zW-00; Mon, 13 Jan 2003 10:53:30 -0800 Date: Mon, 13 Jan 2003 10:53:30 -0800 From: Tom Marshall To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon Message-ID: <20030113185330.GB30293@real.com> References: <20030109202638.GD14191@real.com> <3E2277B6.4070802@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <3E2277B6.4070802@era.ericsson.se> User-Agent: Mutt/1.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: , --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >1. When 304 is sent in response to a DESCRIBE, what exactly is meant by > >"not modified"? >=20 > In my opinion the 304 answer to a DESCRIBE request must be related to if= =20 > the session description is changed. The session content that the session= =20 > description relates to is not part of the question. Okay, that sounds logical to me. > If the media content changes it should be published as a new resources > with an new URI. I agree that it is desirable to have a new URI for a changed resource, but I don't think it should not be a MUST. I don't think the spec should dictate content policy to this degree. > >2. Same issue with SETUP, but in reverse. Does 304 necessarily imply > >that the resource description is identical? >=20 > What is your suggestion for the semantics of receiving a 304 to a SETUP= =20 > request? I have earlier asked what happens when one do SETUP to change=20 > parameters and it does not work correctly, see bug 513737: > https://sourceforge.net/tracker/?group_id=3D23194&atid=3D377744&func=3Dde= tail&aid=3D513737 The answer to my question is implied: a 304 response to a SETUP does not guarantee that the resource description is unchanged. Correct? I admit that I have not thought about the issue in 513737 before. It seems to come from overloading the semantics of SETUP. > >3. The RTSP state machine mandates that a 3xx response to a request > >changes > >the state to Init. This is fairly logical for the other 3xx codes, as > >they > >are used for redirection. Should 304 also follow this rule? Suppose > >that a > >client has a Session and is PLAYing a resource. The client then issues > >a > >DESCRIBE on that same resource, specifying the existing Session and an > >If-Modified-Since header. The server returns a 304 response. What > >happens > >to the Session? Should it be considered torn down? Should the server > >stop > >sending data packets? > >=20 > > > I think 304 needs to be excluded from this behavior. Is it not in fact=20 > that a 304 response is the result of that the session state has not been= =20 > changed? Yes, it would be logical to exclude 304 from the state change in this case.= =20 But wouldn't this break compatibility with 2326? Are there existing RTSP implementations that would reset the state to Init in this case? > >Further, suppose that the same scenario as (3) above plays out but the > >server returns 302 instead. What happens to the session, and should the > >server stop sending data packets? > >=20 > > > The scenario you think of is a DESCRIBE request with session header=20 > relating to a active session. That DESCRIBE request results in a 302=20 > response. However as DESCRIBE does not effect the session state (see=20 > table 6). I think there is a conflict in the state change rules. Perhaps the rules for state changes need to be re-examined, or at least clarified? > Also currently session header is not applicable for DESCRIBE requests=20 > (See table 4). This is true for draft-02, but 2326 section 12 says: Header type support methods =2E.. Session Rr req. all but SETUP, OPTIONS This is not strictly correct, as the Session header is indeed meaningful in SETUP, but it does allow Session to be used in DESCRIBE. --=20 I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, "Dijkstra would not have liked this", well that would be enough immortality for me. --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+IwsqqznSmcYu2m8RAq/OAJ9TwwUgDvqCrzlmK4DndYm6xXbTWACeImGD eRjqS4TbT/e/bGMniEHNFn4= =N3t/ -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 15 06:04:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22298 for ; Wed, 15 Jan 2003 06:04:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FBJA300435 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 06:19:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBJ9J00432 for ; Wed, 15 Jan 2003 06:19:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22287 for ; Wed, 15 Jan 2003 06:04:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBIZJ00391; Wed, 15 Jan 2003 06:18:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBHpJ00348 for ; Wed, 15 Jan 2003 06:17:51 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22278 for ; Wed, 15 Jan 2003 06:02:45 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0FB65KV018745; Wed, 15 Jan 2003 12:06:05 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNBC1A1; Wed, 15 Jan 2003 12:06:05 +0100 Message-ID: <3E25409D.8000802@era.ericsson.se> Date: Wed, 15 Jan 2003 12:06:05 +0100 X-Sybari-Trust: d239294a 1864f774 206fc897 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon References: <20030113185330.GB30293@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, Tom Marshall wrote: >>If the media content changes it should be published as a new resources >>with an new URI. >> >> > >I agree that it is desirable to have a new URI for a changed resource, >but I >don't think it should not be a MUST. I don't think the spec should >dictate >content policy to this degree. > > No, I agree but we should be clear with what a certain answer means so. That way we can avoid ambiguities if different content policies are used. > > >>>2. Same issue with SETUP, but in reverse. Does 304 necessarily imply >>>that the resource description is identical? >>> >>> >>What is your suggestion for the semantics of receiving a 304 to a >> >> >SETUP > > >>request? I have earlier asked what happens when one do SETUP to change >> >> > > > >>parameters and it does not work correctly, see bug 513737: >> >> >> >https://sourceforge.net/tracker/?group_id=23194&atid=377744&func=detail& >aid=513737 > >The answer to my question is implied: a 304 response to a SETUP does not >guarantee that the resource description is unchanged. Correct? > I don't know actually. Lets start deciding what resource that a If-Modified-Since header actually relates to in a SETUP request. Comparing this with Last-Modified header which for a SETUP relates to the media stream. In that case it seems valid that the If-Modified-Since header in a request relates to the media stream also. In that case a 304 would mean that the media stream which the URL in the request points at has not be changed. Assuming that the media stream has not changed, how could a resource description in that case be different while the media is not different. If that is possible we should point out this fact and explicitly declare that a 304 answer does not in fact guarantee the resource description is still the same. > >I admit that I have not thought about the issue in 513737 before. It >seems >to come from overloading the semantics of SETUP. > > I don't think this problem of overloading is that problematic. I simply think that we need to clarify the behavior of reSETUP request that fails. > > >>>3. The RTSP state machine mandates that a 3xx response to a request >>>changes >>>the state to Init. This is fairly logical for the other 3xx codes, >>> >>> >as > > >>>they >>>are used for redirection. Should 304 also follow this rule? Suppose >>>that a >>>client has a Session and is PLAYing a resource. The client then >>> >>> >issues > > >>>a >>>DESCRIBE on that same resource, specifying the existing Session and >>> >>> >an > > >>>If-Modified-Since header. The server returns a 304 response. What >>>happens >>>to the Session? Should it be considered torn down? Should the >>> >>> >server > > >>>stop >>>sending data packets? >>> >>> >>> >>> >>I think 304 needs to be excluded from this behavior. Is it not in fact >> >> > > > >>that a 304 response is the result of that the session state has not >> >> >been > > >>changed? >> >> > >Yes, it would be logical to exclude 304 from the state change in this >case. >But wouldn't this break compatibility with 2326? Are there existing >RTSP >implementations that would reset the state to Init in this case? > > Looking at the RFC2326 state machine nothing of this is explicitly declared. Therefore I don't think there is a problem of fixing this in the new state machine. > > >>>Further, suppose that the same scenario as (3) above plays out but >>> >>> >the > > >>>server returns 302 instead. What happens to the session, and should >>> >>> >the > > >>>server stop sending data packets? >>> >>> >>> >>> >>The scenario you think of is a DESCRIBE request with session header >>relating to a active session. That DESCRIBE request results in a 302 >>response. However as DESCRIBE does not effect the session state (see >>table 6). >> >> > >I think there is a conflict in the state change rules. Perhaps the >rules >for state changes need to be re-examined, or at least clarified? > > Yes, this needs consideration and clarification. I haven't thought before of the case that one actually desires to do a new describe of the session description of the session currently set up. This case might imply that a server needs to know that this request is in the context of the given session so it does not move a requesting party around due to load balancing, etc. In all other cases it looks like the DESCRIBE can be stateless and simply be a tool for requesting session descriptions related to a certain media resource. Have you any clarifying thoughts on when a session context is needed for a DESCRIBE? However the use of 302 for load balancing on DESCRIBE and SETUP request looks very dangerous. Lets assume that there are two server that are both fairly well loaded, what prevents them from sending a requesting party back and forth between the server without allowing it to get its description or session? > > >>Also currently session header is not applicable for DESCRIBE requests >>(See table 4). >> >> > >This is true for draft-02, but 2326 section 12 says: > >Header type support methods >... >Session Rr req. all but SETUP, OPTIONS > >This is not strictly correct, as the Session header is indeed meaningful >in >SETUP, but it does allow Session to be used in DESCRIBE. > > > Yes, as RFC 2326 is obvious in error and can easily be showed to contradict itself, this is not an argument. The valid argument for session header in request is simply: Are there reasons when the content of a DESCRIBE request is dependent on a already established session? If yes, session header shall be allowed in DESCRIBE, else not. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 15 08:01:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24669 for ; Wed, 15 Jan 2003 08:01:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FDG1F08261 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 08:16:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDG1J08258 for ; Wed, 15 Jan 2003 08:16:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24599 for ; Wed, 15 Jan 2003 08:00:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDFtJ08231; Wed, 15 Jan 2003 08:15:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDYJ08029 for ; Wed, 15 Jan 2003 08:13:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24378; Wed, 15 Jan 2003 07:58:25 -0500 (EST) Message-Id: <200301151258.HAA24378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 Jan 2003 07:58:25 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-implem-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Implementation Status Of SDP Author(s) : T. Taylor Filename : draft-ietf-mmusic-sdp-implem-00.txt Pages : 18 Date : 2003-1-14 This document is written to track implementations of the features of the Session Descritpion Protocol (SDP). Conventions used in this document This document is not intended to be normative, and therefore makes no reference to RFC 2119 conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-implem-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-implem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-implem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14151024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-implem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-implem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14151024.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 15 08:27:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26476 for ; Wed, 15 Jan 2003 08:27:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FDgZJ10529 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 08:42:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDgZJ10526 for ; Wed, 15 Jan 2003 08:42:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26436 for ; Wed, 15 Jan 2003 08:27:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDg9J10469; Wed, 15 Jan 2003 08:42:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDfTJ10429 for ; Wed, 15 Jan 2003 08:41:29 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26283 for ; Wed, 15 Jan 2003 08:26:19 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FDTdK14698 for ; Wed, 15 Jan 2003 08:29:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 08:30:01 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E15E@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: mmusic@ietf.org Subject: FW: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-implem-00.txt Date: Wed, 15 Jan 2003 08:29:39 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , Please have a look and tell me what cases I should add or what cases should be removed. We can also start collecting interop reports. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, January 15, 2003 7:58 AM Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-implem-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Implementation Status Of SDP Author(s) : T. Taylor Filename : draft-ietf-mmusic-sdp-implem-00.txt Pages : 18 Date : 2003-1-14 This document is written to track implementations of the features of the Session Descritpion Protocol (SDP). Conventions used in this document This document is not intended to be normative, and therefore makes no reference to RFC 2119 conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-implem-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-implem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-implem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 15 09:52:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28898 for ; Wed, 15 Jan 2003 09:52:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FF78t15837 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 10:07:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF77J15834 for ; Wed, 15 Jan 2003 10:07:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28872 for ; Wed, 15 Jan 2003 09:51:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF6hJ15589; Wed, 15 Jan 2003 10:06:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF5YJ15519 for ; Wed, 15 Jan 2003 10:05:34 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28826; Wed, 15 Jan 2003 09:50:22 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FErgM26520; Wed, 15 Jan 2003 09:53:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:53:42 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E163@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'mmusic@ietf.org'" , "'megaco@ietf.org'" Date: Wed, 15 Jan 2003 09:53:35 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [MMUSIC] draft-taylor-mmusic-sdp-tdm-xx 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 subject draft defined a bunch of attributes to allow text-formatted specification of bearer characteristics for TDM circuits. The Megaco NAS packages had a dependency on it. It appears that there is no real interest in this draft, so I am going to let it die. The purpose of this note is to make sure that is the right thing to do. I will rewrite the Megaco NAS packages draft to use the RFC 3108 bearerSigIE attribute where necessary. This implies that the NAS/MG has to understand the Q.931 encoding of the Bearer Capability, Low Layer Compatibility, and High Layer Compatibility Information Elements, expressed as hex strings. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 15 10:56:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00867 for ; Wed, 15 Jan 2003 10:56:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGB1A21161 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 11:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGB0J21158 for ; Wed, 15 Jan 2003 11:11:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00826 for ; Wed, 15 Jan 2003 10:55:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGAUJ21046; Wed, 15 Jan 2003 11:10:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG3hJ20130 for ; Wed, 15 Jan 2003 11:03:43 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00647 for ; Wed, 15 Jan 2003 10:48:30 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FFphYH001205; Wed, 15 Jan 2003 10:51:50 -0500 (EST) Message-ID: <3E24C13C.7030803@dynamicsoft.com> Date: Tue, 14 Jan 2003 21:02:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: mmusic@ietf.org Subject: Re: [MMUSIC] comedia-fix and the whole source address/port boondoggle References: <5.1.1.6.0.20030107090246.03445d08@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Responses inline. David Yon wrote: > comedia-fix again raises the argument against embedding the source > address/port information in the SDP. That is something that I still > feel strongly about, and work has progressed that makes use of it, > although not as a fail-safe session correlation mechanism. We've found > that it's useful as a DoS counter-measure, using the following design: > > - An intermediate proxy on our network acts as a STUN-like > inverse-NAT translator to at least recover the likely address > from where the media will originate, and rewrites the SDP > if necessary. It is quite a mystery to me how such a thing could possibly work in a causal fashion. The endpoint won't actually open any connections until after the offer/answer exchange has completed. The opening of the TCP connection is the thing which causes the NAT to assign a binding. So, the binding is assigned after the o/a exchange, but your proxy needs to know the binding before the exchange completes. So, I don't get it. > > - Our gateways, when under load, sort the incoming connection > pending queue based on source addresses that they expect > to arrive. > > The idea is that when under DoS attack, connections sourced from > uninvited addresses are not dealt with until the queue of invited > addresses has been serviced. This is especially critical when the media > is carried over TLS, and in our case we do not commence with the TLS > handshake until either the connection has been correlated or until > servicing the connection does not overload the gateway. The side-effect > of a failed/incorrect inverse-NAT rewrite only occurs under heavy load, > and is not fatal. But without the source address information, there is > no way to implement such a scheme. Since, practically speaking, I would expect the majority of users to connect to things from behind a NAT, this mechanism serves little purpose to prevent DOS attacks. I don't understand why you would not use more tried-and-true mechanisms, such as return routability, which validate a source IP address by sending it a cookie, and getting this cookie back. Such a mechanism actually works through NAT, and you can provide much more than just service prioritiziation based on it. I still maintain that, given we are painfully aware of the trials and tribulations of distributing source IP addresses in protocols, and given the vast potential for misuse, and the potentially small (if not ZERO) deployable benefits of this mechanism, I would like to see it removed. It is one thing to include a mechanism that is useful in many cases, but might not work in some (and then documenting such) as compared to a mechanism that will most likely be misused, and whose real benefit is small or zero. We should keep this bit separate from much of the rest of the comedia-fix stuff. I will comment on that separately (to a resolution I do think you will be happy with). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Wed Jan 15 10:56:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00880 for ; Wed, 15 Jan 2003 10:56:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGB4H21180 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 11:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGB3J21177 for ; Wed, 15 Jan 2003 11:11:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00829 for ; Wed, 15 Jan 2003 10:55:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGAhJ21072; Wed, 15 Jan 2003 11:10:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG4ZJ20153 for ; Wed, 15 Jan 2003 11:04:35 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00662 for ; Wed, 15 Jan 2003 10:49:20 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FFqYYH001211; Wed, 15 Jan 2003 10:52:40 -0500 (EST) Message-ID: <3E24CE61.8020203@dynamicsoft.com> Date: Tue, 14 Jan 2003 21:58:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: mmusic@ietf.org Subject: Re: [MMUSIC] comedia-fix-00 comments References: <5.1.1.6.0.20030103094038.00b37198@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Ben, Paul and I discussed your comments extensively over the last week or so. Our conclusion was that we will not use comedia for simple messaging sessions. At a high level, the conclusion was that we were looking at "message sessions over TCP" and that comedia was perhaps optimized for "streaming media sessions over TCP". As such, many of our requirements that were critical, or assumptions we could make (such as demux within a single TCP connection) don't necessarily apply to streaming media over TCP. Now, I still think that much of what we proposed is valid. However, it is no longer critical to get it changed. So, keep that in mind as you read my responses below. David Yon wrote: > This is a rather long and rambling commentary, so let me summarize the > major points up front: > > - The scaling issue is misstated. > > - The security issues raised are not actually solved by > comedia-fix, but can be mitigated more simply. > > - The proposed mechanism for session correlation has > serious side-effects that are not addressed. > > - The connection/session lifetime decoupling is a > major paradigm shift, and also has some serious > side-effects. > > Details below, arranged by comedia-fix sections: > > 3.1 Port Multiplicity on Servers > > This section is incorrect. Even without a means to correlate incoming > connections to sessions, the mapping of allocated port numbers to > clients is not 1:1. I'm surprised to see this statement in the draft > since I thought I had explained that in detail at earlier meetings. > > The size of the port space need only be as large as the NUMBER OF > PENDING OFFERS made to potential clients. This is not the scaling > problem described in comedia-fix (and not really a scaling problem at > all, IMO), and the draft should be updated to reflect this. I conceded this point. You are correct that its not 1:1. I still believe that this will fundamentally make tcp-based streaming media complicated for firewalls. It would be REALLY nice to allow an admin to open the "streaming FOO port" and that would allow for all media traffic of that type through. You are still going to need dynamic ports in your proposal, which perpetuates the firewall problems. The use of dynamic ports was (arguably) needed for UDP because there is no other protocol-independent demux. However, that is NOT true for TCP, which has the notion of multiple connections on a port. Thus, to me, any usage of TCP should make use of this natural and well-understood property, rather than perpetuating a (IMHO ultimately wrong) design choice for UDP [ranting for a moment, given the huge problems we have encountered in deploying voip, a large number of which are based on the usage of dynamic ports for session demux, I think ultimately we should have chosen a well-known port for RTP, and then used something like SSRC or CNAME to demux. But that is another conversation.] > 3.2 No Connection Re-Use > > This references 3.1 and restates the incorrect scaling assumption. > > This scenario seems to be the only problem for which connection/session > lifetime decoupling is presented as a solution. I cover this in more > detail below, but the short answer is that any economy of design derived > from this solution is offset by burdening other, more common scenarios > with undesirable restrictions. Can you explain what you mean? > > > 3.3 Security > > The Man-in-the-Middle attack can be mitigated by simply disallowing > multiple connections to the advertised IP/port during the offer period. > If more than one arrives, then the endpoint assumes an attack and does a > session teardown. (yes, this requires updating the language in comedia > to reflect this new scenario) That helps, but doesnt eliminate the problem. I can dos the other party, preventing them from connecting to you. This came up during the development of stun, which documents a similar attack. I admit this is not a crucial point, since if it truly bothers you, using real media level security will fix it. > > The firewall trust issue can be addressed by a chain of trust, can it > not? I.e., presumably the firewall authenticates/trusts a SIP proxy > which in turn authenticates/trusts each of the UA's. That would be the midcom approach, yes. > The instruction to > open/close pinholes is made by the SIP proxy to the firewall as a result > of the message traffic the proxy is relaying, not by any sort of > stateful packet inspection by the firewall. > > As for the "there's no ALG yet" argument for residential gateways: I > submit yet again that without including the source address/port, comedia > will preclude an ALG from ever being written. I think thats a good thing. ALGs are bad. Thats why midcom got started. We need to keep application layer intelligence out of them, and either get protocols to work through them without adding more to the mess (stun/turn), or even better, specify well-defined behaviors for them that can be controlled through something like nsis. But, all of that is far off. > > > 4.1 Endpoint-ID > > This concerns me greatly. During the extended period when comedia was > in development, I longed for just a "hook" that would allow for reliable > connection correlation. But alas, since we are signaling media streams > that use an open-ended set of protocols, such a hook did not exist. My > working assumption was that shoe-horning additional information into an > arbitrary protocol was outside the bounds of what SDP could impose. > Guess I was wrong. :-) We wrangled on this one too. In the end I felt the benefits (it would work, as opposed to, it didnt) outweighed the costs. > > The suggestion in comedia-fix (to use a header at the start of the > connection) jumbles the protocol stack, and as such may cause some > unintended consequences. Arguably, yes. Not the first time though. It is common to do this in many protocols that are strongly recommended in IETF. > At the heart of the issue is "what is it that > we are signaling here?". If we are signaling RTP/AVP over TCP, then we > violate the spec with the initial ID transmission. THink of it like a windowing operation in an operating system. During the times at which the RTP/AVP stack has the connection, its compliant. Its just that it doesnt get the connection right away. > If we are signaling > RTP/AVP over TLS, where does the ID transmission go, as part of the TLS > stream or prior to the TLS handshake? In either case we end up with a > stream that is neither (a) 100% RTP/AVP and/or (b) 100% TLS. Funny you should say this, since TLS is a good example of where common practice is to mix protocol layers. The recommended practice these days is for protocols to NOT run their apps over tls on a separate port. The prtoocol itself needs to be able to demux the two, and to transition from "raw protocol" to TLS. An example of this is the STARTTLS mechanism used in http and other protocols. First its HTTP, and then its TLS, all on the same TCP connection. Also, this is the only way for SASL to work. SASL, by design, inserts a security layer in the middle of the protocol stream. Sasl compliant protocols need to specify how they will demarcate the point at which you "hand the connection" over to the sasl security layer, so it can decrypt the messages and hand them over to the application. So, while I agree with your concerns, there is a long-established and recommended practice of such a thing in a good number of widely deployed IETF protocols. > > This problem can manifest itself in implementation complications as well > as middlebox problems. I don't see the middlebox issue. Please elaborate. > > Take TLS for example: let's say we put the endpoint ID ahead of the TLS > handshake. The OpenSSL folks were kind enough to provide C developers a > simple API where you prepend "ssl_" in front of the normal BSD socket > calls, and for the most part you can write code for SSL/TLS in the same > manner as raw TCP sockets. But with an endpoint ID, suddenly I the > developer have to do a more complicated scheme where I (a) connect a TCP > socket, (b) send/receive the endpoint ID, then (c) construct an SSL > session based on the connected socket. This of course presumes that the > language-specific API to SSL is flexible enough for the developer to > juggle the order of the protocol stack in this manner. Other API's > (Java, Perl, VB, etc.) may not be so forgiving. Indeed. THis is a weakness. Not a new one. In fact, the need to support STARTTLS makes me think this is a very common feature of TLS stacks. But, I have not looked into it. > Then there are the considerations for a decomposed gateway topology. By > multiplexing signalling information into the media stream, suddenly you > force the a tight coupling between the signalling and media transport > infrastructures by intermixing signalling tokens with the media stream. How is this different than having the signaling thing ask the media thing for an IP address, and then putting that IP address into the SDP? Then, when the media thing receives media on that IP address, it knows the "control" connection associated with it. Here, we do the same, but instead of IP address, its IP+eid. Same difference. > > For middlebox problems, consider the stateful packet inspection > firewall. The idea of course is to enforce a policy by protocol rather > than by connectivity. So SMTP, HTTP, FTP, and DNS are allowed, but > nothing else, and it doesn't matter what ports or addresses are used. > In theory the sysadmin should also be able to specify SIP, TLS, RTP/AVP, > and IM protocols in this list and allow those forward-looking end-users > to utilize this fancy new SIP stuff. With comedia-fix, every protocol > that is signaled will not, in fact, *be* the protocol described in the > SDP. So when the firewall watches the media stream, it doesn't see a > stream that fits any of the protocol structures it recognizes, and > therefore disallows the stream. Now I am confused. The way that firewall admins enforce policy by protocol rather than by connectivity is through ports. In the current comedia spec, there will almost never be just a single port for the newfangled media stream. So, you can't enforce policy. The mechanism in comedia-fix allows there to be one, and only one, port allocated for any specific media-over-tcp type. This will enable firewall admins to do things, not disable it. I do not understand your point about the protocol not "being" the one that is advertised. It most certainly is, with the addition of a 32 byte ID up front, but who cares? > > Another case is where TLS is provided by an external accelerator box to > offload the compute load of the server---same issue. > > > 4.2 Decoupled lifetimes > > This has a number of side-effects. First, it essentially forces a > single-port architecture on both of the endpoints, as the only other > option is the "this-doesn't-scale" 1:1 client-to-port-number mapping. > With comedia as it stands today, the lifetime of the listener port is > decoupled from the lifetime of the session that is begat from that > listener. No longer the case with comedia-fix. You can use as many ports as you like, ranging from 1 to one for each session. Because I don't need the port to correlate, I am free to use any algorithm I like. Comedia has to use an algorithm which has at least one-per-pending-offer, because you have no way to correlate. Therefore, I do not believe that comedia-fix introduces a binary "1 port" or "1 port per session" restriction. > > Second, it forces endpoints to use "both" where one could have opted for > just "active" or "passive". The problem here is that if one endpoint > specified "passive", and the media connection drops, it has no way to > legally reinstate the connection if it needs to send data to the other > endpoint. In essence, comedia-fix "raises the stakes" as to what is an > appropriate connection mode to negotiate. In comedia, the only thing at > stake was the ability to bring up the intial connection. In > comedia-fix, we add the issue of recovering from the scenario that the > remote endpoint will drop the connection. You need to handle connection failures. In the current comedia, if the passive side loses the connection, it can bring it up by doing a re-invite and then include a reconnect parameter. What you CANNOT do is have the active side reconnect without doing a re-inVITE. In comedia-fix, you can have the active side reconnect without doing a re-INVITE. There is no reason we could not also allow the passive side to do a re-INVITE to force a reconnect from the active side. I did propose to remove that, but perhaps it is useful after all. > > Third, as described in comedia-fix, NAT's can cause a similar outage to > #2 even if each endpoint specifies "both". > > The decoupled lifetime, to my knowledge, is unprecedented. Really? See RFC3261. SIP can run over TCP. When it does, the lifetime of the connection is not strongly coupled to the lifetime of the transaction or dialog. It used to be, in rfc2543. After years of trying to make it work, we found it was a nightmare to maintain. THus, it got disacarded. The result was a nice clean separate of the SIP layer from teh TCP connectivity layer. This change bought us many properties, including improvements in robustness (the ability to recover a SIP transaction even if the tcp connection the request went over had closed). Its critical in any protocol where the intermediary elements provide a subset of the endpoint functionality. > In > developing comedia I tried to apply the litmus test of "how is this > scenario handled in connectionless media, and how do connections > differ?". I don't believe that decoupled lifetimes fares very well > here. Remember that while "traditional" SDP media transports may be > connectionless, they aren't stateless. So the corollary to decoupling > connection lifetime from session lifetime is akin to allowing RTP/AVP > streams to be stopped, reset, then restarted, all without any additional > activity on the signalling channel. Again, I'm not an expert here, but > I imagine that this would be considered outside the spec today. There is no notion to starting/stopping RTP streams, so its hard to say what this would mean. > > I also don't understand the rationale behind the statement: "If one side > wishes to force the other to reconnect, it merely drops the connection. > When the other side has data to send, it will establish a new > connection." The "reconnect" attribute was never intended to "force" > reconnects. Rather, it was intended as a way to recover from an > *unintended* disconnection in such as a way as to preserve the existing > session state. Is there ever a reason that an endpoint would tear down > the connection solely to inconvenience the other endpoint with the task > of re-establishing it? (insert half-smiley here, since that's the > impression one gets from the language in comedia-fix) No, of course not. I must admit I am not sure what I meant here. Per above, I do see how the reconnect parameter would help. > > I guess I'm having trouble understanding why it is so important that the > lifetime be decoupled. The only argument put forth is the > multiplexing-bridge scenario. If we really are using a multiplexed > tunnel to bridge two networks, what's the harm in making the tunneling > connection "sticky"? The intermediaries in this case woudl need to "reference count". That is, they would need to keep track of each session that gets set up, and then torn down, which had media over that connection. This is impossible to do when the media intermediary is decoupled from the SIP proxy. Doing it would require what we call a B2BUA in SIP, along with a colocated media intermediary or a remote one under tight control. Another problem is disconnects due to some kind of network outage. Lets say users are sending their TCP-media through two relays. The connection between the relays gets lost, but the connections from each user to their relay remains. Neither user will try to reconnect, since as far as they know, there is no TCP connection problem. The relays know there is a problem, and they could reconnect, but comedia prohibits them from doing so. They would have to be a b2bua once more, and issue a new INVITE on their own, just to re-establish it. In other words, the relays need to be the same (in terms of fucntioanlity) as the endpoints. I want to drive such things out of intermediaries, not INTO them. So, to sum up, with comedia today, building these relays requires a very tight coupling between the SIP proxy (which has to be a b2bua) and the tcp media relay. WIth the comedia-fix, they are decoupled. The SIP intermediary can remain a proxy, and the media-relay can worry about its own connectivity. > On the flip side, since there is a multiplexing > function occurring in an intermediary, shouldn't there be a mechanism > for determining the lifetime of the feeds into the mux that just makes > this problem go away? How today, do the endpoints in this scenario know > when to do an initial INVITE, then do the final BYE? Sure, it can be computed. It just introduces a coupling whcih is not otherwise there. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Wed Jan 15 13:15:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05583 for ; Wed, 15 Jan 2003 13:15:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FITkd31589 for mmusic-archive@odin.ietf.org; Wed, 15 Jan 2003 13:29:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FITkJ31586 for ; Wed, 15 Jan 2003 13:29:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05563 for ; Wed, 15 Jan 2003 13:14:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FITXJ31568; Wed, 15 Jan 2003 13:29:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FISoJ31497 for ; Wed, 15 Jan 2003 13:28:50 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05480 for ; Wed, 15 Jan 2003 13:13:35 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18Ys5w-0002Pa-00 for ; Wed, 15 Jan 2003 10:16:56 -0800 Date: Wed, 15 Jan 2003 10:16:56 -0800 From: Tom Marshall To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon Message-ID: <20030115181656.GA9121@real.com> References: <20030113185330.GB30293@real.com> <3E25409D.8000802@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <3E25409D.8000802@era.ericsson.se> User-Agent: Mutt/1.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: , --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >The answer to my question is implied: a 304 response to a SETUP does not > >guarantee that the resource description is unchanged. Correct? > > >=20 > I don't know actually. Lets start deciding what resource that a=20 > If-Modified-Since header actually relates to in a SETUP request.=20 > Comparing this with Last-Modified header which for a SETUP relates to=20 > the media stream. In that case it seems valid that the If-Modified-Since= =20 > header in a request relates to the media stream also. In that case a 304= =20 > would mean that the media stream which the URL in the request points at= =20 > has not be changed. My assumptions are that: 1. The resource description is independent from the resource content. This follows from having a resource description be available via alternate means (eg. an HTTP download). 2. The resource description may change while the content does not. One example would be fixing a typo in an i=3D, e=3D, or p=3D line of SDP. 3. The resource content may change while the description does not. One example would be re-encoding a media file with the same codec settings.= =20 Another example would be live content. > Assuming that the media stream has not changed, how could a resource=20 > description in that case be different while the media is not different.= =20 See above. > If that is possible we should point out this fact and explicitly declare= =20 > that a 304 answer does not in fact guarantee the resource description is= =20 > still the same. Agreed. I will state that the 304 response to a DESCRIBE or SETUP does not imply anything about the response to the other method. > >I admit that I have not thought about the issue in 513737 before. It > >seems > >to come from overloading the semantics of SETUP. > >=20 > > > I don't think this problem of overloading is that problematic. I simply= =20 > think that we need to clarify the behavior of reSETUP request that fails. It will be interesting to see how well this works. There seems to be a non-trivial number of combinations of headers and response codes that can be used with a SETUP request/response. > >Yes, it would be logical to exclude 304 from the state change in this > >case. But wouldn't this break compatibility with 2326? Are there > >existing RTSP implementations that would reset the state to Init in this > >case? > >=20 > Looking at the RFC2326 state machine nothing of this is explicitly=20 > declared. Therefore I don't think there is a problem of fixing this in=20 > the new state machine. It is in section A.1: "If a request yields a status code of 3xx, the state becomes Init, and a status code of 4xx yields no change in state." This sentence makes it very, very tempting to code the state machine based solely on the first digit of the status code. In fact, I think rfc2068 (upon which a large part of rfc2326 is based) encourages this behavior.=20 Also note that the error in assuming that all 3xx codes are redirections is carried over from rfc2068. I don't know if any existing RTSP state machines behave based solely on the class of status code, but the concern should be noted. > Yes, this needs consideration and clarification. I haven't thought=20 > before of the case that one actually desires to do a new describe of the= =20 > session description of the session currently set up. This case might=20 > imply that a server needs to know that this request is in the context of= =20 > the given session so it does not move a requesting party around due to=20 > load balancing, etc. In all other cases it looks like the DESCRIBE can=20 > be stateless and simply be a tool for requesting session descriptions=20 > related to a certain media resource. Have you any clarifying thoughts on= =20 > when a session context is needed for a DESCRIBE? I know that in our (RealNetworks) system, the session context is used for a DESCRIBE. If you look at past and current versions of our software, you will see it passed as both an ETag (which is a Session in disguise) and an actual Session. This is not to say that the context is needed in the strict sense, but it is used. I expect (and hope to motivate) a move away from using session context in such a manner, but there is one example that has been in use for several years. > However the use of 302 for load balancing on DESCRIBE and SETUP request= =20 > looks very dangerous. Lets assume that there are two server that are=20 > both fairly well loaded, what prevents them from sending a requesting=20 > party back and forth between the server without allowing it to get its=20 > description or session? Nothing prevents this in either HTTP or RTSP. Most clients will track the number of redirects received and complain if it is "too many". > >>Also currently session header is not applicable for DESCRIBE requests= =20 > >>(See table 4). > >> =20 > >> > > > >This is true for draft-02, but 2326 section 12 says: > > > >Header type support methods > >... > >Session Rr req. all but SETUP, OPTIONS > > > >This is not strictly correct, as the Session header is indeed meaningful > >in > >SETUP, but it does allow Session to be used in DESCRIBE. > > > >=20 > > > Yes, as RFC 2326 is obvious in error and can easily be showed to=20 > contradict itself, this is not an argument. The valid argument for=20 > session header in request is simply: Are there reasons when the content= =20 > of a DESCRIBE request is dependent on a already established session? If= =20 > yes, session header shall be allowed in DESCRIBE, else not. See above. --=20 Give a man a fish, and you feed him for a day. Tell him he should learn how to fish himself, and he'll hate you for a lifetime. --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD4DBQE+JaWYqznSmcYu2m8RAsX/AJijdhxTHxyRcMbvkP9Ko/iaIq3EAJ41vNBL A55T5zGLW9dYpYykWqGUGQ== =9Nly -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jan 16 10:20:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13613 for ; Thu, 16 Jan 2003 10:20:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFZo430407 for mmusic-archive@odin.ietf.org; Thu, 16 Jan 2003 10:35:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFZoJ30404 for ; Thu, 16 Jan 2003 10:35:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13606 for ; Thu, 16 Jan 2003 10:20:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFZQJ30390; Thu, 16 Jan 2003 10:35:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFYdJ30337 for ; Thu, 16 Jan 2003 10:34:39 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13572 for ; Thu, 16 Jan 2003 10:18:57 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0GFMIKV019593; Thu, 16 Jan 2003 16:22:18 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNDMG99; Thu, 16 Jan 2003 16:22:18 +0100 Message-ID: <3E26CE2A.1050305@era.ericsson.se> Date: Thu, 16 Jan 2003 16:22:18 +0100 X-Sybari-Trust: 2c77b633 9ffcebbb ba5f67bb 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP draft changes from telecon References: <20030115181656.GA9121@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 Tom Marshall wrote: >>>The answer to my question is implied: a 304 response to a SETUP does >>> >>> >not > > >>>guarantee that the resource description is unchanged. Correct? >>> >>> >>> >>I don't know actually. Lets start deciding what resource that a >>If-Modified-Since header actually relates to in a SETUP request. >>Comparing this with Last-Modified header which for a SETUP relates to >>the media stream. In that case it seems valid that the >> >> >If-Modified-Since > > >>header in a request relates to the media stream also. In that case a >> >> >304 > > >>would mean that the media stream which the URL in the request points >> >> >at > > >>has not be changed. >> >> > >My assumptions are that: > >1. The resource description is independent from the resource content. >This > follows from having a resource description be available via alternate > means (eg. an HTTP download). > >2. The resource description may change while the content does not. One > example would be fixing a typo in an i=, e=, or p= line of SDP. > >3. The resource content may change while the description does not. One > example would be re-encoding a media file with the same codec >settings. > Another example would be live content. > > Ok. > > >>Assuming that the media stream has not changed, how could a resource >>description in that case be different while the media is not >> >> >different. > >See above. > > > >>If that is possible we should point out this fact and explicitly >> >> >declare > > >>that a 304 answer does not in fact guarantee the resource description >> >> >is > > >>still the same. >> >> > >Agreed. I will state that the 304 response to a DESCRIBE or SETUP does >not >imply anything about the response to the other method. > > How do we solve the scenario when a SDP description is distributed with HTTP and the client would like to setup this session under the assumption that the resource description has not changed in relation to the media. Does etags work for this? In that case I think the proposed clarification works fine. >>I don't think this problem of overloading is that problematic. I >> >> >simply > > >>think that we need to clarify the behavior of reSETUP request that >> >> >fails. > >It will be interesting to see how well this works. There seems to be a >non-trivial number of combinations of headers and response codes that >can be >used with a SETUP request/response. > > Yes, there are a couple of questions here. But my direct approach would be that a 200 response means that the requested changes has happened. A 100 answer would mean not yet. A 3xx answer I assume is the same as a REDIRECT request for that session, with the possible exception for 304. A 4xx would mean that nothing has been changed due to some error in the request. A 5xx is usual a little dependent on what has actually happened. If the session is still useable at least the parameters shall not have been changed. Which means that a server must basically verify that it can address all changes requested in the change before actually performing them. However I guess that the above idea might not totally fly when one starts to look into all details. >It is in section A.1: "If a request yields a status code of 3xx, the >state >becomes Init, and a status code of 4xx yields no change in state." > >This sentence makes it very, very tempting to code the state machine >based >solely on the first digit of the status code. In fact, I think rfc2068 >(upon which a large part of rfc2326 is based) encourages this behavior. >Also note that the error in assuming that all 3xx codes are redirections >is >carried over from rfc2068. > >I don't know if any existing RTSP state machines behave based solely on >the >class of status code, but the concern should be noted. > > I think the notion of coding the state machine after the first digit is actually good one. However in this case it might be needed to either clarify the exception or actually move 304 to a new number space like 6xx. What the general category would actually do is another question. >I know that in our (RealNetworks) system, the session context is used >for a DESCRIBE. If you look at past and current versions of our software, you >will see it passed as both an ETag (which is a Session in disguise) and >an actual Session. This is not to say that the context is needed in the >strict sense, but it is used. I expect (and hope to motivate) a move away from >using session context in such a manner, but there is one example that >has been in use for several years. > > Okay, that I guess that we might need to allow session header in DESCRIBE request to allow for compatibility. However depending on what motivations we can see write some text how it actually shall be used. >>However the use of 302 for load balancing on DESCRIBE and SETUP >> >> >request > > >>looks very dangerous. Lets assume that there are two server that are >>both fairly well loaded, what prevents them from sending a requesting >>party back and forth between the server without allowing it to get its >> >> > > > >>description or session? >> >> > >Nothing prevents this in either HTTP or RTSP. Most clients will track >the >number of redirects received and complain if it is "too many". > > Okay, I guess that work and does not need fixing. However a note about this might be useful. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Jan 19 14:46:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24734 for ; Sun, 19 Jan 2003 14:46:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0JK3dG18305 for mmusic-archive@odin.ietf.org; Sun, 19 Jan 2003 15:03:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JK3dJ18302 for ; Sun, 19 Jan 2003 15:03:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24701 for ; Sun, 19 Jan 2003 14:46:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JK34J18294; Sun, 19 Jan 2003 15:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JJx6J18171 for ; Sun, 19 Jan 2003 14:59:06 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24625 for ; Sun, 19 Jan 2003 14:41:54 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0JJj1Fp004326; Sun, 19 Jan 2003 11:45:01 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AAQ75967; Sun, 19 Jan 2003 11:45:00 -0800 (PST) From: "Cullen Jennings" To: , "Jonathan Rosenberg" Date: Sun, 19 Jan 2003 11:50:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Endpoint IDs in draft-rosenberg-mmusic-comedia-fix-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: 7bit Content-Transfer-Encoding: 7bit Few thoughts.... Have you considered using the TCP ISN for the endpoint id? I imagine this is not really practical from an implementation point of view. Perhaps how the Endpoint ID is communicated in the connection should be out of scope of this draft and the draft should just required that there is some way to do it in the initial hello. Things like BEEP and SCTP could use a different mechanism to deal with passing the EndPoint ID. I wonder if a 32 bit Endpoint is large enough if a client needs to be prepared to receive multiple connections on the same port at any time in the session. Some attacker could just try random Endpoint ID for a long time and hope to connect. A client like a SMS GW could have lots of valid EndPoint IDs that bring up the birthday attack problem. I have not thought too much about how fast this search space can be covered but it seems that it is in the many days magnitude. I am confused by messages 7,8,9 in figure 2. Cullen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 20 07:58:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18366 for ; Mon, 20 Jan 2003 07:58:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KDFmJ18049 for mmusic-archive@odin.ietf.org; Mon, 20 Jan 2003 08:15:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDFmJ18046 for ; Mon, 20 Jan 2003 08:15:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18360 for ; Mon, 20 Jan 2003 07:58:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDFMJ18019; Mon, 20 Jan 2003 08:15:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDEXJ17973 for ; Mon, 20 Jan 2003 08:14:33 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18343 for ; Mon, 20 Jan 2003 07:56:58 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0KD0NKV015100 for ; Mon, 20 Jan 2003 14:00:23 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1HZT1X; Mon, 20 Jan 2003 14:00:23 +0100 Message-ID: <3E2BF2E7.60509@era.ericsson.se> Date: Mon, 20 Jan 2003 14:00:23 +0100 X-Sybari-Trust: d33a9c41 9ffcebbb cd1bde24 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP telecon 22 january 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, Just a reminder about the RTSP teleconference on wednesday, 18.00 (CET) 9.00 (PST). If you desire to participate and have not yet received any details please send me a mail. I used the rtspspec-logistics list to distribute the information. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jan 21 17:16:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13722 for ; Tue, 21 Jan 2003 17:16:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LMYZB21753 for mmusic-archive@odin.ietf.org; Tue, 21 Jan 2003 17:34:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMYZJ21750 for ; Tue, 21 Jan 2003 17:34:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13719 for ; Tue, 21 Jan 2003 17:16:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMYLJ21735; Tue, 21 Jan 2003 17:34:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KN0JJ21629 for ; Mon, 20 Jan 2003 18:00:19 -0500 Received: from bels002.mediator.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03305 for ; Mon, 20 Jan 2003 17:42:32 -0500 (EST) Received: from bays02.mediator.com ([172.16.100.252]) by bels002.mediator.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Jan 2003 14:45:56 -0800 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" Date: Mon, 20 Jan 2003 14:45:55 -0800 Message-ID: <30A6344AEBFC85429C30FF6C9C501CD1184FD3@bays02.mediator.com> Thread-Topic: Pipelining RTSP SETUP Thread-Index: AcLA1bFkGX8tUXNVRK6j6lCQqfuEcA== From: "Josh Perfetto" To: X-OriginalArrivalTime: 20 Jan 2003 22:45:56.0967 (UTC) FILETIME=[B22D3770:01C2C0D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KN0JJ21630 Subject: [MMUSIC] Pipelining RTSP SETUP 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: 8bit Content-Transfer-Encoding: 8bit Hello All, As I read RFC2326, in the typical DESCRIBE followed by multiple SETUPs, the server will first assign the RTSP session ID in response to the first SETUP. The player is supposed to include this session ID in all subsequent requests. However, this seems to preclude the possibility of pipelining a second SETUP request with the first one, as the session ID for the second SETUP wouldn't be known at the time it is sent. Is this correct? If it is, I would think it is a significant shortcoming, as pipelining is essential when streaming over high-latency wireless networks. Is this something that could be looked at in 2326bis? RFC2326 does say that the server doesn't need to generate session identifiers if it has another means of identifying requests, but the player wouldn't know this until it receives the first SETUP response. -Josh -- Josh Perfetto Director of Architecture Vidiator Technologies josh@vidiator.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jan 21 19:36:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16405 for ; Tue, 21 Jan 2003 19:36:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M0rqE30050 for mmusic-archive@odin.ietf.org; Tue, 21 Jan 2003 19:53:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0rqJ30047 for ; Tue, 21 Jan 2003 19:53:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16399 for ; Tue, 21 Jan 2003 19:35:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0rUJ30022; Tue, 21 Jan 2003 19:53:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0qrJ29982 for ; Tue, 21 Jan 2003 19:52:53 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16383 for ; Tue, 21 Jan 2003 19:34:33 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h0M0bvI18849; Tue, 21 Jan 2003 16:37:57 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:37:57 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7724@MISTY> From: Thomas Zeng To: "'Magnus Westerlund'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-rfc2326bis-02.txt Date: Tue, 21 Jan 2003 16:37:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) 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: , Magnus: I finally have found some time to respond to your email from Dec 16., albeit briefly: 1. I have logged a bug (672160) against item 7 below. 2. There was only one typo re item 14 below (and you said you found it). 3. Regarding item 17 below (about Server sending TEARDOWN to Client and also optionally END_OF_STREAM), are you in favor of our proposals (meaning allowing TEARDOWN on S->C and also add END_OF_STREAM? We will send you more comments/additions once we have come up with draft text for other issues (e.g., items 1 and 18 below). See you tomorrow on the telecom. Regards, thomas -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Monday, December 16, 2002 7:30 AM To: Thomas Zeng Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rfc2326bis-02.txt Hi Thomas, I will try to respond to your comments. I hope that people manage to read this very long mail. If responding please trim away all unnecessary text. Thomas Zeng wrote: >PacketVideo has the following collective comments: > >1. Section 10, method Definitions, in the table, it indicates in the Client >Req column that OPTIONS is Required for Send - this doesn't make sense to me >- what does it mean that the client is required to send OPTIONS? When? > > The requirements are related to implementation not usage. In fact I would believe that sending of OPTIONS on the client side may only be Recommended. => So this section should be fixed to clarify the that the requirements are regarding implementation. It should also be consider to change OPTIONS, Sd to recommended. >2. How can they not bump the Version number (say from 1.0 to 1.1) when they >are allowing non-interoperable changes from 2326? For example, from section >10.5 - PLAY: > >" After playing the desired range, the presentation is NOT automati- | > cally paused, media deliver simple stops. A PAUSE request MUST be | > issued before another PLAY request can issued. Note: This is one | > change resulting in a non-operability with RFC 2326 implementations. | > A client not issuing a PAUSE request before a new PLAY will be stuck | > in PLAYING state. A client desiring to play the media from the begin- | > ning MUST send a PLAY request with a Range header pointing at the | > beginning, e.g. npt=0-. " > >What's the point of being "stuck" in playing state? If *EVERY* client has >issue the PAUSE request >before being able to do something useful, why not just assume they all did >and stick with the >current behavior of returning to the READY state? What is the behavior if >the client issues a PLAY >before a PAUSE? > > > The reason for this change is that it removes all automatic state changes that does not result in session deletion. Having automatic state changes is a big problem for the state consistency between client and server. One existing problem with the old state machine is that a client could send a PLAY request and not know what the result of it would be. The request could either be queued or played out directly. This may be acceptable if one would only be interested in basic on-demand play functionality. However to have this protocol be robust to extensions this change is needed. One needs to know what behavior one shall expect when sending a request. Regarding the interoperability issue. This is currently the most evident issue. However I don't regards it as extremely problematic. A client has at least managed to play the stream once. There are other issues that exist when we know that different implementations are not compatible. One example is the behavior at the end of the stream. Some server sets the current play out point to 0.0 when reaching the end of a media clip will others do not. A client will not be able to be interoperable with both servers. In this case however a simple fix exist and that is to always include a range header. However a client not knowing this will not be interoperable. So far this interoperability problem has been regarded as minor compared to the need to fix the underlying problem. A new version number would not fix the underlying problem which is that RTSP 1.0 has major interoperability problems due to specification shortcomings. My working hypothesis is that we will try to fix RTSP 1.0 so that it works. Any change resulting in interoperability problems need to be documented as I have done in this case. (We should perhaps gather them in a special chapter). Then if the end we can't fix the protocol without totally breaking the interoperability then we will have to accept a new version number. We will not fix this protocol without hurting some of the deployed implementations at least to some extent. My goal is to let things be minor. In the updated version the correct reponse to a PLAY request in playing state is: "455 Method Not Valid in This State". > >3. One of the big gaps in the previous spec was how to use Basic and Digest >Authentication in the context of RTSP. This draft does not give any more >clarification. Do you send the authentication headers in all requests? >Only until a valid session ID has been established? Just the DESCRIBE? In >all SETUPs? Details like these need to be worked out and an example >wouldn't hurt either. > > Yes, I agree that we should have security feature like authentication in the core spec or an extension spec of RTSP. The big problem is that this is basically at the same maturity level as specifying some new functionality. So we need someone to start writing on this. If you are interested in this you are very welcome to volunteer to write this. >4. In section 3.3, "Session identifiers are opaque strings of arbitrary >length. Linear white space must be URL-escaped." Why allow spaces? And URL >escaping results in the '%' characters. The BNF they use to detail the >session ID does NOT allow for spaces or the '%' character: > > session-id = 8*( ALPHA / DIGIT / safe ) > > ALPHA = UPALPHA / LOALPHA > UPALPHA = > LOALPHA = > DIGIT = > safe = "$" / "-" / "_" / "." / "+" > > A simple type I would say, the sentence is out of date and not in line with the BNF definition. I resolve this by checking in a version with out the sentence "Linear white space must be URL-escaped." I guess that resolves this issue. >5. Can the open-ended start time be used for live presentations? For >example, can "-30" mean play from now til 30 seconds form now? How about >"now-30" or "now-now+30" to indicate streaming from the current point in the >live stream, but only streaming for 30 seconds. > > Yes, they can be. The BNF allows for example the following ranges clock=-20021216T164500Z, or npt=now-00:30:00. However the now-now+30 is not valid. In the case of live sessions the most reasonable seems to be to use the UTC format (clock) to specify a wall clock time when the session ends. In that case a simple start time open ended is sufficient. >6. Need to resolve the problem of supporting the REDIRECT request and >non-persistent connections. If you are using non-persistent connections, >there is no way for a server to send a REDIRECT request to the client. > > I think this is as resolved as it ever will be. The client is strongly recommended to have persistent connections. If not keeping the connection open and the server would like to do redirect/announce etc. the client, the server will simply let the request fail. In this case this failure will result in that the sever ends the session when it has to. This is the incentive for a client to keep a connection alive. Of course this must be clearly documented. > >7. In the section on RTP interleaved over the RTSP channel, there was no >mention of the client sending RTCP RR back to the server. Are these still >present? They did specify the sender reports from the server to client, but >that's it. > This is a new bug, would you please register it at source forge: http://rtspspec.sourceforge.net. Please log in before registering a bug. However my opinion is that this channel should allow for sending RTCP traffic also to the server. It seems simple to assume symmetry of the identifiers. Please give your view of how this is simplest and best solved. > >8. The description of the redirection responses needs work. It's not >clear how they see the use of load balancing, etc. > > Please provide more details of what you think is missing. In most case I assume that there is no need for the client to know the reason behind a redirect as long as the correct behavior is indicated. >9. Table 3, page 51: Why are DESCRIBE, ANNOUNCE, and PING supported for a >request on the media URL? I understand them to work on the presentation >URL, but I don't think that they are appropriate to work on the media-level >control URLs. > > In cases you don't do media aggregation the use of ANNOUNCE and PING are motivated. Of course, you can in that case see it as the presentation URL and media-url is the same. The use of DESCRIBE I can't motivate other way that the difference between a presentation and a media URL are not always clear. One example of usage could be a non aggregated session that becomes redirected. In that case the media should not be directed to the whole presentation rather the media. If the client checks the media description to verify that it is in fact the same media and not a another configuration it is motivated. >10. Section 12.18, why MUST the server send the "Date" header? And what is >the determining factor to say a sending host has a clock? How could a >server send RTP data without a clock? > > The "Date" header MUST be sent with any request or response containing a body. Which means that for a server only the DESCRIBE response really MUST contain a Date header. However it good to include it also in other request for logging, debugging purposes. For the messages with body it is for proxy reasons so that one can judge how old the content in the proxy is. In the case of Date it is evident that the requirement is to have a wall time clock, i.e. capable of producing time in GMT/UTC. >11. Section 12.19, page 63, Why can't they define a separate string value to >indicate that the description "Never Expires" instead of using a date/time >that is one year in the future? > There seem to be a very good reason for this. Can you really guarantee that any thing will work and accessible for all time in the future. By specifying the expire time one year into the future you give it a very long life time but still bounded. > >12. Section 12.29, must a server understand the "time" parameter in the >range header in a request? And what error should it respond if it doesn't >support the time parameter? There is no way to inform the client that it >does/doesn't support this parameter. > > Looking at the specification, it seems that it is assumed to be a part of the core functionality of the protocol that is required to be supported. >13. Section 12.38, the first line of the "Supported" example looks garbled. > > Yes, It certainly is >14. The introduction of the "client_rtcp_port" and "server_rtcp_port" REALLY >breaks backwards compatibility. The RTSP version number MUST be bumped! >And there is a typo in that section/example where "client_rtcp_port" is used >twice - one in place of the server port. > No, it does not. Not with the described mechanism of resolving this. By requiring a client to check if the sever supports the new parameters interoperability can be ensured. So the use of this parameter requires that the client to include the supported header in a request prior to the SETUP to determine if feature tag "play.basic" is supported by the server. If support is signaled then the client MAY include the client_rtcp_port. If a server receives a SETUP request with client_rtcp_port parameter it shall include its own RTCP port in server_rtcp_port. I find one typo, the item name was client in the description. What was the other one? One big problem with the transport header is that it doesn't support extensions. This I think must be corrected. If extensions are required to be understood feature tags in the Require header should be used. > >15. In section 9.3 it states that the server MUST NOT close the connection >directly after responding to the TEARDOWN request for the whole session. >Are they trying to state >that the server should wait to ensure that the response arrives at the >client? I don't understand >how this is case is different than the handling of any other RTSP response. > > TEARDOWN is not different from other request. It is only a clarification to some implementations that do close the TCP connection as a response to the TEARDOWN request. It should be the client that initiate closing of the TCP connection. However the server may close the TCP connection after a time-out interval without traffic. >16. Section 9.3 also states "A persistent connection MAY be used for all >transactions between the server and client, including messages to >multiple RTSP sessions." It would be a good idea to point out the server >MAY impose limits on the number of simulataneous sessions a client is >allowed to create/control. > > I think I understand the motivation behind your request. However I don't think such a restriction is possible in the current look of the RTSP standard. The scenario when such a restriction is hard to enforce is: A large number of clients are sitting behind the same proxy. The proxy multiplex all the clients it handles into a single TCP connection. How does the server distinguish that it is talking with many different clients and not a single one behind the proxy? >17. In table 2 of section 10, the TEARDOWN message should also be required >to be handled in the >Server->Client direction. There are cases where the server needs to drop >the client >(e.g., load shedding) and it is better if it can inform the client that this > >is happening. A few IETFs ago someone was proposing "END_OF_STREAM" as a >new RTSP request from Server to client. But TEARDOWN from server to client >could be more appropriate. > Okay, TEARDOWN in S->C may be motivated when a server needs to get rid of all its clients and has no alternative server to REDIRECT to. However to make this useful compared to just deleting the sessions and refusing any connections a channel for extra information about the reason is needed. This could be included in the body but also SIPs warning may be appropriate. However the END_OF_STREAM had other purposes as it was to indicate that all media of the current request had been sent. > >18. Section 12.10: The section on the server closing the connection should >be softened: > >12.10 Connection > > See [H14.10]. The use of the connection option "close" in RTSP mes- | > sages SHOULD be limited to error messages when the server is unable | > to recover and therefore see it necessary to close the connection. | > The reason is that the client shall have the choice of continue using | > a connection indefinitely as long as it sends valid messages. > >The standard shouldn't mandate server policies on the use of resources. The >server should have the option >of closing connections (perhaps without dropping the RTSP session) if >demanded by resource constraints or >usage policies. > > This text is added to clarify that the usage of close that is evident in some implementations today are not correct. In my view a TCP connection should not be closed from server end unless its inactive for at least one RTSP time-out period. It may also be kept open for longer as the RTSP session is kept alive with RTCP messages. However I can agree that another formulation of this may be more appropriate. I see that there exist problems like DOS attacks by setting up many TCP connections, etc. that would require the server to start closing connections. Please propose how you would like it to be written. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 22 00:19:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21842 for ; Wed, 22 Jan 2003 00:19:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M5asI13597 for mmusic-archive@odin.ietf.org; Wed, 22 Jan 2003 00:36:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5asJ13594 for ; Wed, 22 Jan 2003 00:36:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21828 for ; Wed, 22 Jan 2003 00:18:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5aSJ13579; Wed, 22 Jan 2003 00:36:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5Z5J13500 for ; Wed, 22 Jan 2003 00:35:05 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21804 for ; Wed, 22 Jan 2003 00:16:41 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18bDJ1-0000Kl-00 for ; Tue, 21 Jan 2003 21:20:07 -0800 Date: Tue, 21 Jan 2003 21:20:07 -0800 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030122052007.GA1271@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [MMUSIC] Proposed update to draft-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: , --GID0FwUMdk1T2AWN Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The attached diff addresses the issues that Magnus and I have been discussing in the past week. Comments would be appreciated. I will be attending the telecon tomorrow. --=20 Nothing will dispel enthusiasm like a small admission fee. -- Kim Hubbard --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-02.diff" Content-Transfer-Encoding: quoted-printable --- draft-02-original.txt 2003-01-21 18:58:12.000000000 -0800 +++ draft-02.txt 2003-01-21 19:48:34.000000000 -0800 @@ -1202,7 +1202,7 @@ + 2xx: Success - The action was successfully received, understood, and accepted =20 - + 3xx: Redirection - Further action must be taken in order to com- + + 3rr: Redirection - Further action must be taken in order to com- plete the request =20 + 4xx: Client Error - The request contains bad syntax or cannot be @@ -2417,13 +2417,23 @@ =20 10.10 REDIRECT =20 - A redirect request informs the client that it MUST connect to another | - server location. REDIRECT SHALL only be sent to the client who cur- | - rently has a session at the server. The REDIRECT request MAY contain | - the header Location, which indicates that the client should issue | - requests for that URL. If the Location URL only contains a host | - address the client shall connect to the given host, while using the | - path from the URL on the current server. | + A redirect request informs the client that it MUST connect to another + server location. The REDIRECT request MAY contain the header Location, + which indicates that the client should issue requests for that URL. If + the Location URL only contains a host address the client shall connect = to + the given host, while using the path from the URL on the current server. + + If a REDIRECT request contains a Session header, it is end-to-end and + applies only to the given session. If there are proxies in the request + chain, they SHOULD NOT disconnect the control channel unless there are + no remaining sessions. + + If a REDIRECT request does not contain a Session header, it is next-hop + and applies to the control connection. The Location header SHOULD only + contain a host address. If there are proxies in the request chain, they + SHOULD disconnect the control channel, reconnect to the given host + address, and pass the request to each applicable client (typically those + clients with an active session or unanswered request from that server). =20 The redirect request MAY contain the header Range, which indicates | when the redirection takes effect. If the Range contains a time=3D = | @@ -2436,11 +2446,6 @@ time. The range value MUST be a single value in the open ended form, | e.g. npt=3D59-. = | =20 - If a Session header is included in the REDIRECT request the client | - MUST redirect the indicated session. If no Session header is included | - the client MUST redirect all sessions that it have on the server | - sending the request. | - If the client wants to continue to send or receive media for this | resource, the client MUST issue a TEARDOWN request for the current | session. A new session must be established with the designated host. | @@ -2647,7 +2652,11 @@ processes on the server may be consuming storage space simultane- ously, a client should take this only as an estimate. =20 -11.3 Redirection 3xx +11.3 Redirection 3rr + + The notation "3rr" indicates response codes from 300 to 399 inclusive + which are meant for redirection. The response code 304 is excluded + from this set, as it is not used for redirection. =20 See [H10.3] for definition of status code 300 to 305. However com- | ments are given for some to how they apply to RTSP. Further a couple | @@ -2679,6 +2688,24 @@ =20 11.3.5 304 Not Modified | =20 + If the client has performed a conditional DESCRIBE or SETUP (see 12.23) + and the requested resource has not been modified, the server SHOULD send + a 304 response. This response MUST NOT contain a message-body. + + The response MUST include the following header fields: + + - Date + - ETag and/or Content-Location, if the header would have been sent in + a 200 response to the same request. + - Expires, Cache-Control, and/or Vary, if the field-value might + differ from that sent in any previous response for the same variant. + + This response is independent for the DESCRIBE and SETUP requests. That + is, a 304 response to DESCRIBE does NOT imply that the resource content + is unchanged and a 304 response to SETUP does NOT imply that the resour= ce + description is unchanged. The ETag and If-Match headers may be used to + link the DESCRIBE and SETUP in this manner. + 11.3.6 305 Use Proxy | =20 See [H10.3.6]. | @@ -3011,7 +3038,7 @@ If-Match R r - - o - - - If-Modified-Since R r o - o - - - Last-Modified r r o - - - - - - Location 3xx o - o - - - + Location 3rr o - o - - - Proxy-Authenticate 407 amr m m m m m m Proxy-Require R ar o o o o o o Public r admr - m* - - - - @@ -3028,7 +3055,7 @@ Internet Draft RTSP November 01, 2002 =20 =20 - Retry-After 3xx,503 o o o - - - + Retry-After 3rr,503 o o o - - - RTP-Info r - - o m - - Scale - - - o - - Session R - o o m m m @@ -3125,7 +3152,7 @@ Range R - - - - o - Referer R o o o o o - Require R o o o o o o - Retry-After 3xx,503 o o - - - - + Retry-After 3rr,503 o o - - - - Scale - - - o - - Session R o o m m o m Session r c c m m o m @@ -5830,8 +5857,9 @@ =20 type of error occur the appropriate response code MUST be sent. If | the response code is a 4xx the session state is unchanged. A response | - code of 3xx will result in that the session is ended and its state is | - changed to Init. However there exist restrictions to when a 3xx | + code of 3rr will result in that the session is ended and its state is | + changed to Init. A response code of 304 results in no state change. + However there exist restrictions to when a 3xx | response may be used. A 5xx response SHALL not result in any change | of the session state, except if the error is not possible to recover | from. A unrecoverable error SHALL result the ending of the session. | @@ -5855,7 +5883,7 @@ =20 Event Prerequisite Response ----------------------------------------------------------------- - DESCRIBE Needs REDIRECT 3xx Redirect + DESCRIBE Needs REDIRECT 3rr Redirect DESCRIBE 200, Session description OPTIONS Session ID 200, Reset session timeout timer OPTIONS 200 @@ -5888,20 +5916,20 @@ Action Requisite New State Response ------------------------------------------------- SETUP Ready NRM=3D1, RP=3D0.0 - SETUP Needs Redirect Init 3xx Redirect + SETUP Needs Redirect Init 3rr Redirect =20 =20 Table 7: State: Init =20 state variables are also set by a correct request. This table also | shows that a correct SETUP can in some cases be redirected to another | - URL and/or server by a 3xx response. | + URL and/or server by a 3rr response. | =20 =20 Action Requisite New State Response ---------------------------------------------------------- SETUP Ready NRM=3D1,RP=3D0.0 - SETUP Needs Redirect Init 3xx + SETUP Needs Redirect Init 3rr TEARDOWN URL=3D* Init No session hdr. Timeout Init S->C:REDIRECT Range hdr Ready-nm Set RedP @@ -7187,7 +7215,7 @@ 11.1.1 100 Continue . . . . . . . . . . . . . . . . . . . . . . 47 11.2 Success 2xx . . . . . . . . . . . . . . . . . . . . . . . 48 11.2.1 250 Low on Storage Space . . . . . . . . . . . . . . . . 48 -11.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 48 +11.3 Redirection 3rr . . . . . . . . . . . . . . . . . . . . . 48 11.3.1 TBW . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . 48 11.3.3 302 Found . . . . . . . . . . . . . . . . . . . . . . . . 48 --xHFwDpU9dbj6ez1V-- --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+LioHqznSmcYu2m8RAtNLAJwOM2lhA7SaLafWfeo1b77RDpehLwCeL/U0 cMLT9IOfKOT7ws51stxh09I= =1Uwb -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 22 02:59:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18428 for ; Wed, 22 Jan 2003 02:59:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M8Hth01377 for mmusic-archive@odin.ietf.org; Wed, 22 Jan 2003 03:17:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8HtJ01374 for ; Wed, 22 Jan 2003 03:17:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18419 for ; Wed, 22 Jan 2003 02:59:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8HOJ01360; Wed, 22 Jan 2003 03:17:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8GwJ01331 for ; Wed, 22 Jan 2003 03:16:58 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18399 for ; Wed, 22 Jan 2003 02:58:31 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0M81vAv014641; Wed, 22 Jan 2003 09:01:57 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGN3LLLT; Wed, 22 Jan 2003 09:01:57 +0100 Message-ID: <3E2E4FEF.9090505@era.ericsson.se> Date: Wed, 22 Jan 2003 09:01:51 +0100 X-Sybari-Trust: a23e4ab4 9ffcebbb cd1bde24 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Perfetto CC: mmusic@ietf.org Subject: Re: [MMUSIC] Pipelining RTSP SETUP References: <30A6344AEBFC85429C30FF6C9C501CD1184FD3@bays02.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 Josh, See comments below: Josh Perfetto wrote: >Hello All, > >As I read RFC2326, in the typical DESCRIBE followed by multiple SETUPs, the server will first assign the RTSP session ID in response to the first SETUP. The player is supposed to include this session ID in all subsequent requests. However, this seems to preclude the possibility of pipelining a second SETUP request with the first one, as the session ID for the second SETUP wouldn't be known at the time it is sent. Is this correct? > Yes, you are correct. The first SETUP can't be pipelined with any subsequent SETUP. Also a PLAY request can't be sent until all outstanding SETUP request has been responded to. > >If it is, I would think it is a significant shortcoming, as pipelining is essential when streaming over high-latency wireless networks. Is this something that could be looked at in 2326bis? > I agree that it results in long setup delays. You are welcome to come in with proposals that would improve the setup phase. However remember that any changes needs to be backwards compatible towards a RFC 2326 client. If that can't be achieved, I think such a improvement must be done in the context of a protocol extension. > >RFC2326 does say that the server doesn't need to generate session identifiers if it has another means of identifying requests, but the player wouldn't know this until it receives the first SETUP response. > > I can't remember that text, nor find it in the RFC. Please point out the section where it is written. It is of course possible to use something else to identify sessions. However today the only standardized solution is the session ID. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 22 03:12:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18724 for ; Wed, 22 Jan 2003 03:12:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M8UU601947 for mmusic-archive@odin.ietf.org; Wed, 22 Jan 2003 03:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8UUJ01944 for ; Wed, 22 Jan 2003 03:30:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18678 for ; Wed, 22 Jan 2003 03:12:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8U4J01934; Wed, 22 Jan 2003 03:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8TVJ01900 for ; Wed, 22 Jan 2003 03:29:31 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18651 for ; Wed, 22 Jan 2003 03:11:01 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0M8ERAv017778; Wed, 22 Jan 2003 09:14:27 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DL6H17XT; Wed, 22 Jan 2003 09:14:20 +0100 Message-ID: <3E2E52DA.3070400@era.ericsson.se> Date: Wed, 22 Jan 2003 09:14:18 +0100 X-Sybari-Trust: 93fd8ea5 9ffcebbb cd1bde24 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rfc2326bis-02.txt References: <72263E8E8622D611975C0002B32C19D84A7724@MISTY> 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 Thomas, Thomas Zeng wrote: >Magnus: > >I finally have found some time to respond to your email from Dec 16., albeit >briefly: > >1. I have logged a bug (672160) against item 7 below. > > I think that RTCP reporting from client to server shall be supported as default even on a interleaved TCP channel, so this needs to be clarified. >2. There was only one typo re item 14 below (and you said you found it). > > Ok. >3. Regarding item 17 below (about Server sending TEARDOWN to Client >and also optionally END_OF_STREAM), are you in favor of our proposals >(meaning >allowing TEARDOWN on S->C and also add END_OF_STREAM? > > I think we should do our best to keep a consistent usage of the methods and also avoid multiple ways of doing the same. In this case I think using REDIRECT would be the preferred way, although an address is missing to where to redirect to. This seems just to be a special case of REDIRECT that needs to be explained. Regarding END_OF_STREAM, I think such a protocol extension can be added and also be quite useful. I would envisage a that it would simple be sent to report the last packet in a stream for the current playing context. Similar to what RTP-Info does at stream start. If you would like such functionality please write a draft on it that works as an extension to RTSP. >We will send you more comments/additions once we have come up with draft >text for other issues (e.g., items 1 and 18 below). > >See you tomorrow on the telecom. > > Good, Best Regards Magnus >Regards, >thomas >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] >Sent: Monday, December 16, 2002 7:30 AM >To: Thomas Zeng >Cc: mmusic@ietf.org >Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rfc2326bis-02.txt > > >Hi Thomas, > >I will try to respond to your comments. I hope that people manage to >read this very long mail. If responding please trim away all unnecessary >text. > >Thomas Zeng wrote: > > > >>PacketVideo has the following collective comments: >> >>1. Section 10, method Definitions, in the table, it indicates in the >> >> >Client > > >>Req column that OPTIONS is Required for Send - this doesn't make sense to >> >> >me > > >>- what does it mean that the client is required to send OPTIONS? When? >> >> >> >> > >The requirements are related to implementation not usage. In fact I >would believe that sending of OPTIONS on the client side may only be >Recommended. >=> So this section should be fixed to clarify the that the requirements >are regarding implementation. It should also be consider to change >OPTIONS, Sd to recommended. > > > >>2. How can they not bump the Version number (say from 1.0 to 1.1) when >> >> >they > > >>are allowing non-interoperable changes from 2326? For example, from >> >> >section > > >>10.5 - PLAY: >> >>" After playing the desired range, the presentation is NOT automati- | >> cally paused, media deliver simple stops. A PAUSE request MUST be | >> issued before another PLAY request can issued. Note: This is one | >> change resulting in a non-operability with RFC 2326 implementations. | >> A client not issuing a PAUSE request before a new PLAY will be stuck | >> in PLAYING state. A client desiring to play the media from the begin- | >> ning MUST send a PLAY request with a Range header pointing at the | >> beginning, e.g. npt=0-. " >> >>What's the point of being "stuck" in playing state? If *EVERY* client has >>issue the PAUSE request >>before being able to do something useful, why not just assume they all did >>and stick with the >>current behavior of returning to the READY state? What is the behavior if >>the client issues a PLAY >>before a PAUSE? >> >> >> >> >> >The reason for this change is that it removes all automatic state >changes that does not result in session deletion. Having automatic state >changes is a big problem for the state consistency between client and >server. One existing problem with the old state machine is that a client >could send a PLAY request and not know what the result of it would be. >The request could either be queued or played out directly. This may be >acceptable if one would only be interested in basic on-demand play >functionality. However to have this protocol be robust to extensions >this change is needed. One needs to know what behavior one shall expect >when sending a request. > >Regarding the interoperability issue. This is currently the most evident >issue. However I don't regards it as extremely problematic. A client has >at least managed to play the stream once. There are other issues that >exist when we know that different implementations are not compatible. >One example is the behavior at the end of the stream. Some server sets >the current play out point to 0.0 when reaching the end of a media clip >will others do not. A client will not be able to be interoperable with >both servers. In this case however a simple fix exist and that is to >always include a range header. However a client not knowing this will >not be interoperable. > >So far this interoperability problem has been regarded as minor compared >to the need to fix the underlying problem. A new version number would >not fix the underlying problem which is that RTSP 1.0 has major >interoperability problems due to specification shortcomings. My working >hypothesis is that we will try to fix RTSP 1.0 so that it works. Any >change resulting in interoperability problems need to be documented as I >have done in this case. (We should perhaps gather them in a special >chapter). Then if the end we can't fix the protocol without totally >breaking the interoperability then we will have to accept a new version >number. We will not fix this protocol without hurting some of the >deployed implementations at least to some extent. My goal is to let >things be minor. > >In the updated version the correct reponse to a PLAY request in playing >state is: "455 Method Not Valid in This State". > > > >>3. One of the big gaps in the previous spec was how to use Basic and Digest >>Authentication in the context of RTSP. This draft does not give any more >>clarification. Do you send the authentication headers in all requests? >>Only until a valid session ID has been established? Just the DESCRIBE? In >>all SETUPs? Details like these need to be worked out and an example >>wouldn't hurt either. >> >> >> >> > >Yes, I agree that we should have security feature like authentication in >the core spec or an extension spec of RTSP. The big problem is that this >is basically at the same maturity level as specifying some new >functionality. So we need someone to start writing on this. If you are >interested in this you are very welcome to volunteer to write this. > > > >>4. In section 3.3, "Session identifiers are opaque strings of arbitrary >>length. Linear white space must be URL-escaped." Why allow spaces? And >> >> >URL > > >>escaping results in the '%' characters. The BNF they use to detail the >>session ID does NOT allow for spaces or the '%' character: >> >> session-id = 8*( ALPHA / DIGIT / safe ) >> >> ALPHA = UPALPHA / LOALPHA >> UPALPHA = >> LOALPHA = >> DIGIT = >> safe = "$" / "-" / "_" / "." / "+" >> >> >> >> > >A simple type I would say, the sentence is out of date and not in line >with the BNF definition. I resolve this by checking in a version with >out the sentence "Linear white space must be URL-escaped." I guess that >resolves this issue. > > > >>5. Can the open-ended start time be used for live presentations? For >>example, can "-30" mean play from now til 30 seconds form now? How about >>"now-30" or "now-now+30" to indicate streaming from the current point in >> >> >the > > >>live stream, but only streaming for 30 seconds. >> >> >> >> >Yes, they can be. The BNF allows for example the following ranges >clock=-20021216T164500Z, or npt=now-00:30:00. However the now-now+30 is >not valid. In the case of live sessions the most reasonable seems to be >to use the UTC format (clock) to specify a wall clock time when the >session ends. In that case a simple start time open ended is sufficient. > > > >>6. Need to resolve the problem of supporting the REDIRECT request and >>non-persistent connections. If you are using non-persistent connections, >>there is no way for a server to send a REDIRECT request to the client. >> >> >> >> > >I think this is as resolved as it ever will be. The client is strongly >recommended to have persistent connections. If not keeping the >connection open and the server would like to do redirect/announce etc. >the client, the server will simply let the request fail. In this case >this failure will result in that the sever ends the session when it has >to. This is the incentive for a client to keep a connection alive. Of >course this must be clearly documented. > > > >>7. In the section on RTP interleaved over the RTSP channel, there was no >>mention of the client sending RTCP RR back to the server. Are these still >>present? They did specify the sender reports from the server to client, >> >> >but > > >>that's it. >> >> >> > >This is a new bug, would you please register it at source forge: >http://rtspspec.sourceforge.net. >Please log in before registering a bug. > >However my opinion is that this channel should allow for sending RTCP >traffic also to the server. It seems simple to assume symmetry of the >identifiers. Please give your view of how this is simplest and best solved. > > > >>8. The description of the redirection responses needs work. It's not >>clear how they see the use of load balancing, etc. >> >> >> >> > >Please provide more details of what you think is missing. In most case I >assume that there is no need for the client to know the reason behind a >redirect as long as the correct behavior is indicated. > > > >>9. Table 3, page 51: Why are DESCRIBE, ANNOUNCE, and PING supported for a >>request on the media URL? I understand them to work on the presentation >>URL, but I don't think that they are appropriate to work on the media-level >>control URLs. >> >> >> >> > >In cases you don't do media aggregation the use of ANNOUNCE and PING are >motivated. Of course, you can in that case see it as the presentation >URL and media-url is the same. The use of DESCRIBE I can't motivate >other way that the difference between a presentation and a media URL are >not always clear. One example of usage could be a non aggregated session >that becomes redirected. In that case the media should not be directed >to the whole presentation rather the media. If the client checks the >media description to verify that it is in fact the same media and not a >another configuration it is motivated. > > > >>10. Section 12.18, why MUST the server send the "Date" header? And what is >>the determining factor to say a sending host has a clock? How could a >>server send RTP data without a clock? >> >> >> >> > >The "Date" header MUST be sent with any request or response containing a >body. Which means that for a server only the DESCRIBE response really >MUST contain a Date header. However it good to include it also in other >request for logging, debugging purposes. For the messages with body it >is for proxy reasons so that one can judge how old the content in the >proxy is. In the case of Date it is evident that the requirement is to >have a wall time clock, i.e. capable of producing time in GMT/UTC. > > > >>11. Section 12.19, page 63, Why can't they define a separate string value >> >> >to > > >>indicate that the description "Never Expires" instead of using a date/time >>that is one year in the future? >> >> >> > >There seem to be a very good reason for this. Can you really guarantee >that any thing will work and accessible for all time in the future. By >specifying the expire time one year into the future you give it a very >long life time but still bounded. > > > >>12. Section 12.29, must a server understand the "time" parameter in the >>range header in a request? And what error should it respond if it doesn't >>support the time parameter? There is no way to inform the client that it >>does/doesn't support this parameter. >> >> >> >> > >Looking at the specification, it seems that it is assumed to be a part >of the core functionality of the protocol that is required to be supported. > > > >>13. Section 12.38, the first line of the "Supported" example looks garbled. >> >> >> >> > >Yes, It certainly is > > > >>14. The introduction of the "client_rtcp_port" and "server_rtcp_port" >> >> >REALLY > > >>breaks backwards compatibility. The RTSP version number MUST be bumped! >>And there is a typo in that section/example where "client_rtcp_port" is >> >> >used > > >>twice - one in place of the server port. >> >> >> >No, it does not. Not with the described mechanism of resolving this. By >requiring a client to check if the sever supports the new parameters >interoperability can be ensured. So the use of this parameter requires >that the client to include the supported header in a request prior to >the SETUP to determine if feature tag "play.basic" is supported by the >server. If support is signaled then the client MAY include the >client_rtcp_port. If a server receives a SETUP request with >client_rtcp_port parameter it shall include its own RTCP port in >server_rtcp_port. > >I find one typo, the item name was client in the description. What was >the other one? > >One big problem with the transport header is that it doesn't support >extensions. This I think must be corrected. If extensions are required >to be understood feature tags in the Require header should be used. > > > >>15. In section 9.3 it states that the server MUST NOT close the connection >>directly after responding to the TEARDOWN request for the whole session. >>Are they trying to state >>that the server should wait to ensure that the response arrives at the >>client? I don't understand >>how this is case is different than the handling of any other RTSP response. >> >> >> >> > >TEARDOWN is not different from other request. It is only a clarification >to some implementations that do close the TCP connection as a response >to the TEARDOWN request. It should be the client that initiate closing >of the TCP connection. However the server may close the TCP connection >after a time-out interval without traffic. > > > >>16. Section 9.3 also states "A persistent connection MAY be used for all >>transactions between the server and client, including messages to >>multiple RTSP sessions." It would be a good idea to point out the server >>MAY impose limits on the number of simulataneous sessions a client is >>allowed to create/control. >> >> >> >> > >I think I understand the motivation behind your request. However I don't >think such a restriction is possible in the current look of the RTSP >standard. The scenario when such a restriction is hard to enforce is: A >large number of clients are sitting behind the same proxy. The proxy >multiplex all the clients it handles into a single TCP connection. How >does the server distinguish that it is talking with many different >clients and not a single one behind the proxy? > > > >>17. In table 2 of section 10, the TEARDOWN message should also be required >>to be handled in the >>Server->Client direction. There are cases where the server needs to drop >>the client >>(e.g., load shedding) and it is better if it can inform the client that >> >> >this > > >>is happening. A few IETFs ago someone was proposing "END_OF_STREAM" as a >>new RTSP request from Server to client. But TEARDOWN from server to client >>could be more appropriate. >> >> >> > >Okay, TEARDOWN in S->C may be motivated when a server needs to get rid >of all its clients and has no alternative server to REDIRECT to. However >to make this useful compared to just deleting the sessions and refusing >any connections a channel for extra information about the reason is >needed. This could be included in the body but also SIPs warning may be >appropriate. > >However the END_OF_STREAM had other purposes as it was to indicate that >all media of the current request had been sent. > > > >>18. Section 12.10: The section on the server closing the connection should >>be softened: >> >>12.10 Connection >> >> See [H14.10]. The use of the connection option "close" in RTSP mes- | >> sages SHOULD be limited to error messages when the server is unable | >> to recover and therefore see it necessary to close the connection. | >> The reason is that the client shall have the choice of continue using | >> a connection indefinitely as long as it sends valid messages. >> >>The standard shouldn't mandate server policies on the use of resources. >> >> >The > > >>server should have the option >>of closing connections (perhaps without dropping the RTSP session) if >>demanded by resource constraints or >>usage policies. >> >> >> >> > >This text is added to clarify that the usage of close that is evident in >some implementations today are not correct. In my view a TCP connection >should not be closed from server end unless its inactive for at least >one RTSP time-out period. It may also be kept open for longer as the >RTSP session is kept alive with RTCP messages. However I can agree that >another formulation of this may be more appropriate. I see that there >exist problems like DOS attacks by setting up many TCP connections, etc. >that would require the server to start closing connections. Please >propose how you would like it to be written. > >Regards > >Magnus Westerlund > >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 22 11:52:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00739 for ; Wed, 22 Jan 2003 11:52:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MHAfs04674 for mmusic-archive@odin.ietf.org; Wed, 22 Jan 2003 12:10:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHAfJ04671 for ; Wed, 22 Jan 2003 12:10:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00727 for ; Wed, 22 Jan 2003 11:52:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHANJ04650; Wed, 22 Jan 2003 12:10:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MH9pJ04609 for ; Wed, 22 Jan 2003 12:09:51 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00665 for ; Wed, 22 Jan 2003 11:51:14 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h0MGsdI35935; Wed, 22 Jan 2003 08:54:39 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 08:54:39 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A772A@MISTY> From: Thomas Zeng To: "'Tom Marshall'" , mmusic@ietf.org Subject: RE: [MMUSIC] Proposed update to draft-02 Date: Wed, 22 Jan 2003 08:54:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) 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: , Tom: There is a proposal from Magnus to use "REDIRECT" without location header (i.e., not even a host) to act like a TEARDOWN from Server to Client. I wonder whether it affects your update should this proposal be accepted. thanks, thomas zeng -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Tuesday, January 21, 2003 9:20 PM To: mmusic@ietf.org Subject: [MMUSIC] Proposed update to draft-02 The attached diff addresses the issues that Magnus and I have been discussing in the past week. Comments would be appreciated. I will be attending the telecon tomorrow. -- Nothing will dispel enthusiasm like a small admission fee. -- Kim Hubbard _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 22 11:57:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00950 for ; Wed, 22 Jan 2003 11:57:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MHG0s04989 for mmusic-archive@odin.ietf.org; Wed, 22 Jan 2003 12:16:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHG0J04986 for ; Wed, 22 Jan 2003 12:16:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00893 for ; Wed, 22 Jan 2003 11:57:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHFEJ04932; Wed, 22 Jan 2003 12:15:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHEGJ04881 for ; Wed, 22 Jan 2003 12:14:16 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00842 for ; Wed, 22 Jan 2003 11:55:38 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0MGx4Av029946; Wed, 22 Jan 2003 17:59:04 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGN3PWXD; Wed, 22 Jan 2003 17:59:03 +0100 Message-ID: <3E2ECDD3.1030509@era.ericsson.se> Date: Wed, 22 Jan 2003 17:58:59 +0100 X-Sybari-Trust: 4fa132fb 9ffcebbb 8f3ed959 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: "'Tom Marshall'" , mmusic@ietf.org Subject: Re: [MMUSIC] Proposed update to draft-02 References: <72263E8E8622D611975C0002B32C19D84A772A@MISTY> 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 Thomas and Tom, I did not say without a location header. However the location header can be empty if you are lacking a host to redirect to. Regards Magnus Thomas Zeng wrote: >Tom: > >There is a proposal from Magnus to use "REDIRECT" without location header >(i.e., not even a host) to act like a TEARDOWN from Server to Client. I >wonder whether it affects your update >should this proposal be accepted. > >thanks, >thomas zeng > >-----Original Message----- >From: Tom Marshall [mailto:tmarshall@real.com] >Sent: Tuesday, January 21, 2003 9:20 PM >To: mmusic@ietf.org >Subject: [MMUSIC] Proposed update to draft-02 > > >The attached diff addresses the issues that Magnus and I have been >discussing in the past week. Comments would be appreciated. > >I will be attending the telecon tomorrow. > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 22 15:20:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05964 for ; Wed, 22 Jan 2003 15:20:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MKcgv17764 for mmusic-archive@odin.ietf.org; Wed, 22 Jan 2003 15:38:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKcgJ17761 for ; Wed, 22 Jan 2003 15:38:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05931 for ; Wed, 22 Jan 2003 15:20:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKcOJ17740; Wed, 22 Jan 2003 15:38:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKbYJ17723 for ; Wed, 22 Jan 2003 15:37:34 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05884 for ; Wed, 22 Jan 2003 15:18:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 22 Jan 2003 12:20:48 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Wed, 22 Jan 2003 12:20:47 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2/8.12.2) with ESMTP id h0MKGtKO002227 for ; Wed, 22 Jan 2003 12:16:55 -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 18bRIh-0001uJ-00 for ; Wed, 22 Jan 2003 12:16:43 -0800 Date: Wed, 22 Jan 2003 12:15:54 -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-Status: No, hits=-8.0 required=5.0 tests=KNOWN_MAILING_LIST,NO_REAL_NAME,RCVD_IN_BONDEDSENDER, SPAM_PHRASE_02_03 version=2.42 X-UIDL: ddb74585c606e4d84af658f5ba997297 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #71 - 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-672160 ] Describe a interleaved RTSP channel for client RR reports (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 21 Jan 2003 16:28:52 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports Bugs item #672160, was opened at 2003-01-22 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=672160&group_id=23194 Category: General Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Rob Lanphier (robla) Summary: Describe a interleaved RTSP channel for client RR reports Initial Comment: In the section on RTP interleaved over the RTSP channel (section 10.13), there was no mention of the client sending RTCP RR back to the server. Are these still present? They did specify the sender reports from the server to client, but that's it. The back channel is symmetric to the RTCP for server to send SRs and should be described as such (i.e. described in Transport headers). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=672160&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jan 27 14:12:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23242 for ; Mon, 27 Jan 2003 14:12:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RJXGq11030 for mmusic-archive@odin.ietf.org; Mon, 27 Jan 2003 14:33:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJXGJ11027 for ; Mon, 27 Jan 2003 14:33:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23234 for ; Mon, 27 Jan 2003 14:12:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJWfJ10971; Mon, 27 Jan 2003 14:32:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJVlJ10946 for ; Mon, 27 Jan 2003 14:31:47 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23158 for ; Mon, 27 Jan 2003 14:10:34 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h0RJE4r05839 for ; Mon, 27 Jan 2003 11:14:04 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 11:14:04 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7746@MISTY> From: Thomas Zeng To: "'mmusic@ietf.org'" Date: Mon, 27 Jan 2003 11:14:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Subject: [MMUSIC] Minutes from RTSP telecon 22 of january 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: , Attendees of RTSP telecon 22 of january, 2003 Andrea Basso Tom Marshall Jorg Ott Magnus Westerlund Adlers Klemets Thomas Zeng Agenda Bashing: Magnus: Please everyone take a look at A proposal for RTP interleaved in TCP: draft-lazzaro-avt-rtp-framing-contrans-00.txt. It is available from the IETF repository at: http://www.ietf.org/internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-0 0.txt Meeting notes: - Follow up on last telecon * 304 and REDIRECT "*" text proposal. (Tom's proposal -- see corresponding email sent by Tom Marshall on Jan 21 entiled [MMUSIC] Proposed update to draft-02. Mag(nus): The paragraph on redirect out to proxy and clients is back wards? Tom: I don't understand... Mag: I mean the order of control channel teardown... Tom: Why order is important? why a particular order? Mag: Perhaps my misunderstanding ? Tom: Proxy can answer requests on behalf of the clients, therefore order (of answering vs taking done the RTSP session) is no longer important. Resolution: add a session that proxy should answer redirect request to the server on behalf of its down stream clients - 3rr codes: Thomas: What is 3rr useful for? Mag: If a client closed TCP after setup, then connect again to send play request but Server wanted to REDIRECT, then Server would use 3rr responses. Mag: I have more ecommments: have you (Tom) considered header usability? eg. Location header for 3rr responses ... Should update table 4 and 5 such that Location header should be allowed for all methods. (Action item: Tom to add wording to allow 3rr for other method responses). Thomas: I'd like to bring up the proposal from Magnus (or Mag in short) to use REDIRECT as a way to say "TEARDOWN" from S->C. Tom: I don't like using REDIECT to replace TEARDOWN from S->C. I prefer END_OF_STREAM in this case to close a session. Jorg: I agree with Tom. Compared to TEARDOWN from S->C, REDIRECT means something else. Mag: We can say REDIRECT with empty Location header to mean redirecting to cyber space. Jorg: It still is not convincing. Tom: A "*" location maybe? Mag: Perhaps END_OF_STREAM (or END_OF_SESSION) is more appropriate? Adrea: what about backwards compability? in that regard REDIRECT is better (than END_OF_STREAM/SESSION)... Mag: I don't know whether it belongs to RTSP (i.e., RTCP BYE is better to signal end of live session)... Tom: I ahve an idea. Suppose server live feed goes away, then server redirect its clients to itself. Then client reconnect; Magnus: Yah, you can actually redirect to info page Resolution: use redirect to tell the clients to teardown and reconnect to the same server. Then tell the clients that service is not available via perhaps a info page. That way we have good backwards compatibility and no need for TEARDOWN S->C nor END_OF_STREAM. Mag: Let's go on to extension mechanism - Extension mechanism Mag: basic idea is to use feature tags and require/Proxy-requre headers as well as the Support/Unsupported header from SIP. End points will list all feature tags it supports in a request and the other side includes all its tags in its response Andrea: it's not clear who will be the master (e.g., 324-M one guy takes the role of the master) Mag; it's up to the requester Andrea: in the case of streaming you are right it is the client to decide Mag: it applies to two way as well Andrea: what about two way? a capability exchange must have a master Mag : but we are talking about server capabilit not media capabilty Jorg: Clarifying 324M ... Feature tags are independent of master slave Feature tags only indicate what's available , independent of hieraarchical relationships (master / slave). Andrea: for streaming scenario it is clear to me. Mag: This is basically the idea if you require a feature put in Require header. If server does not have the capability it responds with error (code 551) with an Unsupported header containing the feature tags in question that are not supported. The feature tag representing the updated specification with basic playback functionality is necessary due to the few non-backwards compatibility issues we have. To be able to use the following mechanism in RTSP both end-points need to support "play.basic": -- IPv6 addresses in source and destination parameters in transport header -- Use of "RTCP_client_port" and "rtcp_server_port" transport header parameters. This mechanism makes it possible to evolve the RTSP standards (e.g. possible future IPV6 or RTCP back channel (?) extensions). Thomas : Makes sense since SIP had a success with it. Mag: We have the options method which is a perfrect place to include Supported header. * Feature tags - play.basic Mag: The tag, play.basic signals the min implementation of the new spec. There are also play.speed and play.scale tags. Thomas: let's require Range in PLAY response in play.basic (i.e. min implementation) if there is no objection. Mag: the draft alreadys requires Range header in all Play responses for on-demand media. Thomas: Let's do the same with Live. Resolution: Let's propose to require Range in Play responses (for live, use range "now- ") to the mailing list. Magnus: A comment, for live streams if possible it is better to give a real clock if possible. I think UTC times can be useful also in live streams. - registration Jorg: There is a big issue with registration, which should be centralized by IETF to reg all feature tags. For event packages may not necessaryly be regi by IETF. We have seen too many attmpts to abuse it. Keep strict control here is to ensure people don't do strange things. For RTSP we want same security so RTSP don't open up too many doors. We should probably start with strict registration, but we are aware of propriatary tags in the existing servers. SIP says don't mess up existing registered feature tags if you have propriatary features. Ensure we don't get collisions in the registration process. Should have an open documentation for that. It's up to group to decide whether we have allowance to experimentations, since people don't want to wait until it's all finished. What are people's thoughts whether to make it very strict or very open? Mag: Judging by 3gpp experience, 3 months turn around is too long. I'd rather see it faily open registration Jorg: Just not say anything about how to use feature tags? not a good idea. Mag: first come first serve is an option. Conclustion: More thougts are required. Please look at the existing registration route in the drafts as well as the 7 tags. Identify potential parties who will likely send requests to register tags (e.g. 3gpp and ISMA). Jorg: My goal is to avoid too many profiles of RTSP -- we have had enough incompabilites b/w SIP in general and 3gpp SIP. Neither side should be relying on anything. Mag: I have been talking to 3gpp. RTSP so far hasn't suffered much in terms of "profiling RTSP". Jorg: there is going to be a meeting b/w 3gpp and IETF next week. I'll speak to Allison on this issue. (Action item: Jorg to post a feedback after next week's meeting.) * Require header * Proxy-require header - Shall it really require server to support these? See SIP, RFC 3261 which uses Proxy-Require only for proxies. Tom: all Proxy headers are hop by hop in HTTP 1.1 Magus: it makes sense to align with SIP than HTTP at this moment. Magnus: can you see Proxy only feature tags? e.g. cache feature tags for RTSP that are only for proxies? Current servers are not to honor Proxy-require headers. Jorg: if you want tag be supported by both proxy and servers then use both Require and Proxy-Require. Mag: Do you Tom support Proxy-require? Tom: yes, but there is no specific tags. in previous server, Proxy-require not honored by servers. It's changed in recent release. Conclusion: Propose to MMUSIC that Proxy-require should not be honored by servers, only by Proxys. Likewise, Require is only for servers, not Proxy. This would be aligning with SIP. Mag: Tom's and my servers both honor Proxy-require headers. So there is backwards compatibility issue, but minor engouh. - Next meeting Magnus: when? also think about editorship. Let's say two weeks. Thomas : any objectisn to two weeks? Two weeks it is. --------------------------------- Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ 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 mailnull@www1.ietf.org Mon Jan 27 18:36:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00900 for ; Mon, 27 Jan 2003 18:36:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RNv0U27138 for mmusic-archive@odin.ietf.org; Mon, 27 Jan 2003 18:57:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNv0J27135 for ; Mon, 27 Jan 2003 18:57:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00896 for ; Mon, 27 Jan 2003 18:35:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNuOJ27107; Mon, 27 Jan 2003 18:56:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNtmJ27081 for ; Mon, 27 Jan 2003 18:55:48 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00867 for ; Mon, 27 Jan 2003 18:34:36 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id PAA01359 for mmusic@ietf.org; Mon, 27 Jan 2003 15:38:06 -0800 Date: Mon, 27 Jan 2003 15:38:06 -0800 From: John Lazzaro Message-Id: <200301272338.PAA01359@snap.CS.Berkeley.EDU> To: mmusic@ietf.org Subject: [MMUSIC] draft-lazzaro-avt-rtp-framing-contrans-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: , Hi everyone, Saw Magnus's pointer to the contrans I-D: http://www.ietf.org/internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-00.txt Thought I should give a quick background for those who aren't subscribed to AVT. There was a need for a short I-D documenting the legacy TCP framing for RTP (two-octet length field preceding the packet), and Section 2 of the I-D above does this. The remaining sections of the document define ways to use this framing with draft-ietf-mmusic-sdp-comedia-04.txt (by defining fmt tokens for use with TCP and TLS), and with RTSP (by linking the framing to the use of the "RTP/AVP/TCP" value of "transport-spec" without the use of interleaved). It seemed easiest to clump these three topics together for the first draft of the I-D ... although its unclear whether its better to keep the three topics in one I-D or split them apart ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jan 29 08:45:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19186 for ; Wed, 29 Jan 2003 08:45:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TE7Bk26796 for mmusic-archive@odin.ietf.org; Wed, 29 Jan 2003 09:07:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TE7BJ26793 for ; Wed, 29 Jan 2003 09:07:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19164 for ; Wed, 29 Jan 2003 08:45:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TE76J26636; Wed, 29 Jan 2003 09:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TDw2J26046 for ; Wed, 29 Jan 2003 08:58:02 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19064 for ; Wed, 29 Jan 2003 08:36:03 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h0TDdP031842; Wed, 29 Jan 2003 08:39:25 -0500 Message-Id: <5.1.1.6.0.20030128115955.03105110@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 29 Jan 2003 08:39:27 -0500 To: Jonathan Rosenberg From: David Yon Subject: Re: [MMUSIC] comedia-fix and the whole source address/port boondoggle Cc: mmusic@ietf.org In-Reply-To: <3E24C13C.7030803@dynamicsoft.com> References: <5.1.1.6.0.20030107090246.03445d08@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote: >Responses inline. > >David Yon wrote: >>comedia-fix again raises the argument against embedding the source >>address/port information in the SDP. That is something that I still feel >>strongly about, and work has progressed that makes use of it, although >>not as a fail-safe session correlation mechanism. We've found that it's >>useful as a DoS counter-measure, using the following design: >> - An intermediate proxy on our network acts as a STUN-like >> inverse-NAT translator to at least recover the likely address >> from where the media will originate, and rewrites the SDP >> if necessary. > >It is quite a mystery to me how such a thing could possibly work in a >causal fashion. The endpoint won't actually open any connections until >after the offer/answer exchange has completed. The opening of the TCP >connection is the thing which causes the NAT to assign a binding. So, the >binding is assigned after the o/a exchange, but your proxy needs to know >the binding before the exchange completes. So, I don't get it. It works on ranking rather than absolute correlation. You're correct about the NPAT port binding not being known ahead of time. However, most NPAT scenarios involve a single IP Address, so a media connection coming from that IP Address (regardless of source port) would be ranked higher than one that comes an unknown address. And let's not forget about connections that originate from dial-up accounts (which accounts for the vast majority of home access), where the IP Address and port are actually correct, in which case the ranking is 100% accurate. >> - Our gateways, when under load, sort the incoming connection >> pending queue based on source addresses that they expect >> to arrive. >>The idea is that when under DoS attack, connections sourced from >>uninvited addresses are not dealt with until the queue of invited >>addresses has been serviced. This is especially critical when the media >>is carried over TLS, and in our case we do not commence with the TLS >>handshake until either the connection has been correlated or until >>servicing the connection does not overload the gateway. The side-effect >>of a failed/incorrect inverse-NAT rewrite only occurs under heavy load, >>and is not fatal. But without the source address information, there is >>no way to implement such a scheme. > >Since, practically speaking, I would expect the majority of users to >connect to things from behind a NAT, this mechanism serves little purpose >to prevent DOS attacks. I don't understand why you would not use more >tried-and-true mechanisms, such as return routability, which validate a >source IP address by sending it a cookie, and getting this cookie back. >Such a mechanism actually works through NAT, and you can provide much more >than just service prioritiziation based on it. Again, the scheme as described works in the presence of NAT (despite assertions to the contrary), and allows the media to be 100% TLS without any out-of-spec "enhancements". >I still maintain that, given we are painfully aware of the trials and >tribulations of distributing source IP addresses in protocols, and given >the vast potential for misuse, and the potentially small (if not ZERO) >deployable benefits of this mechanism, I would like to see it removed. It >is one thing to include a mechanism that is useful in many cases, but >might not work in some (and then documenting such) as compared to a >mechanism that will most likely be misused, and whose real benefit is >small or zero. It is OPTIONAL in the spec, and the limitations clearly outlined. At least one implementation finds it useful. I don't know how to be more clear than that, and why it causes such heartburn. >We should keep this bit separate from much of the rest of the comedia-fix >stuff. I will comment on that separately (to a resolution I do think you >will be happy with). > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >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 mailnull@www1.ietf.org Wed Jan 29 08:46:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19226 for ; Wed, 29 Jan 2003 08:46:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TE7iI27184 for mmusic-archive@odin.ietf.org; Wed, 29 Jan 2003 09:07:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TE7iJ27181 for ; Wed, 29 Jan 2003 09:07:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19185 for ; Wed, 29 Jan 2003 08:45:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TE7AJ26755; Wed, 29 Jan 2003 09:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TDw6J26050 for ; Wed, 29 Jan 2003 08:58:06 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19067 for ; Wed, 29 Jan 2003 08:36:06 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h0TDdQ031845; Wed, 29 Jan 2003 08:39:26 -0500 Message-Id: <5.1.1.6.0.20030128121040.03130008@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 29 Jan 2003 08:36:56 -0500 To: Jonathan Rosenberg From: David Yon Subject: Re: [MMUSIC] comedia-fix-00 comments Cc: mmusic@ietf.org In-Reply-To: <3E24CE61.8020203@dynamicsoft.com> References: <5.1.1.6.0.20030103094038.00b37198@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 09:58 PM 1/14/2003, Jonathan Rosenberg wrote: >David, > >Ben, Paul and I discussed your comments extensively over the last week or >so. Our conclusion was that we will not use comedia for simple messaging >sessions. At a high level, the conclusion was that we were looking at >"message sessions over TCP" and that comedia was perhaps optimized for >"streaming media sessions over TCP". As such, many of our requirements >that were critical, or assumptions we could make (such as demux within a >single TCP connection) don't necessarily apply to streaming media over TCP. > >Now, I still think that much of what we proposed is valid. However, it is >no longer critical to get it changed. So, keep that in mind as you read my >responses below. The the meta-question is whether comedia-fix will continue to block comedia's progress. On one hand you imply above that it won't, but then again we have the rest of this email that argues that comedia is severely flawed. So, where are we going from here? >>lem at all, IMO), and the draft should be updated to reflect this. > >I conceded this point. You are correct that its not 1:1. > >I still believe that this will fundamentally make tcp-based streaming >media complicated for firewalls. It would be REALLY nice to allow an admin >to open the "streaming FOO port" and that would allow for all media >traffic of that type through. You are still going to need dynamic ports in >your proposal, which perpetuates the firewall problems. The use of dynamic >ports was (arguably) needed for UDP because there is no other >protocol-independent demux. However, that is NOT true for TCP, which has >the notion of multiple connections on a port. Thus, to me, any usage of >TCP should make use of this natural and well-understood property, rather >than perpetuating a (IMHO ultimately wrong) design choice for UDP [ranting >for a moment, given the huge problems we have encountered in deploying >voip, a large number of which are based on the usage of dynamic ports for >session demux, I think ultimately we should have chosen a well-known port >for RTP, and then used something like SSRC or CNAME to demux. But that is >another conversation.] I agree that fixed ports are desirable. Changing your endpoint ID from its current form to be something keyed from within the media protocol itself would go a long way towards this while alleviating my other concerns. >>3.2 No Connection Re-Use >>This references 3.1 and restates the incorrect scaling assumption. >>This scenario seems to be the only problem for which connection/session >>lifetime decoupling is presented as a solution. I cover this in more >>detail below, but the short answer is that any economy of design derived >>from this solution is offset by burdening other, more common scenarios >>with undesirable restrictions. > >Can you explain what you mean? Well, like I said, I explain what I mean below. :-) >>3.3 Security >>The Man-in-the-Middle attack can be mitigated by simply disallowing >>multiple connections to the advertised IP/port during the offer period. >>If more than one arrives, then the endpoint assumes an attack and does a >>session teardown. (yes, this requires updating the language in comedia >>to reflect this new scenario) > >That helps, but doesnt eliminate the problem. I can dos the other party, >preventing them from connecting to you. This came up during the >development of stun, which documents a similar attack. > >I admit this is not a crucial point, since if it truly bothers you, using >real media level security will fix it. A DoS is a very different animal than a security breach, and arguably an improvement in terms of vulnerability introduced by the protocol, since protecting against all forms of DoS is nearly impossible. Besides, comedia-fix didn't fix the security breach either, so I'm not sure what it is you're after. >>The firewall trust issue can be addressed by a chain of trust, can it >>not? I.e., presumably the firewall authenticates/trusts a SIP proxy >>which in turn authenticates/trusts each of the UA's. > >That would be the midcom approach, yes. Ok, so you agree that the original assertion in comedia-fix is not valid. >>The instruction to open/close pinholes is made by the SIP proxy to the >>firewall as a result of the message traffic the proxy is relaying, not by >>any sort of stateful packet inspection by the firewall. >>As for the "there's no ALG yet" argument for residential gateways: I >>submit yet again that without including the source address/port, comedia >>will preclude an ALG from ever being written. > >I think thats a good thing. > >ALGs are bad. Thats why midcom got started. We need to keep application >layer intelligence out of them, and either get protocols to work through >them without adding more to the mess (stun/turn), or even better, specify >well-defined behaviors for them that can be controlled through something >like nsis. But, all of that is far off. I think we understand each others' opposing points of view. Not clear to me that we need to discuss it further, and I think the topic at hand is best addressed via other points (like the other email thread we're having). >>The suggestion in comedia-fix (to use a header at the start of the >>connection) jumbles the protocol stack, and as such may cause some >>unintended consequences. > >Arguably, yes. Not the first time though. It is common to do this in many >protocols that are strongly recommended in IETF. > >>At the heart of the issue is "what is it that we are signaling >>here?". If we are signaling RTP/AVP over TCP, then we violate the spec >>with the initial ID transmission. > >THink of it like a windowing operation in an operating system. During the >times at which the RTP/AVP stack has the connection, its compliant. Its >just that it doesnt get the connection right away. This doesn't convince me. I still haven't seen precedent in SDP where the protocol, as described in SDP, was augmented by some other protocol not listed within the SDP. >>If we are signaling RTP/AVP over TLS, where does the ID transmission go, >>as part of the TLS stream or prior to the TLS handshake? In either case >>we end up with a stream that is neither (a) 100% RTP/AVP and/or (b) 100% TLS. > >Funny you should say this, since TLS is a good example of where common >practice is to mix protocol layers. > >The recommended practice these days is for protocols to NOT run their apps >over tls on a separate port. The prtoocol itself needs to be able to demux >the two, and to transition from "raw protocol" to TLS. An example of this >is the STARTTLS mechanism used in http and other protocols. First its >HTTP, and then its TLS, all on the same TCP connection. But what you are really talking about is SMTP, not TLS, so this doesn't hold either. The difference here is that the STARTTLS command IS IN THE SMTP SPEC. The session from start-to-finish is 100% legal SMTP, and any security middlebox is going to recognize it as such. Not so with the Endpoint ID approach in comedia-fix. >Also, this is the only way for SASL to work. SASL, by design, inserts a >security layer in the middle of the protocol stream. Sasl compliant >protocols need to specify how they will demarcate the point at which you >"hand the connection" over to the sasl security layer, so it can decrypt >the messages and hand them over to the application. > >So, while I agree with your concerns, there is a long-established and >recommended practice of such a thing in a good number of widely deployed >IETF protocols. To repeat: these are embedded in the protocol specs and designs themselves, so they don't go out of scope the way that Endpoint ID does. >>This problem can manifest itself in implementation complications as well >>as middlebox problems. > >I don't see the middlebox issue. Please elaborate. Stateful packet inspection. See below. >>Take TLS for example: let's say we put the endpoint ID ahead of the TLS >>handshake. The OpenSSL folks were kind enough to provide C developers a >>simple API where you prepend "ssl_" in front of the normal BSD socket >>calls, and for the most part you can write code for SSL/TLS in the same >>manner as raw TCP sockets. But with an endpoint ID, suddenly I the >>developer have to do a more complicated scheme where I (a) connect a TCP >>socket, (b) send/receive the endpoint ID, then (c) construct an SSL >>session based on the connected socket. This of course presumes that the >>language-specific API to SSL is flexible enough for the developer to >>juggle the order of the protocol stack in this manner. Other API's >>(Java, Perl, VB, etc.) may not be so forgiving. > >Indeed. THis is a weakness. Not a new one. In fact, the need to support >STARTTLS makes me think this is a very common feature of TLS stacks. But, >I have not looked into it. Implementation difficulties are rarely met with sympathy at the IETF it seems. :-) I'll agree to differ on this and leave it for now. >>Then there are the considerations for a decomposed gateway topology. By >>multiplexing signalling information into the media stream, suddenly you >>force the a tight coupling between the signalling and media transport >>infrastructures by intermixing signalling tokens with the media stream. > >How is this different than having the signaling thing ask the media thing >for an IP address, and then putting that IP address into the SDP? Then, >when the media thing receives media on that IP address, it knows the >"control" connection associated with it. Here, we do the same, but instead >of IP address, its IP+eid. Same difference. The difference is that the media thing needs to know about windowing the protocol, which means that it's now tightly bound to SDP-based signalling rather than being a generic media thing. >>For middlebox problems, consider the stateful packet inspection >>firewall. The idea of course is to enforce a policy by protocol rather >>than by connectivity. So SMTP, HTTP, FTP, and DNS are allowed, but >>nothing else, and it doesn't matter what ports or addresses are used. >>In theory the sysadmin should also be able to specify SIP, TLS, RTP/AVP, >>and IM protocols in this list and allow those forward-looking end-users >>to utilize this fancy new SIP stuff. With comedia-fix, every protocol >>that is signaled will not, in fact, *be* the protocol described in the >>SDP. So when the firewall watches the media stream, it doesn't see a >>stream that fits any of the protocol structures it recognizes, and >>therefore disallows the stream. > >Now I am confused. The way that firewall admins enforce policy by protocol >rather than by connectivity is through ports. In the current comedia spec, >there will almost never be just a single port for the newfangled media >stream. So, you can't enforce policy. The mechanism in comedia-fix allows >there to be one, and only one, port allocated for any specific >media-over-tcp type. This will enable firewall admins to do things, not >disable it. You're talking about port-number based enforcement. I'm talking about stateful packet inspection, where the validation (yes, often combined with port filtering) is done by verifying that the content of network traffic itself---not just the endpoint information---conforms to the protocols that are allowed by the policy. By adding the initial data, the traffic no longer conforms to the protocols as understood by the inspection engine. >I do not understand your point about the protocol not "being" the one that >is advertised. It most certainly is, with the addition of a 32 byte ID up >front, but who cares? Who cares? The firewall does. See above. >>Another case is where TLS is provided by an external accelerator box to >>offload the compute load of the server---same issue. >> >>4.2 Decoupled lifetimes >>This has a number of side-effects. First, it essentially forces a >>single-port architecture on both of the endpoints, as the only other >>option is the "this-doesn't-scale" 1:1 client-to-port-number mapping. >>With comedia as it stands today, the lifetime of the listener port is >>decoupled from the lifetime of the session that is begat from that >>listener. No longer the case with comedia-fix. > >You can use as many ports as you like, ranging from 1 to one for each >session. Because I don't need the port to correlate, I am free to use any >algorithm I like. Comedia has to use an algorithm which has at least >one-per-pending-offer, because you have no way to correlate. Therefore, I >do not believe that comedia-fix introduces a binary "1 port" or "1 port >per session" restriction. Speaking of decoupling... :-) I was decoupling the lifetime issue from endpoint-ID. So if you assume that the endpoint-ID idea in comedia-fix does not become spec, but decoupled lifetimes *does* become spec, then the issue I stated above becomes a factor. So we are both correct, but are working from different assumptions. At any rate, at the moment this is eclipsed by more important points, discussed below. >>Second, it forces endpoints to use "both" where one could have opted for >>just "active" or "passive". The problem here is that if one endpoint >>specified "passive", and the media connection drops, it has no way to >>legally reinstate the connection if it needs to send data to the other >>endpoint. In essence, comedia-fix "raises the stakes" as to what is an >>appropriate connection mode to negotiate. In comedia, the only thing at >>stake was the ability to bring up the intial connection. In comedia-fix, >>we add the issue of recovering from the scenario that the remote endpoint >>will drop the connection. > >You need to handle connection failures. In the current comedia, if the >passive side loses the connection, it can bring it up by doing a re-invite >and then include a reconnect parameter. What you CANNOT do is have the >active side reconnect without doing a re-inVITE. In comedia-fix, you can >have the active side reconnect without doing a re-INVITE. There is no >reason we could not also allow the passive side to do a re-INVITE to force >a reconnect from the active side. I did propose to remove that, but >perhaps it is useful after all. See below for my rationale on the re-INVITE. >>Third, as described in comedia-fix, NAT's can cause a similar outage to >>#2 even if each endpoint specifies "both". >>The decoupled lifetime, to my knowledge, is unprecedented. > >Really? See RFC3261. SIP can run over TCP. When it does, the lifetime of >the connection is not strongly coupled to the lifetime of the transaction >or dialog. It used to be, in rfc2543. After years of trying to make it >work, we found it was a nightmare to maintain. THus, it got disacarded. >The result was a nice clean separate of the SIP layer from teh TCP >connectivity layer. This change bought us many properties, including >improvements in robustness (the ability to recover a SIP transaction even >if the tcp connection the request went over had closed). > >Its critical in any protocol where the intermediary elements provide a >subset of the endpoint functionality. "Unprecedented" in terms of the rules governing media endpoint behavior when using SDP, not in the entire IETF protocol suite. Sheesh... :-) The rationale for requiring a re-INVITE was that it was safest and simplest to treat the loss of a connection the in same way as a failure of a media stream. So if the connection goes away, but you didn't get a BYE, and you didn't think you were done yet, then the way to attempt to recover the connection was via a re-INVITE. It was assumed that this mapped closest to how connectionless media endpoints would behave. So now that the context is clearer: is there any precedent for connectionless media endpoints to just start sending media again even after the stream has deemed to have failed for some reason? See next comment for an example. >>In developing comedia I tried to apply the litmus test of "how is this >>scenario handled in connectionless media, and how do connections >>differ?". I don't believe that decoupled lifetimes fares very well >>here. Remember that while "traditional" SDP media transports may be >>connectionless, they aren't stateless. So the corollary to decoupling >>connection lifetime from session lifetime is akin to allowing RTP/AVP >>streams to be stopped, reset, then restarted, all without any additional >>activity on the signalling channel. Again, I'm not an expert here, but I >>imagine that this would be considered outside the spec today. > >There is no notion to starting/stopping RTP streams, so its hard to say >what this would mean. Well, consider the failure case, where the data sent to that port either (a) drops below some performance threshold (90% packet loss, 25,000ms latency, pick your favorite poison), (b) doesn't relate at all to what came before it, or (c) is just undecipherable garbage. In whatever case, the endpoint is able to discern that something is sufficiently amiss that the stream can be considered failed and therefore ended. >>I also don't understand the rationale behind the statement: "If one side >>wishes to force the other to reconnect, it merely drops the connection. >>When the other side has data to send, it will establish a new >>connection." The "reconnect" attribute was never intended to "force" >>reconnects. Rather, it was intended as a way to recover from an >>*unintended* disconnection in such as a way as to preserve the existing >>session state. Is there ever a reason that an endpoint would tear down >>the connection solely to inconvenience the other endpoint with the task >>of re-establishing it? (insert half-smiley here, since that's the >>impression one gets from the language in comedia-fix) > >No, of course not. > >I must admit I am not sure what I meant here. Per above, I do see how the >reconnect parameter would help. Ok, sounds like that is resolved, reconnect is useful therefore stays. >>I guess I'm having trouble understanding why it is so important that the >>lifetime be decoupled. The only argument put forth is the >>multiplexing-bridge scenario. If we really are using a multiplexed >>tunnel to bridge two networks, what's the harm in making the tunneling >>connection "sticky"? > >The intermediaries in this case woudl need to "reference count". That is, >they would need to keep track of each session that gets set up, and then >torn down, which had media over that connection. This is impossible to do >when the media intermediary is decoupled from the SIP proxy. Doing it >would require what we call a B2BUA in SIP, along with a colocated media >intermediary or a remote one under tight control. > >Another problem is disconnects due to some kind of network outage. Lets >say users are sending their TCP-media through two relays. The connection >between the relays gets lost, but the connections from each user to their >relay remains. Neither user will try to reconnect, since as far as they >know, there is no TCP connection problem. The relays know there is a >problem, and they could reconnect, but comedia prohibits them from doing >so. They would have to be a b2bua once more, and issue a new INVITE on >their own, just to re-establish it. In other words, the relays need to be >the same (in terms of fucntioanlity) as the endpoints. I want to drive >such things out of intermediaries, not INTO them. > > >So, to sum up, with comedia today, building these relays requires a very >tight coupling between the SIP proxy (which has to be a b2bua) and the tcp >media relay. WIth the comedia-fix, they are decoupled. The SIP >intermediary can remain a proxy, and the media-relay can worry about its >own connectivity. > > >>On the flip side, since there is a multiplexing function occurring in an >>intermediary, shouldn't there be a mechanism for determining the lifetime >>of the feeds into the mux that just makes this problem go away? How >>today, do the endpoints in this scenario know when to do an initial >>INVITE, then do the final BYE? > >Sure, it can be computed. It just introduces a coupling whcih is not >otherwise there. Sounds like you aren't going to use comedia for this anyway, so I won't pursue the topic. >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >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 mailnull@www1.ietf.org Thu Jan 30 15:25:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09645 for ; Thu, 30 Jan 2003 15:25:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UKSDp27202 for mmusic-archive@odin.ietf.org; Thu, 30 Jan 2003 15:28:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKSDJ27199 for ; Thu, 30 Jan 2003 15:28:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09640 for ; Thu, 30 Jan 2003 15:24:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKRkJ27165; Thu, 30 Jan 2003 15:27:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKMKJ27023 for ; Thu, 30 Jan 2003 15:22:20 -0500 Received: from revere.sonusnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09553 for ; Thu, 30 Jan 2003 15:18:39 -0500 (EST) Received: from host-1.ttiworld.com (host-1 [10.10.100.6]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id h0UKM7724367 for ; Thu, 30 Jan 2003 15:22:07 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 30 Jan 2003 14:22:10 -0600 Message-ID: <81877B9826317E448987499EB79AE7024DAE8F@host-1.ttiworld.com> Thread-Topic: Discrepencies between RFC2833/IANA registry and RFC3264/RFC3388 Thread-Index: AcLInUS0VC9nfdxLQquLUBASNtT/Eg== From: "Kevin Summers" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UKMKJ27024 Subject: [MMUSIC] Discrepencies between RFC2833/IANA registry and RFC3264/RFC3388 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: 8bit Content-Transfer-Encoding: 8bit RFC2833 and http://www.iana.org/assignments/media-types/audio/ seem to say clearly that the MIME media subtype is singular audio/telephone-event However, other RFCs give examples that are plural RFC3264 Offer-Answer: a=rtpmap:110 telephone-events/8000 RFC3388 Grouping of Media Lines: a=rtpmap:97 telephone-events Is it agreed that this is a bug in RFC3264 and RFC3388? _____________________________________________________ Kevin Summers 1701 North Collins Blvd Technical Requirements Richardson, Texas Sonus Networks 75080 kevin.summers@sonusnet.com tel: +1-972-680-6360 http://www.sonusnet.com fax:+1-972-301-4901 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jan 30 15:45:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10071 for ; Thu, 30 Jan 2003 15:45:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UKmh228706 for mmusic-archive@odin.ietf.org; Thu, 30 Jan 2003 15:48:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKmhJ28703 for ; Thu, 30 Jan 2003 15:48:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10049 for ; Thu, 30 Jan 2003 15:44:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKmBJ28668; Thu, 30 Jan 2003 15:48:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKlKJ28635 for ; Thu, 30 Jan 2003 15:47:20 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10027 for ; Thu, 30 Jan 2003 15:43:34 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0UKl6HA024912 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jan 2003 15:47:07 -0500 (EST) Message-ID: <3E398F54.2090406@cs.columbia.edu> Date: Thu, 30 Jan 2003 15:47:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Summers CC: mmusic@ietf.org Subject: Re: [MMUSIC] Discrepencies between RFC2833/IANA registry and RFC3264/RFC3388 References: <81877B9826317E448987499EB79AE7024DAE8F@host-1.ttiworld.com> In-Reply-To: <81877B9826317E448987499EB79AE7024DAE8F@host-1.ttiworld.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 As far as I can tell, this is a typo. We should probably add this to the list of errata published on the RFC editor web page. Thanks for catching this. Kevin Summers wrote: > RFC2833 and http://www.iana.org/assignments/media-types/audio/ > seem to say clearly that the MIME media subtype is singular > audio/telephone-event > > However, other RFCs give examples that are plural > > RFC3264 Offer-Answer: > a=rtpmap:110 telephone-events/8000 > RFC3388 Grouping of Media Lines: > a=rtpmap:97 telephone-events > > Is it agreed that this is a bug in RFC3264 and RFC3388? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jan 31 07:28:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04587 for ; Fri, 31 Jan 2003 07:28:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VCVn422134 for mmusic-archive@odin.ietf.org; Fri, 31 Jan 2003 07:31:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCVnJ22131 for ; Fri, 31 Jan 2003 07:31:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04580 for ; Fri, 31 Jan 2003 07:27:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCVFJ22115; Fri, 31 Jan 2003 07:31:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCTkJ22005 for ; Fri, 31 Jan 2003 07:29:46 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04521 for ; Fri, 31 Jan 2003 07:25:46 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0VCTIAv010582 for ; Fri, 31 Jan 2003 13:29:19 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7M4WPQ5; Fri, 31 Jan 2003 13:29:18 +0100 Message-ID: <3E3A6C1E.1050208@era.ericsson.se> Date: Fri, 31 Jan 2003 13:29:18 +0100 X-Sybari-Trust: a1c0b0f4 9ffcebbb 32fc239c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP Proxy-require header 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, At the last teleconference we discussed the RTSP proxy-require header. We have a proposal for changing the meaning of that header. Current text: Says that proxy-require applies to both proxy and server. New Proposal: The feature tags in a "Proxy-require" header will only apply to the proxies, and not the server. For feature that the server must support the "Require" header shall be used. If required feature support from both proxy and server both "Proxy-Require" and "Require" must be used. Pro: - Align with SIP's usage of header - Makes it possible to create features tags for proxy only functionality. Otherwise all servers will be mandated to also know about proxy only features. Cons: Backwards compatibility. (Actually this does not matter much as: A old server implementing the old way would also not work with any new feature tags for proxies. So it will block operation independent of changed semantics or not.) If you have any comments on this, please respond. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jan 31 07:54:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05235 for ; Fri, 31 Jan 2003 07:54:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VCvXD23583 for mmusic-archive@odin.ietf.org; Fri, 31 Jan 2003 07:57:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCvXJ23579 for ; Fri, 31 Jan 2003 07:57:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05218 for ; Fri, 31 Jan 2003 07:53:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCvBJ23561; Fri, 31 Jan 2003 07:57:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCu2J23527 for ; Fri, 31 Jan 2003 07:56:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05102; Fri, 31 Jan 2003 07:51:55 -0500 (EST) Message-Id: <200301311251.HAA05102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 31 Jan 2003 07:51:55 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) Author(s) : M. Westerlund Filename : draft-ietf-mmusic-sdp-bwparam-00.txt Pages : 16 Date : 2003-1-30 The existing Session Description Protocol (SDP) bandwidth modifiers and their values include the bandwidth needed also for the transport and IP layers. When using SDP in protocols like Session Announcement Protocol (SAP), Session Initiation Protocol (SIP) and Real-Time Streaming Protocol (RTSP) and the involved hosts reside in networks running different IP versions, the interpretation of what type of lower layers that is included is not clear. This documents defines a bandwidth modifier that does not include transport overhead, instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the packet rate can then be used to calculate the real bit-rate over the actually used transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-bwparam-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-30135828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-bwparam-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-30135828.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jan 31 08:06:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05543 for ; Fri, 31 Jan 2003 08:06:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VD9bj24672 for mmusic-archive@odin.ietf.org; Fri, 31 Jan 2003 08:09:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VD9bJ24669 for ; Fri, 31 Jan 2003 08:09:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05509 for ; Fri, 31 Jan 2003 08:05:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VD93J24650; Fri, 31 Jan 2003 08:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VD8VJ24627 for ; Fri, 31 Jan 2003 08:08:31 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05492 for ; Fri, 31 Jan 2003 08:04:30 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0VD82Av022841 for ; Fri, 31 Jan 2003 14:08:02 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7M4W6WP; Fri, 31 Jan 2003 14:08:02 +0100 Message-ID: <3E3A7532.7020508@era.ericsson.se> Date: Fri, 31 Jan 2003 14:08:02 +0100 X-Sybari-Trust: 6860926d 9ffcebbb 32fc239c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP teleconference 5 february 18.00 CET 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, It is time for another teleconference on wednesday (5 Feb.) at 18.00 CET, 9.00 PST, duration 90 minutes. All who are members of RTSP logistics will get the detail that way. If not send me a mail to receive participation information. Agenda: 1. Follow up on last meeting - Redirect, waiting for new text from Tom - Update on Range header text in regards to Live streams. - Extension mechanism, have support as SIP. - Registration of feature tags, etc. Any comments? 2. Administrative - Document Editor(s)!!! 3. Today's new Issues: * RTSP and NATs What solutions exist to make RTSP traverse NATs without ALG. http://rtsp.org/bug513888 - STUN? See - NAT, ALG and Firewall recommendations in relation to RTSP? * Use of destination parameter in Transport header: http://rtsp.org/bug507347 * Use of transport connection interleaved data http://rtsp.org/bug507408 http://rtsp.org/bug556589 http://rtsp.org/bug662436 http://rtsp.org/bug672160 * Unclarities when doing resetup http://rtsp.org/bug513737 -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jan 31 15:19:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17621 for ; Fri, 31 Jan 2003 15:19:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VKMkB17040 for mmusic-archive@odin.ietf.org; Fri, 31 Jan 2003 15:22:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKMkJ17037 for ; Fri, 31 Jan 2003 15:22:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17616 for ; Fri, 31 Jan 2003 15:18:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKMOJ17004; Fri, 31 Jan 2003 15:22:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKLmJ16977 for ; Fri, 31 Jan 2003 15:21:48 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17597 for ; Fri, 31 Jan 2003 15:17:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 31 Jan 2003 12:19:36 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Fri, 31 Jan 2003 12:19:35 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2/8.12.2) with ESMTP id h0VKIJKO014788 for ; Fri, 31 Jan 2003 12:18:19 -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 18ehcF-0007bY-00 for ; Fri, 31 Jan 2003 12:18:23 -0800 Date: Fri, 31 Jan 2003 12:17:29 -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-Status: No, hits=2.0 required=5.0 tests=KNOWN_MAILING_LIST,NO_REAL_NAME,SPAM_PHRASE_02_03 version=2.42 X-Spam-Level: ** X-UIDL: 73073f95f339b74251fd68d42f362a93 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #72 - 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-678107 ] Change of Proxy-Require header (SourceForge.net) 2. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net) 3. [ rtspspec-Bugs-507332 ] RTSPS/TLS support (SourceForge.net) 4. [ rtspspec-Bugs-507332 ] RTSPS/TLS support (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 31 Jan 2003 04:43:11 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-678107 ] Change of Proxy-Require header Bugs item #678107, was opened at 2003-01-31 13:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&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: Change of Proxy-Require header Initial Comment: Current text: Says that proxy-require applies to both proxy and server. New Proposal: The feature tags in a "Proxy-require" header will only apply to the proxies, and not the server. For feature that the server must support the "Require" header shall be used. If required feature support from both proxy and server both "Proxy-Require" and "Require" must be used. Pro: - Align with SIP's usage of header - Makes it possible to create features tags for proxy only functionality. Otherwise all servers will be mandated to also know about proxy only features. Cons: - Backwards compatibility. (Actually this does not matter much as: A old server implementing the old way would also not work with any new feature tags for proxies. So it will block operation independent of changed semantics or not.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 31 Jan 2003 04:49:47 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response Bugs item #619421, was opened at 2002-10-07 01:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Rob Lanphier (robla) Summary: Range header in PLAY response Initial Comment: Current RTSP RFC makes Range header in PLAY response from server optional. If the PLAY request includes a Range header indicating a possible seek, then it is probably necessary to include Range in the response since it is possible that the requested seek position could not be honored and playback will resume at the nearest seekable point which is not known to the client. Note: To fix this issue in 3GPP, Range in a PLAY response was made mandatory for all PLAY responses. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 13:49 Message: Logged In: YES user_id=302620 As discussed in the teleconf the 22 jan 2003: We should look at strengting the requirement on having the Range header also for live streams when using RTP. A solution based on Range:npt=now- with optional time or using Range:clock=x can work. But careful wording is required. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-11-20 21:06 Message: Logged In: YES user_id=3796 One other thing...put Maureen Chesire in the acknowlegements for raising this.... ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-11-20 21:02 Message: Logged In: YES user_id=3796 Per a conversation with Magnus and I, we think we should soften the language somewhat (strong SHOULD instead of MUST). One case to consider is a live stream, which one would think would obviate the need for this header. However, the rationale for having it in live is when dealing with RTP. Since RTP audio and video streams can have a completely different timestamp base, there needs to be an out-of-band technique for synchronization. The two techniques used in RTSP are: 1. RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch 2. RTCP timestamp<->NTP mapping Eventually, a well-behaved RTSP client will synch the streams based on the RTCP timestamps (when received). However, there's a period before the first RTCP packet arrives that there's no sync, unless a Range header is known. So, that also points to what the Range header should look like. The Range header should include an open-ended wallclock range, like so: Range: clock=20021120T133205Z- RTP-Info:url=rtsp://example.com/fizzle/audiotrack; seq=5712;rtptime=934207921, url=rtsp://example.com/fizzle/videotrack; seq=57654;rtptime=2792482193 The spec should make this clear. An interesting consideration to make here is a restriction on Range response. The current rtsp spec states that "The unit of the range in the reply is the same as that in the request". Perhaps an alternate syntax, if the PLAY request has a Range: header in npt is as follows: Range: npt=now;time=20021120T133205Z The "time" allows for mapping to occur. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:36 Message: Logged In: YES user_id=302620 Yes, the range header is need for RTP synchonization. The draft specification has been updated to require this when using RTP to make synchonization possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 31 Jan 2003 05:00:00 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507332 ] RTSPS/TLS support Bugs item #507332, was opened at 2002-01-23 04:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194 Category: None >Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: RTSPS/TLS support Initial Comment: Currently, the version of RTSP that's checked into the repository has TLS support and rtsps:. This is probably just a relic of the fact that we pulled this at the very last minute when going to Proposed Standard, and it never got checked in. It's an interesting feature, but one that probably warrents a separate draft on it's own track. robla: I vote for taking this out. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 14:00 Message: Logged In: YES user_id=302620 The current decision from telecon in december 2002 is that we should have it as a seperate extension document. Anyone interested may start writing on such a document. Any more than informative text shall be removed from base spec. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:37 Message: Logged In: YES user_id=302620 If it is going to be left in the spec it needs further work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 31 Jan 2003 05:00:54 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507332 ] RTSPS/TLS support Bugs item #507332, was opened at 2002-01-23 04:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194 Category: None Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: RTSPS/TLS support Initial Comment: Currently, the version of RTSP that's checked into the repository has TLS support and rtsps:. This is probably just a relic of the fact that we pulled this at the very last minute when going to Proposed Standard, and it never got checked in. It's an interesting feature, but one that probably warrents a separate draft on it's own track. robla: I vote for taking this out. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 14:00 Message: Logged In: YES user_id=302620 The current decision from telecon in december 2002 is that we should have it as a seperate extension document. Anyone interested may start writing on such a document. Any more than informative text shall be removed from base spec. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 14:00 Message: Logged In: YES user_id=302620 The current decision from telecon in december 2002 is that we should have it as a seperate extension document. Anyone interested may start writing on such a document. Any more than informative text shall be removed from base spec. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:37 Message: Logged In: YES user_id=302620 If it is going to be left in the spec it needs further work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic