From mailnull@www1.ietf.org Mon Jun 2 10:09: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 KAA08394 for ; Mon, 2 Jun 2003 10:09:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52E9GA17460 for mmusic-archive@odin.ietf.org; Mon, 2 Jun 2003 10:09:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52E9GB17457 for ; Mon, 2 Jun 2003 10:09:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08343 for ; Mon, 2 Jun 2003 10:09:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mpy9-0003JN-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 10:07:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mpy9-0003JH-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 10:07:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52E9AB17447; Mon, 2 Jun 2003 10:09:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52E6HB16421 for ; Mon, 2 Jun 2003 10:06:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08014 for ; Mon, 2 Jun 2003 10:06:11 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpvG-0003IC-00 for mmusic@ietf.org; Mon, 02 Jun 2003 10:04:26 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19MpvG-0003I9-00 for mmusic@ietf.org; Mon, 02 Jun 2003 10:04:26 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 066C4576B7 for ; Mon, 2 Jun 2003 16:06:10 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA15670 for ; Mon, 2 Jun 2003 16:06:10 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p2/8.8.5-1.2.2m-19990317) with ESMTP id QAA18244 for ; Mon, 2 Jun 2003 16:06:09 +0200 (MEST) To: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 2 Jun 2003 15:57:40 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 02/06/2003 16:07:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RTSP redirection Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , dear MMUSICers, following the post last week on RTSP redirection there was a discussion during the last RTSP phone call here are the results (please comment/correct ) ******************************************************** 1) The core RTSP spec needs a few clarifications about redirection (that -in short- [redirection=failure]) 1.A) There is a need for a piece of text explaining that in general the server providing the RTSP streaming service (i.e. SETUP etc ...) is assumed to also be the one that provides the session description (i.e. DESCRIBE) [reasons: simplicity/logic, easier to do interrop testing, backward compatibility] 1.B) Specifically a minimal RTSP client implementation does not need to expect that the response to DESCRIBE would be used to point to another server whatever mean would be used for that (i.e. content-location, absolute URL is SDP etc) unless it is signaled *explicitely* as a redirection: 1.C) Specifically if a server wishes to redirect a client at DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx code (TBD) and the answer MUST NOT contain any SDP (i.e. this is the single minimal interoperable RTSP redirection behavior) Open Issue: what is the most appropriate way to signal the alternate server ? is it Content-Location ? 1.D) following which a minimal RTSP client implementation MUST issue a DESCRIBE on the alternate server (i.e. start from scratch) 2) However a separately documented (and separately interop tested) improvement would be to define "implicit RTSP redirection" i.e. -in short- [redirection=success] 2.A) "implicit RTSP redirection" is an *optional* "optimization" which usage involves a *feature tag*. Such advanced client would issue the DESCRIBE with the corresponding feature tag (TBD) signaling that it is able to receive an "implicit redirection" (servers MUST NOT use implicit RTSP redirection if the feature tag was not present in the DESCRIBE request) 2.B) An "implicit redirection" is defined as a DESCRIBE response with a 2XX code (TBD) -because it contains a valid SDP- and it also contains a mean to redirect the client toward another (alternate) server. 2.C) The exact mean to indicate redirection is TBD. Content-location has been proposed. 2.D) The client MAY then directly SETUP to the alternate server. Note1:The purpose is to save one round trip.(RTSP suffers from being slow to setup due to the large number of required round trips) Note2: It was discussed in the conf call that there are other ways to do that (e.g. use round robin DNS load balanced HTTP to retreive the SDP etc) ....the rationale for doing it in RTSP is that the redirection can be made really "smart" in the sense that we have then a RTSP client talking to a RTSP "service" (service is because there are several "machines", all with a RTSP external interface but that are some how coordinated) ...which may have additional terminal profiling etc ... This is especially relevant in the 3GPP context where: (1)RTT are large (2) UAPROF provides extensive terminal capabilities signaling ************************************* Unless there are objections I will attempt to formulate the corresponding required pieces of text ASAP. ************************************* regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 2 10:27:22 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 KAA09752 for ; Mon, 2 Jun 2003 10:27:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52EQvo18820 for mmusic-archive@odin.ietf.org; Mon, 2 Jun 2003 10:26:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52EQvB18817 for ; Mon, 2 Jun 2003 10:26:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09748 for ; Mon, 2 Jun 2003 10:26:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MqFG-0003Sy-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 10:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MqFF-0003Sv-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 10:25:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52EQsB18809; Mon, 2 Jun 2003 10:26:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52EO4B18579 for ; Mon, 2 Jun 2003 10:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09658 for ; Mon, 2 Jun 2003 10:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MqCU-0003SR-00 for mmusic@ietf.org; Mon, 02 Jun 2003 10:22:14 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19MqCS-0003SO-00 for mmusic@ietf.org; Mon, 02 Jun 2003 10:22:13 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h52ENw0J010580; Mon, 2 Jun 2003 16:23:58 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYSHRWW; Mon, 2 Jun 2003 16:23:30 +0200 Message-ID: <3EDB5D67.9080900@ericsson.com> Date: Mon, 02 Jun 2003 16:21:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP redirection References: 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 Phillipe, Comments below. philippe.gentric@philips.com wrote: > dear MMUSICers, > > following the post last week on RTSP redirection > there was a discussion during the last RTSP phone call > > here are the results (please comment/correct ) > > ******************************************************** > > 1) The core RTSP spec needs a few clarifications about redirection > (that -in short- [redirection=failure]) > > 1.A) There is a need for a piece of text explaining that in general the server providing > the RTSP streaming service (i.e. SETUP etc ...) is assumed to also be the one > that provides the session description (i.e. DESCRIBE) [reasons: simplicity/logic, > easier to do interrop testing, backward compatibility] > > 1.B) Specifically a minimal RTSP client implementation does not need to expect > that the response to DESCRIBE would be used to point to another server > whatever mean would be used for that (i.e. content-location, absolute URL > is SDP etc) unless it is signaled *explicitely* as a redirection: > > 1.C) Specifically if a server wishes to redirect a client at DESCRIBE time > (e.g. for load balancing etc) it MUST issue a 3xx code (TBD) and the answer > MUST NOT contain any SDP (i.e. this is the single minimal interoperable RTSP > redirection behavior) > > Open Issue: what is the most appropriate way to signal the alternate server ? > is it Content-Location ? This is not an open isssue. When one use REDIRECT or a 3rr response to redirect, the "Location" header MUST be used to point out the new server. This MUST level may not be totally clear in draft-03 and should be reviewed. > > 1.D) following which a minimal RTSP client implementation MUST issue > a DESCRIBE on the alternate server (i.e. start from scratch) > > > > > 2) However a separately documented (and separately interop tested) > improvement would be to define "implicit RTSP redirection" i.e. > -in short- [redirection=success] > > 2.A) "implicit RTSP redirection" is an *optional* "optimization" which usage > involves a *feature tag*. Such advanced client would issue the DESCRIBE > with the corresponding feature tag (TBD) signaling that it is able to receive > an "implicit redirection" (servers MUST NOT use implicit RTSP > redirection if the feature tag was not present in the DESCRIBE request) > > 2.B) An "implicit redirection" is defined as a DESCRIBE response with a > 2XX code (TBD) -because it contains a valid SDP- > and it also contains a mean to redirect the client toward > another (alternate) server. > What would be the motivation behind using a differnet 2xx code than 200? Please elaborate with pro and cons. > 2.C) The exact mean to indicate redirection is TBD. > Content-location has been proposed. The usage of Content-Base may actually be more appropriate as it has not any semantic meaning more than being the base for any relative URL. Content-Location has a semantic meaning that the content actually hides/(also present) behind the used URL and instead can be found/referenced using the URL present i Content-Location. Further input into the matter is desired. > > 2.D) The client MAY then directly SETUP to the alternate server. > > Note1:The purpose is to save one round trip.(RTSP suffers from being > slow to setup due to the large number of required round trips) > > Note2: It was discussed in the conf call that there are other ways to do that > (e.g. use round robin DNS load balanced HTTP to retreive the SDP etc) > ....the rationale for doing it in RTSP is that the redirection can be made > really "smart" in the sense that we have then a RTSP client talking > to a RTSP "service" (service is because there are several "machines", > all with a RTSP external interface but that are some how coordinated) > ...which may have additional terminal profiling etc ... This is especially > relevant in the 3GPP context where: (1)RTT are large (2) UAPROF > provides extensive terminal capabilities signaling > > ************************************* > > Unless there are objections I will attempt to formulate the corresponding > required pieces of text ASAP. > 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 2 12:19: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 MAA13885 for ; Mon, 2 Jun 2003 12:19:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52GJEu29731 for mmusic-archive@odin.ietf.org; Mon, 2 Jun 2003 12:19:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GJEB29728 for ; Mon, 2 Jun 2003 12:19:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13865 for ; Mon, 2 Jun 2003 12:19:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mrzy-0004TH-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 12:17:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mrzx-0004TE-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 12:17:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GJ9B29719; Mon, 2 Jun 2003 12:19:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GGWB29566 for ; Mon, 2 Jun 2003 12:16:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13788 for ; Mon, 2 Jun 2003 12:16:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MrxM-0004SB-00 for mmusic@ietf.org; Mon, 02 Jun 2003 12:14:44 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19MrxL-0004S8-00 for mmusic@ietf.org; Mon, 02 Jun 2003 12:14:43 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19Mrz0-0004XQ-00; Mon, 02 Jun 2003 09:16:26 -0700 Date: Mon, 2 Jun 2003 09:16:26 -0700 From: Tom Marshall To: Magnus Westerlund Cc: philippe.gentric@philips.com, mmusic@ietf.org Subject: Re: [MMUSIC] RTSP redirection Message-ID: <20030602161625.GA17220@real.com> References: <3EDB5D67.9080900@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <3EDB5D67.9080900@ericsson.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >2.C) The exact mean to indicate redirection is TBD. > >Content-location has been proposed. >=20 > The usage of Content-Base may actually be more appropriate as it has not= =20 > any semantic meaning more than being the base for any relative URL.=20 > Content-Location has a semantic meaning that the content actually=20 > hides/(also present) behind the used URL and instead can be=20 > found/referenced using the URL present i Content-Location. Further input= =20 > into the matter is desired. I agree that Content-Base is the way to go. I discussed this matter with Rob Lanphier and others last week. The wording in 2326 was designed to discourage redirection via the Content-Base header out of a desire to reduce complexity (or at least not add more complexity).= =20 On the other hand, it seems to be more consistent to allow redirection via the Content-Base header. First, it is more consistent with the way SDP is handled when retrieved via HTTP. If the HTTP server sends a Content-Base header, the host portion is expected to be honored, so why not with RTSP?= =20 If the SDP contains absolute control urls, why should the client connect to different servers depending on how it got the SDP? Second, it is more consistent when a proxy is involved. The client will receive the DESCRIBE response with Content-Base header that points to a different server. It will then request a SETUP on the url resulting from the Content-Base header and the control url. The proxy will connect to the other server to send the SETUP request. Why should the client alone act any differently? The Content-Base method requires minimal changes to the spec. It would mostly require some text that makes it clear the client MUST (or at the very least SHOULD) honor the host portion in the resulting stream url(s). And a couple of examples would be nice, of course. --=20 Another war ... must it always be so? How many comrades have we lost in this way? ... Obedience. Duty. Death, and more death ... -- Romulan Commander, "Balance of Terror", stardate 1709.2 --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+23hZqznSmcYu2m8RAoqbAJwLm2MRzfF9n1Vuh+vQ7uIhDYw3PACcDg2P id8o1iYdoKguT8EJAIpP1I4= =i17v -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 2 12:37: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 MAA14527 for ; Mon, 2 Jun 2003 12:37:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52Gb2n30834 for mmusic-archive@odin.ietf.org; Mon, 2 Jun 2003 12:37:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Gb2B30831 for ; Mon, 2 Jun 2003 12:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14518 for ; Mon, 2 Jun 2003 12:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsHB-0004bU-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 12:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MsHA-0004bR-00 for mmusic-web-archive@ietf.org; Mon, 02 Jun 2003 12:35:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Gb0B30754; Mon, 2 Jun 2003 12:37:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GYwB30663 for ; Mon, 2 Jun 2003 12:34:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14455 for ; Mon, 2 Jun 2003 12:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsFB-0004ag-00 for mmusic@ietf.org; Mon, 02 Jun 2003 12:33:09 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19MsFA-0004Zf-00 for mmusic@ietf.org; Mon, 02 Jun 2003 12:33:08 -0400 Received: from ha2mpk-mail.Eng.Sun.COM ([129.146.16.22]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h52GYO4Z014112 for ; Mon, 2 Jun 2003 09:34:24 -0700 (PDT) Received: from sun.com (vpn-129-150-17-24.SFBay.Sun.COM [129.150.17.24]) by ha2mpk-mail.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id JAA03526 for ; Mon, 2 Jun 2003 09:34:23 -0700 (PDT) Message-ID: <3EDB7C73.4040203@sun.com> Date: Mon, 02 Jun 2003 12:33:55 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Minutes from 28 May Telecon on RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 May 28th Teleconference Meeting Minutes: Agenda: ------- 1. Opening of meeting. 2. Since last meeting (14th of May). a. Bug 533691 & 513880 - Waiting for updated text after resolution of issues. b. http://rtsp.org/bug556295 - Thomas to write text. c. Multiple SSRC in RTSP. - Aravind to write updated text. d. Other? 3. New Things a. http://rtsp.org/507882 - RTP timestamp and pause b. http://rtsp.org/739845 - "a=range" is missing IANA registration and clear rules c. http://rtsp.org/742328 - How to handle PLAY request when at the end of a media clip d. http://rtsp.org/742348 - Usage of implicit REDIRECT. 4. Administrative a. Phase 2 of the work. Getting text into shape. 5. Any other Issues 6. Next meeting - Proposal: 11th of June? 7. End meeting Attendees: ---------- Magnus Westerlund Geetha Srikantan Aravind Narasimhan Philippe Gentric Yves Ramanzin Rob Lanphier Sean Sheedy Thomas Zeng Anders Klemets Old Issues: ----------- Multiple SSRC Issue: -------------------- Magnus: Why change the RTCP section of the Session Header? Aravind: It was just to have method to indicate how the SSRC can be located. Magnus: Hard to have mandatory recommendation where SSRC should go in RR. Thomas: Hint for server implementation Aravind: Implementations should look through all SSRCs in the RR. Thomas: If there are other SSRCs, how does the server resolve it. Magnus: What you need to resolve is the server has to know the client SSRC. Thomas: Client_ssrc is not mandatory, right? Magnus: It is added in the bis02 Thomas: Difficutly in resolving where the RR is coming from it Aravind: What is the main question? RTP session is just address pair Thomas: If there is no NAT, what is the source/destination? Magnus: Client address should be in the destination address field. Aravind: Maybe we should not mandate where the SSRC should be in Thomas: Agreed Magnus: Agreed Resolution: Remove the text added to indicate where SSRC should go into the RTCP RR. Aravind will write up. Bug 556295 - Client Issues PAUSE while server in READY state ------------------------------------------------------------ Thomas: While server is in ready state, badly behaving client sets pause point to future time, what is the proper response? Pause request without the range header, server sends 200 Ok. If client does send the range header in the PAUSE request, what should be returned? Rob: Why not just return response with Range header of where the server paused? Thomas: If the client sends Range header for future time and server sends 200 OK while setting the range header, is that a wrong message to the client? What if the client doesn't check the range response header? Rob: Contend that the Range header needs to be checked by client. Magnus: If this is a big issue, we not allow client to do PAUSE in READY. Sean: The client should be check range header in READY state. It is really a corner case for client to send range in future. Thomas: Ok with that Magnus: Queueing pause in not in the spec? Thomas: Confusion if client doesn't check range header. Aravind: All pause response must have a range header? If the client requests a PAUSE in the future in the READY state, the server will respond 200K with the current pause point in the range header. Resolution: Ok to do PAUSE in ready state. Whether range header is included in the PAUSE request or not, the server will return 200 Ok. The range response header will be set to the current pause point (not to any other time requested in the PAUSE request). Thomas will write up. Bug 533691 & 513880 ------------------- Magnus: Status? Aravind: Just sent it out a couple of minutes ago. Everyone should please review and send comments. Essentially says that Range intervals always go from the first number to the second number. For negative scale, ranges can be decreasing. Range is still half open. Exception at 0, where if 0 is the second point, it is closed. New Things: ----------- Bug 507882 - RTP timestamp and the effect of PAUSE. --------------------------------------------------- Magnus: Old bug. But resolution is reached on email. There will be a gap in the RTP timestamps space during the pause, that reflects realtime. Magnus: Need to add warning that some old servers may not behave this way with the gap in RTP timestamp. Good example in Appendix B is needed. Yves: What is the outcome? Where will it be clarified? Magnus: Will be in the next RTSP update Aravind: Someone going to write this up? I'll take it. Resolution: Aravind will write up the upshot of the mail and teleconference discussions as clarifications to the spec. Bug 739845 - "a=range" is missing IANA registration and clear rules. -------------------------------------------------------------------- Magnus: No IANA registration for it. Just need to write it up. ABNF should also include extension for new format types. Magnus: Multiple a=range allow? May cause major incompatibilities? Thomas: Anyone tried to use it? Magnus: Probably not? Thomas: Should be disallowed? Aravind: Specified anywhere? Magnus: That is the questions Aravind: Will probably cause incompatibilities. Magnus: Need normative language on how ranges should be specified. Magnus: How about allowing multiple range specifications, NPT, SMPTE? Rob: Doubt any current implementations allow it, but that may not be the right way to approach it. Thomas: Different clients may prefer different specifications such as NPT, SMPTE, Clock Magnus: Clock not most common Thomas: SOme clients may not have the capability to understand certain formats. Felxibility helps. Magnus: How do you specify? Each person should consider how your own client deals with it? Resolution: Needs more detailed write up and discussion on MMUSIC. Magnus will write more detail about this to MMUSIC. Bug 742328 - How to handle PLAY requests at end of a media clip -------------------------------------------------------------- Magnus: This came up with interop tests Geetha: The server can use wallclock time and use the range headers from the play request. Magnus: Play request may not have range header in the case of resuming from pause Geetha: Aren't all PLAY and PAUSE requests mandated to have range headers? Aravind: Only responses are mandated to have range headers. Magnus: Use option B from bug report. Send a 457 Invalid Range. Resolution: The server sends a 457 (Invalid Range) including in the response the range header for the pause point. Magnus will write it up. Bug 742348 - Usage of implicit REDIREDCT ---------------------------------------- Phillippe: The first server may not be able to serve the stream but may be able to send the SDP. Want to save SDP. This issue came up in IMTC, 3GPP interop. Philippe: Proposal, to send OK DESCRIBE response with URL for redirection. Counter proposal to use the full URL in the REDIRECT response. Thomas: 2326 tells that describe response should not use this. Philipple: Why? Thomas: To prevent loops Yves: If you use it in the describe response, the client will send some SETUP request. What kind of loop will you have? Rob: Which bug are we talking about? Yves: Section 10.2 says discouraging use of redirect in DESCRIBE response. Yves: We try to minimize RTT. We want to redirect. Load balancing is a place that this is used. Rob: It's not about looping. Its about making sure that the description and the serving was coupled. If there are whole bunch of URLS in the response, makes the clients complex. Yves: Basically, are you saying that it is not recommended to have two different machines, one doing describe and one doing the streaming. Rob: Yes, the machine serving up the media should have a means of describing it. Didn't want to get into the problmem of having URL in the response, and which points you to another server, when you have to do another describe to make sure it matches up. There should be one normative source to do the description and one way of doing it. Rob: Concern is that we are adding another feature. Need to test interoperability. Yves: You can do it with HTTP, Get the SDP from using HTTP and then use the URLs in the SDP to do RTSP. It is better to use RTSP response to keep the mechanisms alinged. Also not preferred to have URLs in SDP. Rob: Big concern is having yet another way to the same thing. Magnus: Load balancing doesnt seem like a good reason. Aren't you hiding the multiple server with DNS level hiding. Yves: Can use Redirect to load balanceing. Rob: Done already Yves: But extra RTT. The proposed soltuion will remove RTT. Mangnus: Maybe can use DNS load balancing to reduce RTT. Yves: Sometimes it takes more intimate knowledge about client. Addtional streaming service info in DESCRIBE can be useful. Rob: RTSP interoperabilty sucks. If we solve that we can add some more features. Yves: The main problem is that the specification is not clear about error messages and some of these features. What is the way foward? Rob: Please write up some text Yves: What is the process for discussing this more? Magnus: Write a proposal and discuss on MMUSIC. Thomas: This is starting to become more clear. Can see advantanges of having the RTT reduced. Rob: An interesting thing that shouldn't be forced on every client. Magnus: Feature tag may be a way to go. Thomas: The feature tag may help also avoid DOS attacks. Rob: The problem is that the Onus is still on the client to use the feature tag and try the fall back, especially if the proxies and servers do not support the fall back. Magnus: Philippe: A new client will be able to save 1 RTT. An old client will get complete explict redirection. Rob: Clients and servers have to support base line capabiliy and this will be an optional optimization on top of that. Philippe: Baseline is explicit redirection. Magnus: Optimization in current spec or separate document? Philippe: Explict redirection is 3XX. No information. Then behavior is close to HTTP. Philippe: Optimization: 2XX with information. And feature tag. Magnus: SDP Content Location or Content Base? Philippe: Let's discuss this more on the mmusic Magnus: Separate document to do optimization Philippe: Will do separate document to do feature tag and optmization. Magnus: Also, Philippe, please clarify the information in current draft. Not allowed to use Content-Base, Content-Location. Should not use Session description to point to other places. Minimum implementation of the client should only need to deal with content from the same server. Resolution: Philippe and Yves will write up a proposal for an optional feature of RTSP to allow redirection on the DESCRIBE response. 2XX will be used for the redirection. It will be proposed as a separate document. The base line will be specified in RTSP. Will be 3XX without any information if stream or SDP cannot be served. Explicit redirection will be the baseline mode of operations. Philippe and Yves will write up a clarification to the the current spec indicating the baseline and disallowing the use of Content-Location and Content-Base in the base line RTSP. Other Issues: ------------- Magnus: Need to clean up the spec. Don't have that much time in hand. Aravind: I can help. Magnus: Let's take it offline. Aravind: July 13-18th is the IETF Magnus: Submissions by 30th June Magnus: Tentative 16th of June for meeting _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jun 3 07:52: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 HAA27901 for ; Tue, 3 Jun 2003 07:52:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53BpWk04752 for mmusic-archive@odin.ietf.org; Tue, 3 Jun 2003 07:51:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BpWB04748 for ; Tue, 3 Jun 2003 07:51:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27868 for ; Tue, 3 Jun 2003 07:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NAIQ-0004FC-00 for mmusic-web-archive@ietf.org; Tue, 03 Jun 2003 07:49:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NAIQ-0004F6-00 for mmusic-web-archive@ietf.org; Tue, 03 Jun 2003 07:49:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BpRB04727; Tue, 3 Jun 2003 07:51:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BlhB04489 for ; Tue, 3 Jun 2003 07:47:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27501; Tue, 3 Jun 2003 07:47:40 -0400 (EDT) Message-Id: <200306031147.HAA27501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Jun 2003 07:47:40 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp4nat-05.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --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 : RTCP attribute in SDP Author(s) : C. Huitema Filename : draft-ietf-mmusic-sdp4nat-05.txt Pages : 7 Date : 2003-6-2 The session description protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these port have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-05.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-sdp4nat-05.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-sdp4nat-05.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-6-2145718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp4nat-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp4nat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145718.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 Jun 4 05:25: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 FAA09233 for ; Wed, 4 Jun 2003 05:25:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h549PWM29106 for mmusic-archive@odin.ietf.org; Wed, 4 Jun 2003 05:25:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h549PWB29103 for ; Wed, 4 Jun 2003 05:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09220 for ; Wed, 4 Jun 2003 05:25:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NUUd-00007y-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 05:23:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NUUc-00007u-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 05:23:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h549NRB29000; Wed, 4 Jun 2003 05:23:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h549M6B28964 for ; Wed, 4 Jun 2003 05:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09185 for ; Wed, 4 Jun 2003 05:22:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NURJ-00007R-00 for mmusic@ietf.org; Wed, 04 Jun 2003 05:20:13 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19NURI-00007O-00 for mmusic@ietf.org; Wed, 04 Jun 2003 05:20:12 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h549Mdbj026019 for ; Wed, 4 Jun 2003 11:22:39 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGGCLX7; Wed, 4 Jun 2003 11:23:01 +0200 Message-ID: <3EDDB99F.9060904@ericsson.com> Date: Wed, 04 Jun 2003 11:19:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP telecon 16th of June 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, I have now decided that the next RTSP telecon is the 16th of June at the normal time of 18.00 CET. The reason for not keeping with the normal two week pattern is that there is very few work days at least for me until the 11th. Agenda will be posted later. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 4 11:03:22 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 LAA25290 for ; Wed, 4 Jun 2003 11:03:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54F2x823144 for mmusic-archive@odin.ietf.org; Wed, 4 Jun 2003 11:02:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54F2xB23141 for ; Wed, 4 Jun 2003 11:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25280 for ; Wed, 4 Jun 2003 11:02:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZl9-0003yk-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 11:01:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZl9-0003yh-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 11:01:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54F1BB23063; Wed, 4 Jun 2003 11:01:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54ExvB22926 for ; Wed, 4 Jun 2003 10:59:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25155 for ; Wed, 4 Jun 2003 10:59:50 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZiE-0003wx-00 for mmusic@ietf.org; Wed, 04 Jun 2003 10:58:02 -0400 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 19NZiD-0003wu-00 for mmusic@ietf.org; Wed, 04 Jun 2003 10:58:01 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id AFF6A6CC30; Wed, 4 Jun 2003 16:59:50 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA05786; Wed, 4 Jun 2003 16:59:50 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p2/8.8.5-1.2.2m-19990317) with ESMTP id QAA07835; Wed, 4 Jun 2003 16:59:49 +0200 (MEST) Subject: Re: [MMUSIC] RTSP redirection To: Magnus Westerlund Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 4 Jun 2003 16:51:18 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 04/06/2003 17:00:52 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 you wrote: [erased context] >What would be the motivation behind using a differnet 2xx code than 200? > Please elaborate with pro and cons. CONS (use 200) because the response to the DESCRIBE is simply *successful* ... PROS (use some 2xx code xx!= 00) RFC2616 uses the following codes: 10.2.1 200 OK ...................................................58 10.2.2 201 Created ..............................................59 10.2.3 202 Accepted .............................................59 10.2.4 203 Non-Authoritative Information ........................59 10.2.5 204 No Content ...........................................60 10.2.6 205 Reset Content ........................................60 10.2.7 206 Partial Content ......................................60 These codes are used to distinguish between seleral "flavor" for a successful response ... in our case we have a succesful describe BUT the client is requested to continue at a different location ... Could also help to indicate different caching status ? typically such a response should not be cached no ? so it could be 207 "Implicit Redirection" ? hum ? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 4 15:25: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 PAA08986 for ; Wed, 4 Jun 2003 15:25:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54JP3V13094 for mmusic-archive@odin.ietf.org; Wed, 4 Jun 2003 15:25:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54JP3B13087 for ; Wed, 4 Jun 2003 15:25:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08961 for ; Wed, 4 Jun 2003 15:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ndqp-0007FH-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 15:23:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ndqo-0007FE-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 15:23:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54JNEB12948; Wed, 4 Jun 2003 15:23:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54JMtB12915 for ; Wed, 4 Jun 2003 15:22:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08826; Wed, 4 Jun 2003 15:22:51 -0400 (EDT) Message-Id: <200306041922.PAA08826@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , mmusic@ietf.org From: The IESG Date: Wed, 04 Jun 2003 15:22:51 -0400 Subject: [MMUSIC] Protocol Action: RTCP attribute in SDP to Proposed Standard Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'RTCP attribute in SDP' as a Proposed Standard. This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary The new version of RTP (draft-ietf-avt-rtp-new-12) relaxes the requirement in 1889 that the port number used for the Real Time Control Protocol (RTCP) must be one port number higher than the port chosen for an RTP stream. Because of this, protocols like the Session Description Protocol which use RTP now need a way to explicitly specify the port that will be used for an RTCP stream corresponding to an RTP stream; previously, SDP had no need for this capability since implementations just assumed that RTP/RTCP used consecutive numbers. So, this document proposes a new SDP attribute (a=rtcp:) that allows this change in RTP, and the proposed change to SDP, RTCP had a great deal of trouble traversing NATs in SDP-based applications (like SIP). The document therefore considers NAT traversal as a motivating case for the addition of this attribute. The use of this new attribute to facilitate NAT traversal is intended to be used in concert with STUN (RFC 3489). Working Group Summary The MMUSIC WG supported the advancement of this document. Protocol Quality Jon Peterson reviewed this specification for the IESG. RFC Editor Note: 2.1 The RTCP attribute last paragraph OLD: The RTCP attribute MAY be used as a media level attribute; it MUST NOT be used as a session level attribute. NEW: The RTCP attribute MAY be used as a media level attribute; it MUST NOT be used as a session level attribute. Though the examples below relate to a method that will return only unicast addresses, both unicast and multicast values are valid. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 4 19:24: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 TAA17133 for ; Wed, 4 Jun 2003 19:24:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54NOHf29697 for mmusic-archive@odin.ietf.org; Wed, 4 Jun 2003 19:24:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54NOGB29693 for ; Wed, 4 Jun 2003 19:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17118 for ; Wed, 4 Jun 2003 19:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NhaL-00018j-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 19:22:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NhaJ-00018g-00 for mmusic-web-archive@ietf.org; Wed, 04 Jun 2003 19:22:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54NMSB29632; Wed, 4 Jun 2003 19:22:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54NJEB29523 for ; Wed, 4 Jun 2003 19:19:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17021; Wed, 4 Jun 2003 19:19:10 -0400 (EDT) Message-Id: <200306042319.TAA17021@ietf.org> To: IETF-Announce: ; Cc: mmusic@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 04 Jun 2003 19:19:10 -0400 Subject: [MMUSIC] Last Call: SDP: Session Description Protocol to Proposed Standard Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Multiparty Multimedia Session Control Working Group to consider SDP: Session Description Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-18. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jun 5 11:21: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 LAA02076 for ; Thu, 5 Jun 2003 11:21:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FKYK13429 for mmusic-archive@odin.ietf.org; Thu, 5 Jun 2003 11:20:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FKYB13426 for ; Thu, 5 Jun 2003 11:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02023 for ; Thu, 5 Jun 2003 11:20:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwVl-0000GR-00 for mmusic-web-archive@ietf.org; Thu, 05 Jun 2003 11:18:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NwVk-0000GK-00 for mmusic-web-archive@ietf.org; Thu, 05 Jun 2003 11:18:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FIjB13331; Thu, 5 Jun 2003 11:18:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FHYB13253 for ; Thu, 5 Jun 2003 11:17:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01070 for ; Thu, 5 Jun 2003 11:17:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwSq-00008A-00 for mmusic@ietf.org; Thu, 05 Jun 2003 11:15:40 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19NwSp-00007q-00 for mmusic@ietf.org; Thu, 05 Jun 2003 11:15:39 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 05 Jun 2003 08:05:46 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Thu, 05 Jun 2003 08:05:46 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Thu, 05 Jun 2003 08:15:09 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19NwSb-0006PS-00 for ; Thu, 05 Jun 2003 08:15:25 -0700 Date: Thu, 05 Jun 2003 08:14:09 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_30,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #77 - 11 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-633779 ] SET_PARAMETER responses (SourceForge.net) 2. [ rtspspec-Bugs-634944 ] Restarting media not allowing seek (SourceForge.net) 3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net) 4. [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net) 5. [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies (SourceForge.net) 6. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net) 7. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net) 8. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net) 9. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net) 10. [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed (SourceForge.net) 11. [ rtspspec-Bugs-507408 ] clarify use of interleaved param (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 May 2003 09:28:56 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses Bugs item #633779, was opened at 2002-11-05 04:19 Message generated for change (Comment added) made by robla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&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: SET_PARAMETER responses Initial Comment: Clarify on the usage of SET_PARAMETER when no body is present. A correct syntax with unknown headers will result in a 200 response but also the understanding of a propreitary or new header will result in 200. Clarify that a requester should use the Require header with an option tag to ensure that the responder of the request really understands the propreitary or new header. Also write text recommending on the usage of parameters in the body with the motivation that they are simpler than using require and headers. But both case should be possible to use. How to handle a empty parameter list in the body should also be explained. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2003-05-28 09:28 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: how to respond if server doesn't understand parameter # Anders: maybe a require header to be used if necessary # Magnus: I can agree with just a clarification # Anders: for proprietary client request, it can expect proprietary response # Magnus: easier if just use body # Anders: don't need to specify more than that # Rob: I agree # Magnus: spec says that SET_PARAMETER can be used for keep alive # Magnus: it's possible to have SET_PARAMETER without body # RESOLUTION: Short explanation of SET_PARAMETER without body being allowed. No other changes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 May 2003 09:30:03 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-634944 ] Restarting media not allowing seek Bugs item #634944, was opened at 2002-11-07 04:24 Message generated for change (Comment added) made by robla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=634944&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Restarting media not allowing seek Initial Comment: The current proposal for what happens when a on-demand stream reaches its end is that a explicit seek to the begining is required to see the media from the begining. However how this work for media that does not allow seek needs to be clarififed. - I think a media dissalowing random access will still allow the media to be seen from the begining. - Also how the discovery of which time formats that will be allowed needs to be clarified. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2003-05-28 09:30 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: we should close the bug, can be solved by standard RTSP server side support # Magnus: some of the OMA DRM work may apply # Anders: maybe something that can be done in SDP. a=type? # Magnus: on demand media stored, but seeking not allowed. # Magnus: can be on the server side # Rob: only complexity is trying to have client interface before seek is tried # Rob: DVDs don't accomodate this, though # Anders: no way to "grey out" the seek buttons on DVD remote # Joerg: it would be possible to define SDP attribute, but we may end up in rathole trying to characterize all of the possible attributes (for speed, etc). # Magnus: I think RTSP will not have problems here. Current spec is fine # Rob: Agreed # RESOLUTION: close the bug as implemented on server ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=634944&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 May 2003 09:34:13 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL Bugs item #640272, was opened at 2002-11-18 12:19 Message generated for change (Comment added) made by robla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&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: Default way of deriving aggregate URL Initial Comment: Currently there is very little said on which aggregated control URL to use. The only given case is the a=control attribute in SDP at session level. In cases when one aggregates media stream that have no common SDP declaration or dependencies in other ways the URL can't be derived. Examples of such cases is when you would like to aggregate a session multiplexed retransmission stream with the original data stream, without requiring aggregatation between all media types part of a stream. Another example is aggregation of streams that are lacking a common SDP description but still can be intressting to aggregate. To fix this a way to derive what a valid aggregate URL is needs to be specified. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2003-05-28 09:34 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: this is problem when aggregate control done in not obvious way # Magnus: what happens when you try to aggregate things that aren't designed to be aggregated # Joerg: I think this would require a lot of work to make this work correctly # Magnus: solution is to solve this with non-aggregate control # Tom: how does client know # Magnus: reuse session id # Tom: what happens when you pass the session id with a different URL # Rob: it should be undefined # Magnus: it should return error # Rob: that's no more backward compatible # Magnus: do you have proposed wording 11.4 second paragraph # RESOLUTION: Tom to write up wording for 11.4 second paragraph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 May 2003 09:34:56 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved Bugs item #662436, was opened at 2003-01-04 18:01 Message generated for change (Comment added) made by robla 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 ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2003-05-28 09:34 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: we should leave this until RTP framing is done # Magnus: this is basically a feature request # Magnus: this might well be a separate draft # Rob: agreed # Aravind: agreed # Tom: we'll have to deal with this issue when DCCP comes along # Anders: I saw this in use # Tom: they might be using interleaving or not # RESOLUTION: separate draft for non-interleaving; narrow spec for interleaving ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 May 2003 09:43:41 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies Bugs item #631148, was opened at 2002-10-30 09:23 Message generated for change (Comment added) made by robla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631148&group_id=23194 Category: None Group: Fix for Draft Standard Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Better Info on usage of Proxies Initial Comment: The information on how RTSP works when there are proxies needs to be fleshed out. Suggest that both HTTP and SIP are studied. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2003-05-28 09:43 Message: Logged In: YES user_id=3796 From 28 April 2003 telecon (http://rtsp.org/2003/telecon/minutes14Apr.html): * Magnus: Tom, you seem to know the most of the folks here about RTSP proxies. Do you have some prose we can use? * Rob: we've got a whitepaper (http://docs.real.com/docs/rtsp.pdf) * Magnus: I'll look through this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631148&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 May 2003 14:33:40 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-745191 ] Appendix B - Clarification? Bugs item #745191, was opened at 2003-05-28 21:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194 Category: General Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve McKenna (stevemck) Assigned to: Rob Lanphier (robla) Summary: Appendix B - Clarification? Initial Comment: We are working on serving A/V content (MPEG4 primarily) for unicast on-demand clients only (no live feeds, no groups). This is a VOD single-viewer system. To make our server as scaleable as possible, we want to pre-timestamp RTP packets (stamp once, use thousands of times). When supporting PAUSE followed by random access repositioning, this gives us an RTP clock timeline that jumps at the moment of restart - backwards when seeking back, forwards when seeking forward. The PLAY response after repositioning does properly identify the new RTP timestamp related to the after-seek NPT in an 'RTP- info' field. Multiple Players have no problem with this - one in particular balks and points to Appendix B as the 'law' that demands we discard our approach. If we were to do 'just in time' stamping, our supported stream counts would drop some appreciable percentage, so it has real costs to do this. I can see why this makes a difference in live-feed models, but would be interested in thoughts as to why it is or is not of any critical importance in the specific case we are working. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Jun 2003 02:10:04 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-745191 ] Appendix B - Clarification? Bugs item #745191, was opened at 2003-05-28 23:33 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194 Category: General >Group: Fix - Discussed/Resolved Status: Open >Resolution: Accepted Priority: 5 Submitted By: Steve McKenna (stevemck) Assigned to: Rob Lanphier (robla) Summary: Appendix B - Clarification? Initial Comment: We are working on serving A/V content (MPEG4 primarily) for unicast on-demand clients only (no live feeds, no groups). This is a VOD single-viewer system. To make our server as scaleable as possible, we want to pre-timestamp RTP packets (stamp once, use thousands of times). When supporting PAUSE followed by random access repositioning, this gives us an RTP clock timeline that jumps at the moment of restart - backwards when seeking back, forwards when seeking forward. The PLAY response after repositioning does properly identify the new RTP timestamp related to the after-seek NPT in an 'RTP- info' field. Multiple Players have no problem with this - one in particular balks and points to Appendix B as the 'law' that demands we discard our approach. If we were to do 'just in time' stamping, our supported stream counts would drop some appreciable percentage, so it has real costs to do this. I can see why this makes a difference in live-feed models, but would be interested in thoughts as to why it is or is not of any critical importance in the specific case we are working. Thanks ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 11:10 Message: Logged In: YES user_id=302620 This has recently been discussed again. There are several reasons why the RTP timestamp usage you have is not the correct one. The correct RTP timestamp model is that the sent RTP timestamp increase continous with wall clock. So if one do a seek back to back with a playing the RTP timestamp will not jump. If one pause for 5 seconds the RTP timestamp of the packet when on continue the playout will be 5 seconds later. The reason for doing this is: - If one pause or do seek the RTP timestamp is not inline with what RTCP report. RTCP needs continous RTP timestamp against real time. Therefore strange synchronization problems may occur. Also the RTT measurement in RTCP may be effected. - A common model that works independently of use case gives minimal implementation effort for all clients. - Using a common RTP timestamp without any random offset between different streams may be a security risks if one does encryption. - The implementation effort of maintaining a correct RTP timestamp is very small, at least if one implements this correctly. In my view it costs one extra 32 bit addition per RTP packet. And at every PLAY request and media jump a couple of extra instructions to calculate the RTP timestamp offset for the first packet. If you have more questions on this issue please email to mailing list mmusic@ietf.org. See www.ietf.org, wg page, mmusic for instructions how to subscribe. This bug is resolved and another tracker item exist, see bug 507882. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=745191&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Jun 2003 02:31:38 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules Bugs item #739845, was opened at 2003-05-19 14:13 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: "a=range" is missing IANA registration and clear rules Initial Comment: The "a=range" SDP attribute in appendix C.1.5 of the specification has some issues. 1. The parameter is not registered with IANA. Write IANA registration request. 2. The parameter is not clearly defined in regards to ABNF. Write ABNF definition for attribute don't forget extension for new format types. 3. Is multiple range specifications allowed? 4. Write normative language on usage regarding session and media level. 5. Is multiple instances for the different formats allowed? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 11:31 Message: Logged In: YES user_id=302620 Has been discussed at telecon 1. Write IANA registration 2. Write ABNF 3. No 4. Yes, will be included. 5. No ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Jun 2003 03:45:18 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules Bugs item #739845, was opened at 2003-05-19 14:13 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: "a=range" is missing IANA registration and clear rules Initial Comment: The "a=range" SDP attribute in appendix C.1.5 of the specification has some issues. 1. The parameter is not registered with IANA. Write IANA registration request. 2. The parameter is not clearly defined in regards to ABNF. Write ABNF definition for attribute don't forget extension for new format types. 3. Is multiple range specifications allowed? 4. Write normative language on usage regarding session and media level. 5. Is multiple instances for the different formats allowed? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 12:45 Message: Logged In: YES user_id=302620 Changes are now editied in. See IANA.tex and SDP.tex ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 11:31 Message: Logged In: YES user_id=302620 Has been discussed at telecon 1. Write IANA registration 2. Write ABNF 3. No 4. Yes, will be included. 5. No ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Jun 2003 08:07:28 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed Bugs item #536713, was opened at 2002-03-29 13:07 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=536713&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jaehwan, Kim (kjh1905m) Assigned to: Magnus Westerlund (magwes) Summary: ControlURL parsing order must be changed Initial Comment: Last winter, magwes suggested using new RTSP spec, RFC 2616. So we need to change parsing order of Control URL which was defined in C.1.1 of draft-ietf-mmusic- rfc2326bis-00.txt. ------ C.1.1 Control URL 1. the RTSP Content-Base field; 2. the RTSP Content-Location field; 3. the RTSP request URL. ------ It is reasonable to remove Content-Base. Because in the RFC 2616... ------- 19.6.3 Changes from RFC 2068 skip... Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML [45]. ------- (even I think Content-Base was implemented widely at lease in the streaming world ) The usage of Content-Base is identical with Content- Location. For this reason,we had better use Content- Location. Jaehwan, Kim(kjh1905m@serome.co.kr) Serome Technology, inc. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 17:07 Message: Logged In: YES user_id=302620 No counter claim made for very long time. The bug is being closed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:04 Message: Logged In: YES user_id=302620 Actually it seems that Content-base actually is useful for giving session descriptions there base-URL. Therefore I believe it should be keept. The Content-base has been moved to the RTSP spec. Content-Location has a slightly different meaning whit some implications. Therefore there is no need to change the parsing order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=536713&group_id=23194 --__--__-- Message: 11 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 05 Jun 2003 08:13:26 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507408 ] clarify use of interleaved param Bugs item #507408, was opened at 2002-01-23 09:27 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507408&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tommy (realtommy) Assigned to: Magnus Westerlund (magwes) Summary: clarify use of interleaved param Initial Comment: As noted in last RTSP telecon, certain implementations use "interleaved" without a parameter "=n" in the Transport header. Please clarify that the parameter is REQUIRED. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-05 17:13 Message: Logged In: YES user_id=302620 This bug is fixed, no comments on solution. Closing item. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:45 Message: Logged In: YES user_id=302620 It is evident from the ABNF and also written in the text now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507408&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 Sun Jun 8 15:34: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 PAA28892 for ; Sun, 8 Jun 2003 15:32:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h58JVoC18897 for mmusic-archive@odin.ietf.org; Sun, 8 Jun 2003 15:31:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58JTtB18823 for ; Sun, 8 Jun 2003 15:29:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28821 for ; Sun, 8 Jun 2003 15:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P5nf-0004y5-00 for mmusic-web-archive@ietf.org; Sun, 08 Jun 2003 15:25:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P5lj-0004xI-00 for mmusic-web-archive@ietf.org; Sun, 08 Jun 2003 15:25:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58JPpB18711; Sun, 8 Jun 2003 15:25:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h57I5oB16771 for ; Sat, 7 Jun 2003 14:05:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17430 for ; Sat, 7 Jun 2003 14:05:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Oi2e-0004tR-00 for mmusic@ietf.org; Sat, 07 Jun 2003 14:03:48 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19Oi2d-0004tK-00 for mmusic@ietf.org; Sat, 07 Jun 2003 14:03:47 -0400 Received: by fox.iptel.org (Postfix, from userid 534) id F3A56232; Sat, 7 Jun 2003 20:05:09 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-172-210.reverse.qdsl-home.de [212.202.172.210]) by fox.iptel.org (Postfix) with ESMTP id 50507232; Sat, 7 Jun 2003 20:05:09 +0200 (CEST) Message-Id: <5.2.0.9.0.20030607184521.03371c48@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 07 Jun 2003 18:47:51 +0200 To: yon@dialout.net From: Jiri Kuthan Cc: mmusic@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-12.1 required=5.0 tests=AWL,BAYES_00 version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) Subject: [MMUSIC] comedia: what happens if both SIP UAs want to be active Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , David, can you please explain me how SIP signaling proceeds if two UAs both with to have direction=active, since they are behind symmetric NATs? Thanks, -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Jun 8 17:44:15 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 RAA00864 for ; Sun, 8 Jun 2003 17:42:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h58LfoW27109 for mmusic-archive@odin.ietf.org; Sun, 8 Jun 2003 17:41:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58LdoB27051 for ; Sun, 8 Jun 2003 17:39:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00812 for ; Sun, 8 Jun 2003 17:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P7py-0005Re-00 for mmusic-web-archive@ietf.org; Sun, 08 Jun 2003 17:36:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19P7o1-0005Rb-00 for mmusic-web-archive@ietf.org; Sun, 08 Jun 2003 17:36:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58LaOB26098; Sun, 8 Jun 2003 17:36:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58LVtB25999 for ; Sun, 8 Jun 2003 17:31:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00728 for ; Sun, 8 Jun 2003 17:31:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19P7jc-0005Qc-00 for mmusic@ietf.org; Sun, 08 Jun 2003 17:29:52 -0400 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 19P7jb-0005QZ-00 for mmusic@ietf.org; Sun, 08 Jun 2003 17:29:51 -0400 Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-283.mrrmnh.adelphia.net [68.64.105.27]) (authenticated) by host110.216.41.119.conversent.net (8.10.2/8.10.2) with ESMTP id h58LWbr20523; Sun, 8 Jun 2003 17:32:47 -0400 Message-Id: <5.1.1.6.0.20030608173054.041d5008@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 08 Jun 2003 17:31:12 -0400 To: Jiri Kuthan , yon@dialout.net From: David Yon Subject: Re: [MMUSIC] comedia: what happens if both SIP UAs want to be active Cc: mmusic@ietf.org In-Reply-To: <5.2.0.9.0.20030607184521.03371c48@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , If they both want to be active, the negotiation fails. At 12:47 PM 6/7/2003, Jiri Kuthan wrote: >David, > >can you please explain me how SIP signaling proceeds if two UAs both >with to have direction=active, since they are behind symmetric NATs? > >Thanks, > >-jiri > >-- >Jiri Kuthan http://iptel.org/~jiri/ > >_______________________________________________ >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 Jun 9 23:59:15 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 XAA00033 for ; Mon, 9 Jun 2003 23:59:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A3wn330706 for mmusic-archive@odin.ietf.org; Mon, 9 Jun 2003 23:58:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3wmB30703 for ; Mon, 9 Jun 2003 23:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00006 for ; Mon, 9 Jun 2003 23:58:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PaFZ-0001IB-00 for mmusic-web-archive@ietf.org; Mon, 09 Jun 2003 23:56:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PaFY-0001I7-00 for mmusic-web-archive@ietf.org; Mon, 09 Jun 2003 23:56:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3wgB30695; Mon, 9 Jun 2003 23:58:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3ImB28603 for ; Mon, 9 Jun 2003 23:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29253 for ; Mon, 9 Jun 2003 23:18:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PZcr-00014S-00 for mmusic@ietf.org; Mon, 09 Jun 2003 23:16:45 -0400 Received: from [209.75.253.217] (helo=shego.dbc.mtview.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19PZcr-00014D-00 for mmusic@ietf.org; Mon, 09 Jun 2003 23:16:45 -0400 Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h5A3HeHQ000604; Mon, 9 Jun 2003 20:17:41 -0700 (PDT) Date: Mon, 9 Jun 2003 20:17:40 -0700 From: Marshall Rose To: mmusic@ietf.org Message-Id: <20030609201740.10fcae6d.mrose+mtr.netnews@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] can i get a sense from the room? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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. may i draw your attention to the I-D: http://www.ietf.org/internet-drafts/draft-hildebrand-xmpp-sdpng-00.txt which introduces tins. in a nutshell, tins is sip-like semantics for sdpng negotiation over xmpp, leading to VoIP, etc., being initiated from xmpp. can i get a sense from folks as to how appropriate it would be to consider this in the context of the working group? thanks! /mtr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jun 10 15:39:53 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 PAA15061 for ; Tue, 10 Jun 2003 15:39:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AJdPp20806 for mmusic-archive@odin.ietf.org; Tue, 10 Jun 2003 15:39:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJdPB20803 for ; Tue, 10 Jun 2003 15:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14939 for ; Tue, 10 Jun 2003 15:39:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Povo-0001bl-00 for mmusic-web-archive@ietf.org; Tue, 10 Jun 2003 15:37:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Povn-0001bi-00 for mmusic-web-archive@ietf.org; Tue, 10 Jun 2003 15:37:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJdIB20789; Tue, 10 Jun 2003 15:39:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJcQB20616 for ; Tue, 10 Jun 2003 15:38:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14901 for ; Tue, 10 Jun 2003 15:38:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pour-0001al-00 for mmusic@ietf.org; Tue, 10 Jun 2003 15:36:21 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Pouq-0001ah-00 for mmusic@ietf.org; Tue, 10 Jun 2003 15:36:20 -0400 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.10.1) with ESMTP id h5AJc0kL016412; Tue, 10 Jun 2003 21:38:00 +0200 (MEST) Message-ID: <3EE633BE.7050002@tzi.uni-bremen.de> Date: Tue, 10 Jun 2003 21:38:38 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: csp@csperkins.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC in Vienna Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we are about to schedule a meeting slot for the Vienna IETF. We are currently planning for a single 2.5 hour slot. We will go for an additional hour if necessary. So please provide us with your input so that we can properly assess how much time we will need. We expect items to be discussed to include - Various SDP extensions (just completing the last bits and pieces) - SDPng - RTSP (quite a lot of it, actually) - IMGs (also quite a bit) Those wanting agenda time at the meeting should contact the working group chairs by 20 June. Submitting a draft does not automatically provide agenda time. Please also note that meetings are meant to discuss and resolve issues, not to present new ideas. You are reminded that the cut-off date for -00 Internet Draft submissions is Monday, 23 June at 9:00am EST (GMT -05:00). Unless you have prior approval from the chairs, -00 submissions should have filenames with the format draft-yourname-mmusic-...-00.txt. Be advised that updates to -00 drafts received after 23 June will not be accepted. All other Internet-Draft submissions must be made by Monday, 30 June at 9:00am EST. Drafts which are submitted late and do not make the cutoff date will not be discussed at the meeting. Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jun 10 19:43: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 TAA22981 for ; Tue, 10 Jun 2003 19:43:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ANgbi05380 for mmusic-archive@odin.ietf.org; Tue, 10 Jun 2003 19:42:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANgaB05377 for ; Tue, 10 Jun 2003 19:42:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22973 for ; Tue, 10 Jun 2003 19:42:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Psj9-0003Ax-00 for mmusic-web-archive@ietf.org; Tue, 10 Jun 2003 19:40:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Psj9-0003Au-00 for mmusic-web-archive@ietf.org; Tue, 10 Jun 2003 19:40:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANgSB05368; Tue, 10 Jun 2003 19:42:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANf8B05342 for ; Tue, 10 Jun 2003 19:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22958 for ; Tue, 10 Jun 2003 19:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pshi-0003AK-00 for mmusic@ietf.org; Tue, 10 Jun 2003 19:39:02 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19Pshi-0003AH-00 for mmusic@ietf.org; Tue, 10 Jun 2003 19:39:02 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h5ANf5Dj014124 for ; Tue, 10 Jun 2003 16:41:05 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h5ANf5jj014122; Tue, 10 Jun 2003 16:41:05 -0700 (PDT) Message-Id: <4.3.1.1.20030610163544.00b96e10@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 10 Jun 2003 16:40:03 -0700 To: mmusic@ietf.org From: Ross Finlayson In-Reply-To: <20030609201740.10fcae6d.mrose+mtr.netnews@dbc.mtview.ca.us > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] What is "application/x-rtsp-mh" (mentioned in the RTSP spec)? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , In the example given in section 15.3 of the RTSP specification, the client sends a "DESCRIBE" that includes the following "Accept:" header: Accept: application/x-rtsp-mh, application/sdp What is "application/x-rtsp-mh", and is there any reason to be mentioning it in this example? (I presume not.) It seems like a mistake for the specification to be using experimental (non-IANA-assigned) MIME types in its examples. Is there any reason not to change this to: Accept: application/sdp ? Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 02:38: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 CAA27247 for ; Wed, 11 Jun 2003 02:38:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B6cYB10963 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 02:38:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6cXB10960 for ; Wed, 11 Jun 2003 02:38:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27242 for ; Wed, 11 Jun 2003 02:38:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PzDc-0005Lb-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 02:36:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PzDb-0005LX-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 02:36:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6cOB10949; Wed, 11 Jun 2003 02:38:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6bvB10930 for ; Wed, 11 Jun 2003 02:37:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27134 for ; Wed, 11 Jun 2003 02:37:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PzD2-0005LC-00 for mmusic@ietf.org; Wed, 11 Jun 2003 02:35:48 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19PzD1-0005L9-00 for mmusic@ietf.org; Wed, 11 Jun 2003 02:35:47 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5B6bl0J004130; Wed, 11 Jun 2003 08:37:47 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP7KZSP; Wed, 11 Jun 2003 08:37:43 +0200 Message-ID: <3EE6CD90.8080801@ericsson.com> Date: Wed, 11 Jun 2003 08:34:56 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ross Finlayson CC: mmusic@ietf.org Subject: Re: [MMUSIC] What is "application/x-rtsp-mh" (mentioned in the RTSP spec)? References: <4.3.1.1.20030610163544.00b96e10@laptop-localhost> 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 Ross, Ross Finlayson wrote: > In the example given in section 15.3 of the RTSP specification, the > client sends a "DESCRIBE" that includes the following "Accept:" header: > > Accept: application/x-rtsp-mh, application/sdp > > What is "application/x-rtsp-mh", and is there any reason to be > mentioning it in this example? (I presume not.) It seems like a > mistake for the specification to be using experimental > (non-IANA-assigned) MIME types in its examples. Is there any reason not > to change this to: > > Accept: application/sdp > ? > I think application/x-rtsp-mh is a bogus MIME type. However I think there is reason to include multiple types as a difference to a single one as it clarifies that capability. However either a note or a change of the MIME type to something registered and useful could be an improvement of the example. I would yet again put out a big caution to all people reading the examples in the 03 version of the draft. They are not updated and contains a lot of errors. We have so far concentrated on correcting the specification text before fixing the examples. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 04:38: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 EAA29502 for ; Wed, 11 Jun 2003 04:38:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B8cTr19216 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 04:38:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8cTB19213 for ; Wed, 11 Jun 2003 04:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29495 for ; Wed, 11 Jun 2003 04:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q15i-0005t9-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 04:36:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q15h-0005t6-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 04:36:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8cGB19194; Wed, 11 Jun 2003 04:38:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8bRB18957 for ; Wed, 11 Jun 2003 04:37:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29458 for ; Wed, 11 Jun 2003 04:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q14i-0005st-00 for mmusic@ietf.org; Wed, 11 Jun 2003 04:35:20 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19Q14h-0005sk-00 for mmusic@ietf.org; Wed, 11 Jun 2003 04:35:19 -0400 Received: from [192.168.104.23] ([::ffff:12.212.102.143]) (AUTH: LOGIN robla, ) by capefear.real.com with esmtp; Wed, 11 Jun 2003 01:36:46 -0700 Subject: Re: [MMUSIC] What is "application/x-rtsp-mh" (mentioned in the RTSP spec)? From: Rob Lanphier To: Magnus Westerlund Cc: Ross Finlayson , mmusic@ietf.org In-Reply-To: <3EE6CD90.8080801@ericsson.com> References: <4.3.1.1.20030610163544.00b96e10@laptop-localhost> <3EE6CD90.8080801@ericsson.com> Message-Id: <1055320629.27132.53.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 11 Jun 2003 01:37:10 -0700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Magnus here. I think application/x-rtsp-mh actually meant something in RealNetworks' really early RTSP implementations, but even we dropped it long, long ago. This may be a good place to put in an SDPng example if we were feeling adventurous. Rob On Tue, 2003-06-10 at 23:34, Magnus Westerlund wrote: > Hi Ross, > > Ross Finlayson wrote: > > In the example given in section 15.3 of the RTSP specification, the > > client sends a "DESCRIBE" that includes the following "Accept:" header: > > > > Accept: application/x-rtsp-mh, application/sdp > > > > What is "application/x-rtsp-mh", and is there any reason to be > > mentioning it in this example? (I presume not.) It seems like a > > mistake for the specification to be using experimental > > (non-IANA-assigned) MIME types in its examples. Is there any reason not > > to change this to: > > > > > Accept: application/sdp > > ? > > > > I think application/x-rtsp-mh is a bogus MIME type. However I think > there is reason to include multiple types as a difference to a single > one as it clarifies that capability. However either a note or a change > of the MIME type to something registered and useful could be an > improvement of the example. > > I would yet again put out a big caution to all people reading the > examples in the 03 version of the draft. They are not updated and > contains a lot of errors. We have so far concentrated on correcting the > specification text before fixing the examples. > > 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@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 10:33:53 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 KAA11447 for ; Wed, 11 Jun 2003 10:33:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BEXTu03405 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 10:33:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEXTm03402 for ; Wed, 11 Jun 2003 10:33:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11425 for ; Wed, 11 Jun 2003 10:33:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q6dD-0000kc-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 10:31:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q6dC-0000kY-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 10:31:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEWim03374; Wed, 11 Jun 2003 10:32:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BETqm03207 for ; Wed, 11 Jun 2003 10:29:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11194 for ; Wed, 11 Jun 2003 10:29:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q6Zi-0000is-00 for mmusic@ietf.org; Wed, 11 Jun 2003 10:27:42 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19Q6Zg-0000ip-00 for mmusic@ietf.org; Wed, 11 Jun 2003 10:27:41 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h5BETgav059752; Wed, 11 Jun 2003 10:29:42 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 11 Jun 2003 10:29:42 -0400 From: Colin Perkins To: Joerg Ott Cc: mmusic@ietf.org Subject: Re: [MMUSIC] MMUSIC in Vienna Message-Id: <20030611102942.7d09e687.csp@csperkins.org> In-Reply-To: <3EE633BE.7050002@tzi.uni-bremen.de> References: <3EE633BE.7050002@tzi.uni-bremen.de> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Joerg Ott writes: > Folks, > > we are about to schedule a meeting slot for the Vienna IETF. We are > currently planning for a single 2.5 hour slot. We will go for an > additional hour if necessary. So please provide us with your input > so that we can properly assess how much time we will need. > > We expect items to be discussed to include > - Various SDP extensions (just completing the last bits and pieces) > - SDPng > - RTSP (quite a lot of it, actually) > - IMGs (also quite a bit) > > Those wanting agenda time at the meeting should contact the working group > chairs by 20 June. Submitting a draft does not automatically provide > agenda time. Please also note that meetings are meant to discuss and > resolve issues, not to present new ideas. > > You are reminded that the cut-off date for -00 Internet Draft submissions > is Monday, 23 June at 9:00am EST (GMT -05:00). Unless you have prior > approval from the chairs, -00 submissions should have filenames with the > format draft-yourname-mmusic-...-00.txt. Be advised that updates to -00 > drafts received after 23 June will not be accepted. Note also that, if you are submitting a draft-ietf-mmusic-...-00 draft, you need to contact the chairs immediately (such drafts must be approved by 16th June, even though they do not need to be submitted until 23rd June). -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 10:52: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 KAA12108 for ; Wed, 11 Jun 2003 10:52:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BEqJU05244 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 10:52:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEqIm05241 for ; Wed, 11 Jun 2003 10:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12088 for ; Wed, 11 Jun 2003 10:52:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q6vR-0000rh-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 10:50:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q6vQ-0000re-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 10:50:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEqCm05192; Wed, 11 Jun 2003 10:52:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEprm05155 for ; Wed, 11 Jun 2003 10:51:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12073 for ; Wed, 11 Jun 2003 10:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q6v1-0000rN-00 for mmusic@ietf.org; Wed, 11 Jun 2003 10:49:43 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Q6v0-0000rK-00 for mmusic@ietf.org; Wed, 11 Jun 2003 10:49:43 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5BEpk0J002089 for ; Wed, 11 Jun 2003 16:51:47 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP7PAJR; Wed, 11 Jun 2003 16:51:44 +0200 Message-ID: <3EE74157.40101@ericsson.com> Date: Wed, 11 Jun 2003 16:48:55 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP core specification author Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am happy to announce that we RTSP authors has become one more. We welcome Aravind Narasimhan as a co-author of the draft-ietf-mmusic-rfc2326bis-??. We also are positive that a new version of the RTSP specification will be available before the Vienna IETF 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 14:26:54 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 OAA20463 for ; Wed, 11 Jun 2003 14:26:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BIQQG23630 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 14:26:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BIQQm23627 for ; Wed, 11 Jun 2003 14:26:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20456 for ; Wed, 11 Jun 2003 14:26:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QAGh-0002Wh-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 14:24:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QAGg-0002We-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 14:24:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BIQJm23619; Wed, 11 Jun 2003 14:26:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BIPBm23568 for ; Wed, 11 Jun 2003 14:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20421 for ; Wed, 11 Jun 2003 14:25:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QAFU-0002Vk-00 for mmusic@ietf.org; Wed, 11 Jun 2003 14:23:04 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19QAFT-0002Vf-00 for mmusic@ietf.org; Wed, 11 Jun 2003 14:23:03 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h5BIP2b2042807 for ; Wed, 11 Jun 2003 11:25:02 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h5BIP2x0042804; Wed, 11 Jun 2003 11:25:02 -0700 (PDT) Message-Id: <4.3.1.1.20030611111615.00c754a0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 11 Jun 2003 11:23:27 -0700 To: mmusic@ietf.org From: Ross Finlayson Subject: Re: [MMUSIC] What is "application/x-rtsp-mh" (mentioned in the RTSP spec)? In-Reply-To: <3EE6CD90.8080801@ericsson.com> References: <4.3.1.1.20030610163544.00b96e10@laptop-localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >I would yet again put out a big caution to all people reading the examples >in the 03 version of the draft. They are not updated and contains a lot of >errors. We have so far concentrated on correcting the specification text >before fixing the examples. For a specification as large and complex as RTSP, the examples are very important, because - rightly or wrongly - people implementing the specification will tend to use the examples as guidelines, without always reading the rest of the specification in detail. For instance, I raised the question about the "application/x-rtsp-mh" MIME type because I learned about a client (Kasenna) that was including it in their "Accept:" headers. Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 21:10: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 VAA11178 for ; Wed, 11 Jun 2003 21:10:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C1AMj23967 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 21:10:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1AMm23964 for ; Wed, 11 Jun 2003 21:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11161 for ; Wed, 11 Jun 2003 21:10:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QGZa-0005m6-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 21:08:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QGZa-0005m3-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 21:08:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1AEm23956; Wed, 11 Jun 2003 21:10:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C196m23892 for ; Wed, 11 Jun 2003 21:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11118 for ; Wed, 11 Jun 2003 21:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QGYN-0005lS-00 for mmusic@ietf.org; Wed, 11 Jun 2003 21:06:59 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19QGYM-0005lB-00 for mmusic@ietf.org; Wed, 11 Jun 2003 21:06:58 -0400 Received: from phys-ha1mpkb.eng.sun.com ([129.146.14.51]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5C18WLv000684; Wed, 11 Jun 2003 18:08:32 -0700 (PDT) Received: from jamba (jamba [129.146.125.67]) by phys-ha1mpkb.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA21633; Wed, 11 Jun 2003 18:08:31 -0700 (PDT) Message-Id: <200306120108.SAA21633@phys-ha1mpkb.eng.sun.com> Date: Wed, 11 Jun 2003 18:08:31 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan To: mmusic@ietf.org, csp@csperkins.org Cc: jo@tzi.uni-bremen.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LcKFoCA8kgit5TUVxgvA4w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Subject: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , I have a few questions and comments on draft-ietf-mmusic-sdp-bwparam-03.txt: 1. Page 9, the last few lines - What is the difference between 'RTP-based media stream' and 'RTP transport' here? It's not very clear when the session level TIAS value can be used. 2. Section 6.2.3, 2nd paragraph - it would be good to clarify that this entire paragraph refers to the media level values. This paragraph is a little confusing to read..it might help to mention explicitly that it is RECOMMENDED to use both the AS and TIAS fields; AS for backwards compatibility, older implementations would ignore the TIAS field; TIAS would be recognized by newer and compliant implementations, which must ignore the AS value. 3. 6.3, 2nd paragraph - here too it might help clarity to assert the 'MUST NOT' case , before the 'MAY' case. 4. 6.3, is there any ambiguity in the last paragraph? For instance, is it ok to *not* have maxprate if one or the other of TIAS or the max packet rate for the transport is not available? 5. It would be great to have a complete example of SDP using TIAS and maxprate attributes. thanks geetha internet: geetha.srikantan@sun.com > To: mmusic@ietf.org > cc: jo@tzi.uni-bremen.de > From: Colin Perkins > Date: Thu, 29 May 2003 09:01:32 -0400 > Subject: [MMUSIC] WG last call: draft-ietf-mmusic-sdp-bwparam-03.txt > X-BeenThere: mmusic@ietf.org > X-Mailman-Version: 2.0.12 > List-Unsubscribe: , > List-Id: Multiparty Multimedia Session Control Working Group > List-Post: > List-Help: > List-Subscribe: , > > This is to announce a working group last call on the Transport Independent > Bandwidth Modifier for SDP . Please > send any final comments on this draft to the mailing list by Friday, 13th > June 2003. If no substantive issues are raised by that time, we propose to > ask the IESG to publish this as a Proposed Standard RFC. > > -- > Colin Perkins > http://csperkins.org/ > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 21:14: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 VAA11262 for ; Wed, 11 Jun 2003 21:14:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C1ECg24073 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 21:14:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1ECm24070 for ; Wed, 11 Jun 2003 21:14:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11259 for ; Wed, 11 Jun 2003 21:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QGdJ-0005nA-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 21:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QGdI-0005n7-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 21:12:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1E2m24051; Wed, 11 Jun 2003 21:14:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1DHm24026 for ; Wed, 11 Jun 2003 21:13:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11224 for ; Wed, 11 Jun 2003 21:13:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QGcP-0005mq-00 for mmusic@ietf.org; Wed, 11 Jun 2003 21:11:09 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19QGcP-0005mn-00 for mmusic@ietf.org; Wed, 11 Jun 2003 21:11:09 -0400 Received: from phys-ha1mpkb.eng.sun.com ([129.146.14.51]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5C1DEYU001601 for ; Wed, 11 Jun 2003 19:13:14 -0600 (MDT) Received: from jamba (jamba [129.146.125.67]) by phys-ha1mpkb.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA23147 for ; Wed, 11 Jun 2003 18:13:13 -0700 (PDT) Message-Id: <200306120113.SAA23147@phys-ha1mpkb.eng.sun.com> Date: Wed, 11 Jun 2003 18:13:13 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CnbUK0yrvNbN1OykNL4nKg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Subject: [MMUSIC] Question about draft-ietf-mmusic-sdp-new-13.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: , A question about the new SDP draft.: On Page 15, 1st paragraph, 4th line: `"b=CT.." line should be...' is this a 'SHOULD' ? It contradicts with the previous paragraphs which say that this is an optional attribute. thanks geetha internet: geetha.srikantan@sun.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Jun 11 21:56:46 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 VAA11859 for ; Wed, 11 Jun 2003 21:56:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C1uJE26220 for mmusic-archive@odin.ietf.org; Wed, 11 Jun 2003 21:56:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1uJm26217 for ; Wed, 11 Jun 2003 21:56:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11848 for ; Wed, 11 Jun 2003 21:56:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QHI3-0005x0-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 21:54:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QHI2-0005wx-00 for mmusic-web-archive@ietf.org; Wed, 11 Jun 2003 21:54:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1uAm26207; Wed, 11 Jun 2003 21:56:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C1ttm26185 for ; Wed, 11 Jun 2003 21:55:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11844 for ; Wed, 11 Jun 2003 21:55:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QHHg-0005wu-00 for mmusic@ietf.org; Wed, 11 Jun 2003 21:53:48 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19QHHe-0005wr-00 for mmusic@ietf.org; Wed, 11 Jun 2003 21:53:47 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h5C1tnav068148; Wed, 11 Jun 2003 21:55:51 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 11 Jun 2003 21:55:49 -0400 From: Colin Perkins To: Geetha Srikantan Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Question about draft-ietf-mmusic-sdp-new-13.txt Message-Id: <20030611215549.19f43ea3.csp@csperkins.org> In-Reply-To: <200306120113.SAA23147@phys-ha1mpkb.eng.sun.com> References: <200306120113.SAA23147@phys-ha1mpkb.eng.sun.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Geetha Srikantan writes: > > A question about the new SDP draft.: > > On Page 15, 1st paragraph, 4th line: > `"b=CT.." line should be...' > is this a 'SHOULD' ? It contradicts with the previous paragraphs > which say that this is an optional attribute. I don't see the contradiction. The "b=" modifier is optional, but may be useful in some cases. One of these cases it to indicate that the session bandwidth differs from that which may be implied by the scope. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jun 12 04:34: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 EAA00653 for ; Thu, 12 Jun 2003 04:34:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C8XXb31404 for mmusic-archive@odin.ietf.org; Thu, 12 Jun 2003 04:33:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C8XXm31401 for ; Thu, 12 Jun 2003 04:33:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00598 for ; Thu, 12 Jun 2003 04:33:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QNUT-00003n-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 04:31:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QNUS-00003k-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 04:31:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C8XOm31392; Thu, 12 Jun 2003 04:33:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C8V3m31256 for ; Thu, 12 Jun 2003 04:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00571 for ; Thu, 12 Jun 2003 04:31:00 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QNS3-00003I-00 for mmusic@ietf.org; Thu, 12 Jun 2003 04:28:55 -0400 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 19QNS2-00003F-00 for mmusic@ietf.org; Thu, 12 Jun 2003 04:28:54 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 797E45D3A5 for ; Thu, 12 Jun 2003 10:30:59 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA23431 for ; Thu, 12 Jun 2003 10:30:59 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p2/8.8.5-1.2.2m-19990317) with ESMTP id KAA05029 for ; Thu, 12 Jun 2003 10:30:57 +0200 (MEST) To: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 12 Jun 2003 10:22:18 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 12/06/2003 10:32:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] stream switching Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Dear MMUSICers, I have been seeking feedback about the stream switching use cases and pending requirements described in: http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-req-00.txt I would like to first check a few fundamentals: * Do we agree that constant bit rate UDP (RTP on UDP unicast) streaming is not a good idea on networks that do not have "ample" bandwidth ? (i.e. congestion control etc) Assuming the answer is yes: I remember that frame skipping and FGS was briefly discussed in SF as alternatives to Stream Switching, my answer was that frame skipping was not capable of covering a wide enough bit rate range and that FGS was not a primary target because of its lack of acceptance (at least today) in the industry etc Also a fundamental objection to these techniques is that they are very codec specific... So my next question is: * Can we say that there is a concensus that Stream Switching is a good candidate for rate and congestion control in streaming (i.e. in the context of RFC3448) ? regards, Philippe Gentric http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jun 12 05:21: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 FAA01535 for ; Thu, 12 Jun 2003 05:21:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C9LEa02681 for mmusic-archive@odin.ietf.org; Thu, 12 Jun 2003 05:21:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9LEm02678 for ; Thu, 12 Jun 2003 05:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01529 for ; Thu, 12 Jun 2003 05:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOEc-0000Jy-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 05:19:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QOEb-0000Jv-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 05:19:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9L8m02664; Thu, 12 Jun 2003 05:21:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9KIm02625 for ; Thu, 12 Jun 2003 05:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01518 for ; Thu, 12 Jun 2003 05:20:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QODi-0000Jc-00 for mmusic@ietf.org; Thu, 12 Jun 2003 05:18:10 -0400 Received: from mail.informatik.uni-ulm.de ([134.60.68.63]) by ietf-mx with esmtp (Exim 4.12) id 19QODh-0000JX-00 for mmusic@ietf.org; Thu, 12 Jun 2003 05:18:09 -0400 Received: from [134.60.77.31] (helo=lamagra) by mail.informatik.uni-ulm.de with smtp (Exim 3.36 #1) id 19QOFi-0000eD-00; Thu, 12 Jun 2003 11:20:14 +0200 Message-ID: <002401c330c4$83221cc0$1f4d3c86@lamagra> From: "Andreas Kassler" To: , References: Subject: Re: [MMUSIC] stream switching Date: Thu, 12 Jun 2003 11:25:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 > Dear MMUSICers, > > I have been seeking feedback about the stream switching > use cases and pending requirements described in: > http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-re q-00.txt > > I would like to first check a few fundamentals: > > * Do we agree that constant bit rate UDP (RTP on UDP unicast) > streaming is not a good idea on networks that do not have "ample" bandwidth ? > (i.e. congestion control etc) > > Assuming the answer is yes: > > I remember that frame skipping and FGS was briefly discussed in SF > as alternatives to Stream Switching, my answer was that frame skipping > was not capable of covering a wide enough bit rate range and that FGS > was not a primary target because of its lack of acceptance (at least today) > in the industry etc Also a fundamental objection to these techniques is > that they are very codec specific... I think there are three main issues: - stream switching is end-to-end and can be seen as a reaction to congestion --> congestion control - additionally, there is a need to minimize the effects of packet drops in the case that there is congestion and it has not been detected yet (e.g. the routers are dropping packets but the receiver did not notice it yet). In this case it is important that the effects of packet drops on quality are minimized. This could be achieved by proper application level framing and DSCP marking, which may lead to automatic frame dropping in routers (e.g. all B-frame packets have lower priority than I-frame packets). - frame skipping at the sender does only lead to temporal scalability and limits the choices of user QoS scalability to the temporal domain. In contrast, when using stream switching, quality scalability or even spatial scalbility may be achieved. But this is up to the video provider, who has to encode the alternative streams in a proper way. However, the disadvantage of stream switching is the need for more resources at the server, as each video alternative consumes disc space. An alternative could be to use content delievray and adaptation overlay networks, that adapt the content of the video on the fly and thus scale the video to the available bandwidth. This could even be done TCP-friendly. > > So my next question is: > > * Can we say that there is a concensus that Stream Switching is a good > candidate for rate and congestion control in streaming (i.e. in the context of RFC3448) ? I would say it is a candidate, but I doubt you can do it in a TCP friendly way, unless you have very fine granular bandwidth steps between the alternative streams. Regards, Andreas Kassler > > > regards, > > > Philippe Gentric > http://www.platform4.philips.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 Jun 12 06:26:53 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 GAA02398 for ; Thu, 12 Jun 2003 06:26:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CAQR006557 for mmusic-archive@odin.ietf.org; Thu, 12 Jun 2003 06:26:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAQRm06554 for ; Thu, 12 Jun 2003 06:26:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02367 for ; Thu, 12 Jun 2003 06:26:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPFi-0000Vs-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 06:24:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QPFh-0000Vp-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 06:24:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAQKm06538; Thu, 12 Jun 2003 06:26:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAPIm06505 for ; Thu, 12 Jun 2003 06:25:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02359 for ; Thu, 12 Jun 2003 06:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPEb-0000Vc-00 for mmusic@ietf.org; Thu, 12 Jun 2003 06:23:09 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19QPEa-0000VZ-00 for mmusic@ietf.org; Thu, 12 Jun 2003 06:23:08 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5CAPEw2003162; Thu, 12 Jun 2003 12:25:14 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP7VCCL; Thu, 12 Jun 2003 12:25:14 +0200 Message-ID: <3EE8545D.90408@ericsson.com> Date: Thu, 12 Jun 2003 12:22:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: mmusic@ietf.org Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt References: <200306120108.SAA21633@phys-ha1mpkb.eng.sun.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, Thanks for the comments. Geetha Srikantan wrote: > I have a few questions and comments on draft-ietf-mmusic-sdp-bwparam-03.txt: > > 1. Page 9, the last few lines - What is the difference between 'RTP-based media > stream' and 'RTP transport' here? It's not very clear when the session level > TIAS value can be used. There is no difference, I can change the RTP-based media stream to "RTP transported media stream". The session level value is bit redundant. It is simply the sum of all media streams and reflect the total amount of bandwidth needed to accommodate this session. This can of course be calculated by a receiver. > > 2. Section 6.2.3, 2nd paragraph - it would be good to clarify that this entire > paragraph refers to the media level values. > This paragraph is a little confusing to read..it might help to mention > explicitly that it is RECOMMENDED to use both the AS and TIAS fields; > AS for backwards compatibility, older implementations would ignore the TIAS > field; TIAS would be recognized by newer and compliant implementations, > which must ignore the AS value. No, It does not only apply for the media level, but both levels. AS can be present at both levels, if one includes it at either level one is recommended to include TIAS also. I don't quite understand what you mean with confusing to read. The information you ask for is there: "..., it is RECOMMENDED to also include the "AS" modifier when using "TIAS"". Do you have a more concrete proposal on how reformulate the paragraph? > > 3. 6.3, 2nd paragraph - here too it might help clarity to assert the 'MUST NOT' > case , before the 'MAY' case. So you would like to be reformulated into something like this: "At the SDP session level, the maxprate value MUST be the sum of all media-level packet rates. The "maxprate" attribute MUST NOT be present at session level if the media streams use different transport. The attribute MAY be present if the media streams use the same transport. If the attribute is present at the session level it SHOULD also be present at the media level for all media streams." Is that better? If not please provide concrete proposals of the paragraph. > > 4. 6.3, is there any ambiguity in the last paragraph? For instance, is it ok to > *not* have maxprate if one or the other of TIAS or the max packet rate > for the transport is not available? Yes, if one can't derive a packet rate due to for example non packet based transport then its ok. However if you use TIAS and have a transport like IP/UDP/RTP you shall have it. Perhaps I should reformulate the sentence to be more strict and explanatory. > > 5. It would be great to have a complete example of SDP using TIAS and maxprate > attributes. > Yes, you are correct. I will look into it. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jun 12 07:14: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 HAA03301 for ; Thu, 12 Jun 2003 07:14:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBEE710198 for mmusic-archive@odin.ietf.org; Thu, 12 Jun 2003 07:14:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBEEm10195 for ; Thu, 12 Jun 2003 07:14:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03293 for ; Thu, 12 Jun 2003 07:14:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPzy-0000hh-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 07:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QPzy-0000he-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 07:12:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBE7m10185; Thu, 12 Jun 2003 07:14:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBDYm10167 for ; Thu, 12 Jun 2003 07:13:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03282 for ; Thu, 12 Jun 2003 07:13:31 -0400 (EDT) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPzK-0000hR-00 for mmusic@ietf.org; Thu, 12 Jun 2003 07:11:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19QPzJ-0000hO-00 for mmusic@ietf.org; Thu, 12 Jun 2003 07:11:26 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CBDV906428 for ; Thu, 12 Jun 2003 14:13:31 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 14:13:31 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 14:13:30 +0300 Received: from trebe006.NOE.Nokia.com ([172.22.232.181]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 14:12:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Date: Thu, 12 Jun 2003 14:12:44 +0300 Message-ID: Thread-Topic: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Thread-Index: AcMwzSeFuXK//wydR2W7QRkPoBKXswAA2mLQ To: , X-OriginalArrivalTime: 12 Jun 2003 11:12:45.0590 (UTC) FILETIME=[8CDAFB60:01C330D3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CBDYm10168 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Magnus, > The session level value is bit redundant. It is simply the sum of all > media streams and reflect the total amount of bandwidth needed to > accommodate this session. This can of course be calculated by > a receiver. > Also, in the , in section 6.2.3, Usage rules section, it is stated that: "...The session level value, if present, MUST be the sum of all media level values.". I believe this is a true statement for constant bitrate streams. But what about VBR cases? At least for RTP usage, the definition of bandwidth is for max bandwidth consumption over a 1 second sliding window, right? Hence, max bandwidth consumption at session level may be smaller or equal to the sum of these max bandwidths at media levels. And if the client is making resource reservation for QoS purposes, then there may possibly be a redundant amount of bandwidth allocation if the session level bandwidth is simply the absolute sum. Therefore, I believe that the session level TIAS bandwidth value MAY be smaller than the sum of the media level TIAS values. I guess for unicast case, a possible way to see the session level bandwidth consumption is during the hinting process of the data at the server side. Regards, Emre Emre Baris Aksu Nokia Mobile Phones > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 12 June, 2003 13:22 > To: Geetha Srikantan > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Questions/Comments on > draft-ietf-mmusic-sdp-bwparam-03.txt > > > Hi, > > Thanks for the comments. > > Geetha Srikantan wrote: > > I have a few questions and comments on > draft-ietf-mmusic-sdp-bwparam-03.txt: > > > > 1. Page 9, the last few lines - What is the difference > between 'RTP-based media > > stream' and 'RTP transport' here? It's not very clear > when the session level > > TIAS value can be used. > > There is no difference, I can change the RTP-based media > stream to "RTP > transported media stream". > > The session level value is bit redundant. It is simply the sum of all > media streams and reflect the total amount of bandwidth needed to > accommodate this session. This can of course be calculated by > a receiver. > > > > > 2. Section 6.2.3, 2nd paragraph - it would be good to > clarify that this entire > > paragraph refers to the media level values. > > This paragraph is a little confusing to read..it might > help to mention > > explicitly that it is RECOMMENDED to use both the AS and > TIAS fields; > > AS for backwards compatibility, older implementations > would ignore the TIAS > > field; TIAS would be recognized by newer and compliant > implementations, > > which must ignore the AS value. > > No, It does not only apply for the media level, but both > levels. AS can > be present at both levels, if one includes it at either level one is > recommended to include TIAS also. > > I don't quite understand what you mean with confusing to read. The > information you ask for is there: "..., it is RECOMMENDED to also > include the "AS" modifier when using "TIAS"". Do you have a more > concrete proposal on how reformulate the paragraph? > > > > > 3. 6.3, 2nd paragraph - here too it might help clarity to > assert the 'MUST NOT' > > case , before the 'MAY' case. > > So you would like to be reformulated into something like this: > > "At the SDP session level, the maxprate value MUST be the sum of all > media-level packet rates. The "maxprate" attribute MUST NOT > be present > at session level if the media streams use different transport. The > attribute MAY be present if the media streams use the same > transport. If > the attribute is present at the session level it SHOULD also be > present at the media level for all media streams." > > Is that better? If not please provide concrete proposals of > the paragraph. > > > > > > 4. 6.3, is there any ambiguity in the last paragraph? For > instance, is it ok to > > *not* have maxprate if one or the other of TIAS or the > max packet rate > > for the transport is not available? > > Yes, if one can't derive a packet rate due to for example non packet > based transport then its ok. However if you use TIAS and have a > transport like IP/UDP/RTP you shall have it. Perhaps I should > reformulate the sentence to be more strict and explanatory. > > > > > 5. It would be great to have a complete example of SDP > using TIAS and maxprate > > attributes. > > > > Yes, you are correct. I will look into it. > > > 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@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Jun 12 08:50:19 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 IAA08564 for ; Thu, 12 Jun 2003 08:50:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CCnoW17606 for mmusic-archive@odin.ietf.org; Thu, 12 Jun 2003 08:49:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCnom17603 for ; Thu, 12 Jun 2003 08:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08548 for ; Thu, 12 Jun 2003 08:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QRUU-00024x-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 08:47:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QRUT-00024u-00 for mmusic-web-archive@ietf.org; Thu, 12 Jun 2003 08:47:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCnYm17589; Thu, 12 Jun 2003 08:49:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CChnm17212 for ; Thu, 12 Jun 2003 08:43:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07850 for ; Thu, 12 Jun 2003 08:43:47 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QROf-0001rQ-00 for mmusic@ietf.org; Thu, 12 Jun 2003 08:41:41 -0400 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 19QROd-0001qf-00 for mmusic@ietf.org; Thu, 12 Jun 2003 08:41:40 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id EE2BA5D16E; Thu, 12 Jun 2003 14:43:33 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA14979; Thu, 12 Jun 2003 14:43:33 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p2/8.8.5-1.2.2m-19990317) with ESMTP id OAA00759; Thu, 12 Jun 2003 14:43:32 +0200 (MEST) Subject: Re: [MMUSIC] stream switching To: "Andreas Kassler" Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 12 Jun 2003 14:35:10 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 12/06/2003 14:44:36 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: , Andreas Kassler wrote: > [erased lines] >I think there are three main issues: >- stream switching is end-to-end and can be seen as a reaction to congestion > --> congestion control Good ! > [erased lines] >- frame skipping at the sender does only lead to >temporal scalability and limits the choices of user QoS >scalability to the temporal domain. In contrast, when using >stream switching, quality scalability or even spatial scalbility >may be achieved. Yes! I think this is a key issue that I should have stressed more to attrack attention, for example what is being done in 3GPP right now concerns MPEG-4 video SP@L0 for which these issues are simply out of scope (you keep the same codec, same image size etc) I would like to have a much more powerful tool in terms of bit rate range and codec choice etc. >But this is up to the video provider, who has to >encode the alternative streams in a proper way. However, the >disadvantage of stream switching is the need for more resources >at the server, as each video alternative consumes disc space. This is a well understood disavantage, the feedback we have from customers today is (in short) that it is "worth it". It is also only a "compromise" issue: if you have more disk you do (a little) better, the *principle* remains. Also we are talking about audio AND video usually and by playing around with the sum (audio+video) you can create up to #audio*#video different rates, which is a rapidly growing number! => disk size = proprotional to #Audio+#Video => number of different rates = #Audio*#Video > [erased lines] >> * Can we say that there is a concensus that Stream Switching is a good >> candidate for rate and congestion control in streaming (i.e. in the >context of RFC3448) ? > >I would say it is a candidate, but I doubt you can do it in a TCP friendly >way, unless you >have very fine granular bandwidth steps between the alternative streams. We had some rather good surprises here when going from theory to practice !-) Actually the way TCP behave is, when going down, to divide the rate by 2: you dont need *that* many alternate streams to do that ! Example (in kb/s): 50,25,12,6 Now if the question is "is this TCP friendly ?" then I would say that the issue is NOT the number of different rates you use but rather the issue is that your rate at a given moment should be SMALLER than the rate computed using TFRC! i.e. if RFRC3438 says "use 37.8 kb/s" then I would use 25 kb/s and this is "better" than TCP friendly right? regards, Philippe Gentric http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 02:05: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 CAA16029 for ; Fri, 13 Jun 2003 02:05:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D65G929051 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 02:05:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D65Gm29048 for ; Fri, 13 Jun 2003 02:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15608 for ; Fri, 13 Jun 2003 02:05:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QheT-0001Vm-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 02:03:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QheT-0001Vi-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 02:03:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CIZ0a14844; Thu, 12 Jun 2003 14:35:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CIYQm14816 for ; Thu, 12 Jun 2003 14:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22202 for ; Thu, 12 Jun 2003 14:34:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QWrw-000594-00 for mmusic@ietf.org; Thu, 12 Jun 2003 14:32:16 -0400 Received: from host217-45-197-114.in-addr.btopenworld.com ([217.45.197.114] helo=aegir.engineering.newport-networks.com) by ietf-mx with esmtp (Exim 4.12) id 19QWrw-00057o-00 for mmusic@ietf.org; Thu, 12 Jun 2003 14:32:16 -0400 Received: from EDLUFF ([134.22.36.66]) (authenticated user edluff@newport-networks.com) by aegir.engineering.newport-networks.com for mmusic@ietf.org; Thu, 12 Jun 2003 19:33:42 +0100 Reply-To: From: "Ed Luff" To: Date: Thu, 12 Jun 2003 14:33:49 -0400 Organization: Newport Networks Message-ID: <003c01c33111$2b78fbe0$1703a8c0@EDLUFF> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SSRC in SDP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The Synchronization Source (SSRC) is passed in the RTP and RTCP headers, which uniquely identifies a particular media stream. There are some good benefits to including the Synchronization Source (SSRC) within the SDP, including the prevention of uncontrolled barge-in or eavesdropping (within the network) and multiplexing media streams over the same receiving port. The only downside that I have come across is the need for the application to appropriately handle the possibility of two clients generating the same random SSRC, which seems minor in nature. Instead of having each session oriented protocol (SIP, RTSP, MGCP and H.323) include support through an extension, would it not be a good idea simply to have the SSRC included within the SDP? I have seen proposals in H.323 and RTSP, where the extension is a bit messy, as the clients must signal their support of the extension in the call setup... I have included some references and information below, which support the need for SSRC signaling. Thoughts? Ed - "SDP Security Descriptions for Media Streams", , February 2003. - "How to make Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls", , February 2003. - H.323 has proposed the use of signaling the SSRC in the H.245 signaling channel. The primary purpose is for multiplexing media streams over the same receiving port. The proposal is shown below. H2250LogicalChannelParameters ::=SEQUENCE {. willUseSSRC NULL OPTIONAL, ssrc INTEGER(0..4294967295) OPTIONAL } H2250LogicalChannelAckParameters ::=SEQUENCE { . ssrc INTEGER(0..4294967295) OPTIONAL } _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 05:47: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 FAA26754 for ; Fri, 13 Jun 2003 05:47:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D9lM225369 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 05:47:22 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9lMm25366 for ; Fri, 13 Jun 2003 05:47:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26739 for ; Fri, 13 Jun 2003 05:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ql7P-0003Dt-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 05:45:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ql7P-0003Dq-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 05:45:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHm5a11516; Thu, 12 Jun 2003 13:48:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHeEm11029 for ; Thu, 12 Jun 2003 13:40:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20412 for ; Thu, 12 Jun 2003 13:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QW1V-0004e1-00 for mmusic@ietf.org; Thu, 12 Jun 2003 13:38:05 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19QW1U-0004dY-00 for mmusic@ietf.org; Thu, 12 Jun 2003 13:38:04 -0400 Received: from phys-ha1mpkb.eng.sun.com ([129.146.14.51]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5CHdeLv016201; Thu, 12 Jun 2003 10:39:40 -0700 (PDT) Received: from jamba (jamba [129.146.125.67]) by phys-ha1mpkb.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id KAA05774; Thu, 12 Jun 2003 10:39:39 -0700 (PDT) Message-Id: <200306121739.KAA05774@phys-ha1mpkb.eng.sun.com> Date: Thu, 12 Jun 2003 10:39:39 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt To: magnus.westerlund@ericsson.com Cc: mmusic@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KjaGTCpnZ+w251KfeRErvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Magnus, Thanks for the response and clarifications. My response is inline. > > > > 2. Section 6.2.3, 2nd paragraph - it would be good to clarify that this entire > > paragraph refers to the media level values. > > This paragraph is a little confusing to read..it might help to mention > > explicitly that it is RECOMMENDED to use both the AS and TIAS fields; > > AS for backwards compatibility, older implementations would ignore the TIAS > > field; TIAS would be recognized by newer and compliant implementations, > > which must ignore the AS value. > > No, It does not only apply for the media level, but both levels. AS can > be present at both levels, if one includes it at either level one is > recommended to include TIAS also. I see..I didn't realize that AS can be present at the session level, too. > I don't quite understand what you mean with confusing to read. The > information you ask for is there: "..., it is RECOMMENDED to also > include the "AS" modifier when using "TIAS"". Do you have a more > concrete proposal on how reformulate the paragraph? I meant 'confusing' in the sense that the motivation for this is not completely clear to me. I interpreted this part of the text to mean that - if both AS and TIAS values are present in the SDP, then a newer (i.e. bwparam-compliant) implementation should ignore the AS values. An older (i.e. bwparam-non-compliant) implementation would try to use the AS values and ignore the TIAS values. Is that right? By providing both AS and TIAS values, it would permit interoperability with older and newer implementations - if that is the only reason, we might want to say so explicitly in the text. If there are other reasons to provide both values, would you please explain? > > > > 3. 6.3, 2nd paragraph - here too it might help clarity to assert the 'MUST NOT' > > case , before the 'MAY' case. > > So you would like to be reformulated into something like this: > > "At the SDP session level, the maxprate value MUST be the sum of all > media-level packet rates. The "maxprate" attribute MUST NOT be present > at session level if the media streams use different transport. The > attribute MAY be present if the media streams use the same transport. If > the attribute is present at the session level it SHOULD also be > present at the media level for all media streams." > > Is that better? If not please provide concrete proposals of the paragraph. Yes, this is much better...thanks! > > 4. 6.3, is there any ambiguity in the last paragraph? For instance, is it ok to > > *not* have maxprate if one or the other of TIAS or the max packet rate > > for the transport is not available? > > Yes, if one can't derive a packet rate due to for example non packet > based transport then its ok. However if you use TIAS and have a > transport like IP/UDP/RTP you shall have it. Perhaps I should > reformulate the sentence to be more strict and explanatory. Thanks..that clarifies it. Perhaps something like this: "maxprate" SHALL be included for all transports where a packet rate can be derived and TIAS is included. For example, if you use TIAS and a transport like IP/UDP/RTP, for which the max packet rate can be derived, then "maxprate" shall be included. If either (a) the packet rate for the transport cannot be derived, or (b) TIAS is not included, then, "maxprate" is not required to be included. > > > > 5. It would be great to have a complete example of SDP using TIAS and maxprate > > attributes. > > > > Yes, you are correct. I will look into it. Thanks, this wil be helpful. geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 11:41:39 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 LAA10113 for ; Fri, 13 Jun 2003 11:41:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFfBW22266 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 11:41:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFfBm22263 for ; Fri, 13 Jun 2003 11:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10088 for ; Fri, 13 Jun 2003 11:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qqdp-0006GI-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 11:39:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qqdo-0006GF-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 11:39:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8Z1a19030; Fri, 13 Jun 2003 04:35:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8Yvm19010 for ; Fri, 13 Jun 2003 04:34:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25142 for ; Fri, 13 Jun 2003 04:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QjzL-0002le-00 for mmusic@ietf.org; Fri, 13 Jun 2003 04:32:47 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19QjzK-0002lZ-00 for mmusic@ietf.org; Fri, 13 Jun 2003 04:32:46 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5D8Zecv025902; Fri, 13 Jun 2003 10:35:40 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGHSQLA; Fri, 13 Jun 2003 10:36:26 +0200 Message-ID: <3EE98BFE.1050307@ericsson.com> Date: Fri, 13 Jun 2003 10:31:58 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: emre.aksu@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Emre, Comments below. emre.aksu@nokia.com wrote: > Hi Magnus, > > >>The session level value is bit redundant. It is simply the sum of all >>media streams and reflect the total amount of bandwidth needed to >>accommodate this session. This can of course be calculated by >>a receiver. >> > > > Also, in the , in section 6.2.3, Usage rules section, it is stated that: > "...The session level value, if present, MUST be the sum of all media level values.". > > I believe this is a true statement for constant bitrate streams. But what about VBR cases? At least for RTP usage, the definition of bandwidth is for max bandwidth consumption over a 1 second sliding window, right? Hence, max bandwidth consumption at session level may be smaller or equal to the sum of these max bandwidths at media levels. And if the client is making resource reservation for QoS purposes, then there may possibly be a redundant amount of bandwidth allocation if the session level bandwidth is simply the absolute sum. Therefore, I believe that the session level TIAS bandwidth value MAY be smaller than the sum of the media level TIAS values. Yes, you are correct that if one has several VBR streams they can be scheduled so that the sum of all the streams has a lower maximum. The session level application of the TIAS value has been something I have been had different views on, during the development of the this draft. For a while I had TIAS only as media level attribute. As I see it there are three possible ways to go with this issue. 1. Remove TIAS and maxprate at session level. This will remove the redundancy compared to ver 03 definition. It will simplify and prevent any possibilities for contradictions between the values. 2. Keep it as defined today as the sum of all media streams values. Is redundant, has the possibility to be contradicting between session level and media level. 3. Define is at being the actual value when all media streams are sent. Will allow for getting a whole session value that are less then the sum of media level values. Will be more complex and will require more implementation to consider if both values are present. A given value on session level will only be true if all media streams are actually used. Not known how often you can actually use this. Looking at this list I now see that using 2 as current proposed may be the least good solution. I would like to get more input if they believe in 3. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 12:58:22 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 MAA12365 for ; Fri, 13 Jun 2003 12:58:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGvt101720 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 12:57:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGvsm01715 for ; Fri, 13 Jun 2003 12:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12208 for ; Fri, 13 Jun 2003 12:57:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrq4-0006kP-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrq3-0006kL-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEI1a14775; Fri, 13 Jun 2003 10:18:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEHRm14756 for ; Fri, 13 Jun 2003 10:17:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07374 for ; Fri, 13 Jun 2003 10:17:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpKl-0005ga-00 for mmusic@ietf.org; Fri, 13 Jun 2003 10:15:15 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19QpKl-0005gX-00 for mmusic@ietf.org; Fri, 13 Jun 2003 10:15:15 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5DEIAcv016743 for ; Fri, 13 Jun 2003 16:18:10 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGKZNXX; Fri, 13 Jun 2003 16:17:13 +0200 Message-ID: <3EE9DCF2.8050807@ericsson.com> Date: Fri, 13 Jun 2003 16:17:22 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP telecon Monday 16th of June 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, Sorry that I am late. There is a teleconference scheduled for monday (16th of June) at 18.00 CET. Included is the contact information and agenda. Cheers Magnus Conference Details: Telephone nr: +46 8 71 99500 Participant PIN: 21158 Date 06/16/2003 (MM/DD/YYYY) Start Time 18:00 (HH:MM) CET Agenda: ------- 1. Opening of meeting. 2. Administrative a. IETF Vienna b. Authoring and Specification - Aravind co-author - Working on the specification. 3. Since last meeting (28th of May). a. Bug 533691 & 513880 - Updated text received, include in specification? b. http://rtsp.org/bug556295 - Text received, include in specification? c. Multiple SSRC in RTSP. - Text received, include in specification? d. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration and clear rules - Magnus to write text and question to list. f. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Magnus to write text. g. http://rtsp.org/742348 - Usage of implicit REDIRECT. - Philippe and Yves has written to the list. Resolve discussion. 3. New Things a. REDIRECT to automatically close session. Problem description: With the clarification the result of the REDIRECT request without session header closes the RTSP message connection, does this mean that the session has automatically been closed? If Yes, should the same behaviour be used also when session header is present? 5. Any other Issues 6. Next meeting - Proposal: IETF meeting? 7. End meeting -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 13:15:26 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 NAA13520 for ; Fri, 13 Jun 2003 13:15:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHExX14312 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 13:14:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHExm14309 for ; Fri, 13 Jun 2003 13:14:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13505 for ; Fri, 13 Jun 2003 13:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qs6a-00074X-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 13:12:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qs6Z-00074U-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 13:12:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8J2a18226; Fri, 13 Jun 2003 04:19:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8IFm18189 for ; Fri, 13 Jun 2003 04:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24870 for ; Fri, 13 Jun 2003 04:18:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QjjC-0002gB-00 for mmusic@ietf.org; Fri, 13 Jun 2003 04:16:06 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19QjjB-0002g6-00 for mmusic@ietf.org; Fri, 13 Jun 2003 04:16:05 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5D8ICw2003996; Fri, 13 Jun 2003 10:18:12 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP3KY8; Fri, 13 Jun 2003 10:19:27 +0200 Message-ID: <3EE98815.1090805@ericsson.com> Date: Fri, 13 Jun 2003 10:15:17 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: mmusic@ietf.org Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt References: <200306121739.KAA05774@phys-ha1mpkb.eng.sun.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 Geetha, See comments below. Geetha Srikantan wrote: > hi Magnus, > > Thanks for the response and clarifications. > My response is inline. > > > >>>2. Section 6.2.3, 2nd paragraph - it would be good to clarify that this >> > entire > >>> paragraph refers to the media level values. >>> This paragraph is a little confusing to read..it might help to mention >>> explicitly that it is RECOMMENDED to use both the AS and TIAS fields; >>> AS for backwards compatibility, older implementations would ignore the >> > TIAS > >>> field; TIAS would be recognized by newer and compliant implementations, >>> which must ignore the AS value. >> >>No, It does not only apply for the media level, but both levels. AS can >>be present at both levels, if one includes it at either level one is >>recommended to include TIAS also. > > > I see..I didn't realize that AS can be present at the session level, too. > > >>I don't quite understand what you mean with confusing to read. The >>information you ask for is there: "..., it is RECOMMENDED to also >>include the "AS" modifier when using "TIAS"". Do you have a more >>concrete proposal on how reformulate the paragraph? > > > I meant 'confusing' in the sense that the motivation for this is > not completely clear to me. > I interpreted this part of the text to mean that - if both AS and TIAS values > are present in the SDP, then a newer (i.e. bwparam-compliant) implementation > should ignore the AS values. An older (i.e. bwparam-non-compliant) > implementation would try to use the AS values and ignore the TIAS values. Is > that right? By providing both AS and TIAS values, it would permit > interoperability with older and newer implementations - if that is the only > reason, we might want to say so explicitly in the text. If there are other > reasons to provide both values, would you please > explain? > No, there exist no further reasons than backwards compatibility to include both values. Your correct in your deduction that a new implementation SHOULD only use the TIAS value, while an old not understanding TIAS will use AS. I think I provide enough explanation for these rule in the first part of the first sentence of paragraph 2 in 6.2.3. Is the current text difficult to understand? > >>>4. 6.3, is there any ambiguity in the last paragraph? For instance, is it ok >> > to > >>> *not* have maxprate if one or the other of TIAS or the max packet rate >>> for the transport is not available? >> >>Yes, if one can't derive a packet rate due to for example non packet >>based transport then its ok. However if you use TIAS and have a >>transport like IP/UDP/RTP you shall have it. Perhaps I should >>reformulate the sentence to be more strict and explanatory. > > > > Thanks..that clarifies it. Perhaps something like this: > > "maxprate" SHALL be included for all transports where a packet rate can be > derived and TIAS is included. For example, if you use TIAS and a transport like > IP/UDP/RTP, for which the max packet rate can be derived, then "maxprate" shall > be included. If either (a) the packet rate for the transport cannot be derived, > or (b) TIAS is not included, then, "maxprate" is not required to be included. > > Thanks, I will use this with some modifications. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 13:20: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 NAA13993 for ; Fri, 13 Jun 2003 13:20:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHJrR17097 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 13:19:53 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHJrm17094 for ; Fri, 13 Jun 2003 13:19:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13927 for ; Fri, 13 Jun 2003 13:19:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsBK-00079y-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsBJ-00079v-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEn1a17258; Fri, 13 Jun 2003 10:49:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEmlm17240 for ; Fri, 13 Jun 2003 10:48:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08577 for ; Fri, 13 Jun 2003 10:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qpp6-0005vw-00 for mmusic@ietf.org; Fri, 13 Jun 2003 10:46:36 -0400 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 19Qpp5-0005vi-00 for mmusic@ietf.org; Fri, 13 Jun 2003 10:46:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C331BB.1B453048" Date: Fri, 13 Jun 2003 16:50:18 +0200 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B909499FFECE@swing.cefriel.it> Thread-Topic: RTSP and NAT Thread-Index: AcMxuxoCDGmpzX9xTwyiRXhN7ZKHWg== From: "Enrico Balatti" To: Subject: [MMUSIC] RTSP and NAT Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C331BB.1B453048 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List Members, =20 my question is about RTSP and STUN integration to make RTSP traffic traverse a NAT. =20 The IETF-draft in the section=20 3.1.2 describes how a RTSP client using RTP transport over UDP can use = STUN to traverse a full cone NAT. =20 I've setup a little demo with a Full Cone NAT between a client (RTSP and = STUN) and a server (RTSP and STUN). In this situation, I've noticed that the RTP flow from the server to the = client is not blocked by the NAT therefore it seems that the steps indicated in section 3.1.2 are not = necessary in this case. I think, but I am not sure, that this is due to the fact that the RTSP client I'm = using (MPEG4IP) include (according to RTSP specification) in the transport header only the "client_port" = information and not the "destination" parameter (that includes the IP address of the client and the ports number).=20 =20 If the RTSP server doesn't receive the "destination" parameter in the = transport header what IP address does it uses how IP destination of the RTP flow? If it = uses the IP address from wich it receives the RTSP methods (that is the mapped IP), then = this explains why the RTSP client behind a full cone NAT receives the Video Stream (according to definition of a Full = Cone NAT: any external host can send a packet to the internal host, by sending a packet to the mapped external address.) If my consideration are right the following statement (to add to section = 3.1.2) is true: =20 >If the user is behind a full cone NAT, STUN allows the >RTSP client to traverse the NAT with some simple client side >adaptations.=20 If the client doesn't include in the RTSP "transport header" the = "destination" parameter then the client doesn't need any adaptation. =20 Best Regards, =20 Ing. Enrico M. Balatti =20 Tel. 02-23954327 Fax. +39 02 23954527 < mailto:balatti@cefriel.it>=20 CEFRIEL -Network Systems Area=20 Via Fucini, 2=20 20133 Milano - Italy=20 < http://www.cefriel.it/>=20 =20 =20 ------_=_NextPart_001_01C331BB.1B453048 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear = List=20 Members,
 
my = question is about=20 RTSP and STUN integration to make
RTSP = traffic=20 traverse a NAT.
 
The = IETF-draft=20 <draft-ietf-mmusic-rtsp-nat-00.txt> in the=20 section 
3.1.2=20 describes how a RTSP client using RTP transport over UDP can = use STUN=20 to traverse a
full cone NAT.
 
I've setup a little demo with a Full Cone = NAT between a=20 client (RTSP and STUN) and a server (RTSP and = STUN).
In = this situation,=20 I've noticed that the RTP flow from the server to the client is not = blocked by=20 the NAT
therefore it seems=20 that the steps indicated in section 3.1.2 are not necessary in this = case. I=20 think,
but I am not = sure, that this is=20 due to the fact that the RTSP client I'm using (MPEG4IP) include=20 (according
to = RTSP=20 specification) in the transport header only the = "client_port" information=20 and not the "destination" parameter (that
includes the IP=20 address of the client and the ports number).
 
If = the RTSP=20 server doesn't receive the "destination" parameter in the = transport header
what = IP address does=20 it uses how IP destination of the RTP flow? If it uses the IP=20 address
from = wich it=20 receives the RTSP methods (that is the mapped IP), then this explains = why the=20 RTSP client behind a full
cone = NAT receives=20 the Video Stream (according to definition of a Full Cone NAT: any external host can send a packet to
the = internal host,=20 by sending a packet to the mapped=20 external address.)
If my = consideration=20 are right the following statement (to add to section 3.1.2) is=20 true:
 
>If the=20 user is behind a full cone NAT, STUN allows the
>RTSP client to = traverse=20 the NAT with some simple client side
>adaptations.=20
If the = client=20 doesn't include in the RTSP "transport header"  the=20 "destination"
parameter then=20 the client doesn't need any adaptation.
 
Best=20 Regards,
 

Ing. Enrico M. = Balatti           =
Tel.=20 02-23954327

Fax. +39 02 23954527

 <mailto:balatti@cefriel.it>=20

CEFRIEL -Network = Systems Area=20
Via Fucini, 2
20133 Milano - Italy

<http://www.cefriel.it/>

 

 
------_=_NextPart_001_01C331BB.1B453048-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 21:43: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 VAA01547 for ; Fri, 13 Jun 2003 21:43:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E1h6010469 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 21:43:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E1h5m10466 for ; Fri, 13 Jun 2003 21:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01465 for ; Fri, 13 Jun 2003 21:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R02I-00037w-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 21:40:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R02H-00037t-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 21:40:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNx2a02978; Fri, 13 Jun 2003 19:59:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNwxm02960 for ; Fri, 13 Jun 2003 19:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29074 for ; Fri, 13 Jun 2003 19:58:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QyPY-0002UC-00 for mmusic@ietf.org; Fri, 13 Jun 2003 19:56:48 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19QyPX-0002U4-00 for mmusic@ietf.org; Fri, 13 Jun 2003 19:56:47 -0400 Received: from phys-ha1mpkb.eng.sun.com ([129.146.14.51]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5DNwN4Z012209; Fri, 13 Jun 2003 16:58:23 -0700 (PDT) Received: from jamba (jamba [129.146.125.67]) by phys-ha1mpkb.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id QAA14535; Fri, 13 Jun 2003 16:58:23 -0700 (PDT) Message-Id: <200306132358.QAA14535@phys-ha1mpkb.eng.sun.com> Date: Fri, 13 Jun 2003 16:58:23 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt To: magnus.westerlund@ericsson.com Cc: mmusic@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hu4fptwLvmAQEVwMwt4jUg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > No, there exist no further reasons than backwards compatibility to > include both values. Your correct in your deduction that a new > implementation SHOULD only use the TIAS value, while an old not > understanding TIAS will use AS. I think I provide enough explanation for > these rule in the first part of the first sentence of paragraph 2 in 6.2.3. > > Is the current text difficult to understand? The text is fine..an additional sentence at the beginning of paragraph 2 in 6.2.3 explaining the rule (as you mentioned above), would be good. thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Jun 13 22:18:51 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 WAA02373 for ; Fri, 13 Jun 2003 22:18:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E2IO112519 for mmusic-archive@odin.ietf.org; Fri, 13 Jun 2003 22:18:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2IOm12516 for ; Fri, 13 Jun 2003 22:18:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02359 for ; Fri, 13 Jun 2003 22:18:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R0aR-0003JR-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 22:16:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R0aQ-0003JO-00 for mmusic-web-archive@ietf.org; Fri, 13 Jun 2003 22:16:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DL82a19952; Fri, 13 Jun 2003 17:08:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DL73m19074 for ; Fri, 13 Jun 2003 17:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22922 for ; Fri, 13 Jun 2003 17:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QvjA-0001Cl-00 for mmusic@ietf.org; Fri, 13 Jun 2003 17:04:52 -0400 Received: from wireless217.east.isi.edu ([65.123.202.217] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19Qvj9-0001Ci-00 for mmusic@ietf.org; Fri, 13 Jun 2003 17:04:51 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h5DL6npv008475; Fri, 13 Jun 2003 17:06:58 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Fri, 13 Jun 2003 17:06:49 -0400 From: Colin Perkins To: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SSRC in SDP Message-Id: <20030613170649.046e4c0f.csp@csperkins.org> In-Reply-To: <003c01c33111$2b78fbe0$1703a8c0@EDLUFF> References: <003c01c33111$2b78fbe0$1703a8c0@EDLUFF> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> "Ed Luff" writes: > The Synchronization Source (SSRC) is passed in the RTP and RTCP headers, > which uniquely identifies a particular media stream. > > There are some good benefits to including the Synchronization Source > (SSRC) within the SDP, including the prevention of uncontrolled barge-in > or eavesdropping (within the network) and multiplexing media streams > over the same receiving port. The only downside that I have come across > is the need for the application to appropriately handle the possibility > of two clients generating the same random SSRC, which seems minor in > nature. Using the SSRC to prevent barge-in and eavesdropping seems weak. There are also good reasons why multiplexing media streams of often not a good idea: the RTP specification goes into details. > Instead of having each session oriented protocol (SIP, RTSP, MGCP and > H.323) include support through an extension, would it not be a good idea > simply to have the SSRC included within the SDP? I have seen proposals > in H.323 and RTSP, where the extension is a bit messy, as the clients > must signal their support of the extension in the call setup... How do you handle collisions if the SSRC is included in the SDP? I would expect there to be the need for some interaction with the signalling protocol. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Jun 15 17:27:32 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 RAA11302 for ; Sun, 15 Jun 2003 17:27:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FLR5o26888 for mmusic-archive@odin.ietf.org; Sun, 15 Jun 2003 17:27:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLR5m26885 for ; Sun, 15 Jun 2003 17:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11288 for ; Sun, 15 Jun 2003 17:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RezZ-0005RA-00 for mmusic-web-archive@ietf.org; Sun, 15 Jun 2003 17:24:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RezZ-0005R6-00 for mmusic-web-archive@ietf.org; Sun, 15 Jun 2003 17:24:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FGY1a09623; Sun, 15 Jun 2003 12:34:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FGXLm09606 for ; Sun, 15 Jun 2003 12:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05443 for ; Sun, 15 Jun 2003 12:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RaPK-0004Gj-00 for mmusic@ietf.org; Sun, 15 Jun 2003 12:31:06 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RaPK-0004Gf-00 for mmusic@ietf.org; Sun, 15 Jun 2003 12:31:06 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5FGXEG5024302; Sun, 15 Jun 2003 18:33:17 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYPXHN3; Sun, 15 Jun 2003 18:34:35 +0200 Message-ID: <3EEC9F15.5060608@ericsson.com> Date: Sun, 15 Jun 2003 18:30:13 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enrico Balatti CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and NAT References: <6F5FB8313FE82C4EA10DA4DA40B909499FFECE@swing.cefriel.it> 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 Enrico, Yes, I believe you are mostly correct. But I would like to clarify a few things why I think there at least some client modifications. The scenario you have when you have a client (A) behind full cone NAT to a RTSP server (C) and STUN server (D). A->D: The client makes a STUN request for each UDP port the session needs. A->C: The client makes a RTSP SETUP utilizing only client_port. A->C: The client sends a RTSP PLAY. C->A: RTP stream plays. This works under a few assumptions. 1. The RTSP TCP connection gets the same public IP address as the UDP mappings. 2. The STUN request results in that the correct port numbers are received, i.e. RTP gets a even port and RTCP gets the next odd. Of the above assumption I is commonly fulfilled. However the second, may not be fulfilled. Why this works does most likely depend on two things. 1. The server does not care if it delivers RTP to odd or even port (Which is a good implementation strategy). 2. The streaming works without RTCP getting through. The RTCP that is directed at the RTP port number + 1, and are lost there. The second point to make about the RTSP NAT draft is that it intended to be used with updated RTSP specification draft-ietf-mmusic-rfc2326bis-??.txt. In that draft we define new transport parameters for address and ports that are more flexible and allows to specify for each individual IP/UDP flow what address/port it should be sent to. This allows one to avoid making the above assumptions. The use of the tuple of address and port is a good thing, as it ensures that both parameters are explicitly given. This also makes the server possible to define certain strategies regarding forwarding media to certain addresses. The client needs adaptation to use the STUN method as it needs a STUN client. However no more changes are needed for this solution. I hope this clarifies a few things. Magnus Enrico Balatti wrote: > Dear List Members, > > my question is about RTSP and STUN integration to make > RTSP traffic traverse a NAT. > > The IETF-draft in the section > 3.1.2 describes how a RTSP client using RTP transport over UDP can use > STUN to traverse a > full cone NAT. > > I've setup a little demo with a Full Cone NAT between a client (RTSP and > STUN) and a server (RTSP and STUN). > In this situation, I've noticed that the RTP flow from the server to the > client is not blocked by the NAT > therefore it seems that the steps indicated in section 3.1.2 are not > necessary in this case. I think, > but I am not sure, that this is due to the fact that the RTSP client I'm > using (MPEG4IP) include (according > to RTSP specification) in the transport header only the > "client_port" information and not the "destination" parameter (that > includes the IP address of the client and the ports number). > > If the RTSP server doesn't receive the "destination" parameter in the > transport header > what IP address does it uses how IP destination of the RTP flow? If it > uses the IP address > from wich it receives the RTSP methods (that is the mapped IP), then > this explains why the RTSP client behind a full > cone NAT receives the Video Stream (according to definition of a Full > Cone NAT: any external host can send a packet to > the internal host, by sending a packet to the mapped external address.) > If my consideration are right the following statement (to add to section > 3.1.2) is true: > >>If the user is behind a full cone NAT, STUN allows the >>RTSP client to traverse the NAT with some simple client side >>adaptations. > If the client doesn't include in the RTSP "transport header" the > "destination" > parameter then the client doesn't need any adaptation. > > Best Regards, > > > Ing. Enrico M. Balatti > Tel. 02-23954327 > > Fax. +39 02 23954527 > > > > CEFRIEL -Network Systems Area > Via Fucini, 2 > 20133 Milano - Italy > > > > > > -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 12:44:32 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 MAA20346 for ; Mon, 16 Jun 2003 12:44:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GGi5o17642 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 12:44:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGi5m17639 for ; Mon, 16 Jun 2003 12:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20330 for ; Mon, 16 Jun 2003 12:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rx3F-0003vp-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 12:41:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rx3E-0003vm-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 12:41:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDE1a01908; Mon, 16 Jun 2003 09:14:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDD8m01883 for ; Mon, 16 Jun 2003 09:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12827 for ; Mon, 16 Jun 2003 09:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rtl5-0002XC-00 for mmusic@ietf.org; Mon, 16 Jun 2003 09:10:51 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Rtl4-0002X9-00 for mmusic@ietf.org; Mon, 16 Jun 2003 09:10:51 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GDDtcv023846; Mon, 16 Jun 2003 15:13:55 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8MSHD; Mon, 16 Jun 2003 15:13:21 +0200 Message-ID: <3EEDC1A9.3050504@ericsson.com> Date: Mon, 16 Jun 2003 15:10:01 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: emre.aksu@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Emre, emre.aksu@nokia.com wrote: > Simply, I propose to change the MUST statement in the session level TIAS value to a MAY statement and an explanation of the above case (sum of media level TIAS <= session level TIAS). An SDP generator can be clever enough to calculate the actual bandwidth needed by analysing the content, if available. Or it can just add up the media level TIAS values. The MUST statement omits the first possibility. > I hope that you mean: (sum of media level TIAS >= session level TIAS) Okay, I can agree to do that. There will be a paragraph or two to explain the implications of a session level TIAS smaller than the sum of them. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 16:34:38 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 QAA01115 for ; Mon, 16 Jun 2003 16:34:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GKYAV01241 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 16:34:10 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GKYAm01238 for ; Mon, 16 Jun 2003 16:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01081 for ; Mon, 16 Jun 2003 16:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S0dt-0006RQ-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 16:31:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S0ds-0006RN-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 16:31:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCu1a32661; Mon, 16 Jun 2003 08:56:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCtcm32645 for ; Mon, 16 Jun 2003 08:55:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12336 for ; Mon, 16 Jun 2003 08:55:36 -0400 (EDT) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RtUA-0002OO-00 for mmusic@ietf.org; Mon, 16 Jun 2003 08:53:22 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19RtU9-0002OL-00 for mmusic@ietf.org; Mon, 16 Jun 2003 08:53:21 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5GCtYa19325 for ; Mon, 16 Jun 2003 15:55:34 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 15:55:34 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 15:55:34 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 15:55:33 +0300 Received: from trebe006.NOE.Nokia.com ([172.22.232.181]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 15:55:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Date: Mon, 16 Jun 2003 15:55:31 +0300 Message-ID: Thread-Topic: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Thread-Index: AcMxwYXe2F9Uaa7MROu3BYqHx4LxmgCQ2ltQ To: Cc: X-OriginalArrivalTime: 16 Jun 2003 12:55:33.0070 (UTC) FILETIME=[929CBEE0:01C33406] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GCtcm32646 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Magnus, Comment below: > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 13 June, 2003 11:32 > To: Aksu Emre (NMP/Tampere) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Questions/Comments on > draft-ietf-mmusic-sdp-bwparam-03.txt > > > Hi Emre, > > Comments below. > > emre.aksu@nokia.com wrote: > > Hi Magnus, > > > > > >>The session level value is bit redundant. It is simply the > sum of all > >>media streams and reflect the total amount of bandwidth needed to > >>accommodate this session. This can of course be calculated by > >>a receiver. > >> > > > > > > Also, in the , in > section 6.2.3, Usage rules section, it is stated that: > > "...The session level value, if present, MUST be the sum of > all media level values.". > > > > I believe this is a true statement for constant bitrate > streams. But what about VBR cases? At least for RTP usage, > the definition of bandwidth is for max bandwidth consumption > over a 1 second sliding window, right? Hence, max bandwidth > consumption at session level may be smaller or equal to the > sum of these max bandwidths at media levels. And if the > client is making resource reservation for QoS purposes, then > there may possibly be a redundant amount of bandwidth > allocation if the session level bandwidth is simply the > absolute sum. Therefore, I believe that the session level > TIAS bandwidth value MAY be smaller than the sum of the media > level TIAS values. > > Yes, you are correct that if one has several VBR streams they can be > scheduled so that the sum of all the streams has a lower maximum. > > The session level application of the TIAS value has been something I > have been had different views on, during the development of the this > draft. For a while I had TIAS only as media level attribute. > As I see it > there are three possible ways to go with this issue. > > 1. Remove TIAS and maxprate at session level. This will remove the > redundancy compared to ver 03 definition. It will simplify > and prevent > any possibilities for contradictions between the values. > > 2. Keep it as defined today as the sum of all media streams > values. Is > redundant, has the possibility to be contradicting between > session level > and media level. > > 3. Define is at being the actual value when all media streams > are sent. > Will allow for getting a whole session value that are less then the > sum of media level values. Will be more complex and will require more > implementation to consider if both values are present. A > given value on > session level will only be true if all media streams are > actually used. > Not known how often you can actually use this. > > Looking at this list I now see that using 2 as current > proposed may be > the least good solution. I would like to get more input if > they believe > in 3. > Simply, I propose to change the MUST statement in the session level TIAS value to a MAY statement and an explanation of the above case (sum of media level TIAS <= session level TIAS). An SDP generator can be clever enough to calculate the actual bandwidth needed by analysing the content, if available. Or it can just add up the media level TIAS values. The MUST statement omits the first possibility. Best Regards, Emre Emre Baris Aksu Nokia Mobile Phones > > 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@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 17:43: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 RAA04008 for ; Mon, 16 Jun 2003 17:43:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GLhNx07565 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 17:43:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLhMm07562 for ; Mon, 16 Jun 2003 17:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03984 for ; Mon, 16 Jun 2003 17:43:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1ir-0007GD-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 17:41:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S1iq-0007G9-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 17:41:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJw1a30987; Mon, 16 Jun 2003 15:58:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJvUm30935 for ; Mon, 16 Jun 2003 15:57:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28770; Mon, 16 Jun 2003 15:57:26 -0400 (EDT) Message-Id: <200306161957.PAA28770@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , mmusic@ietf.org From: The IESG Date: Mon, 16 Jun 2003 15:57:26 -0400 Subject: [MMUSIC] Document Action: SDPng Transition to Informational Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'SDPng Transition' as an Informational RFC. This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. RFC Editor Note: OLD: 2 last paragraph and are now under discussion for TDM. Extensions to other transport NEW: and are now under discussion for time division multiplexing (TDM) networks. Extensions to other transport OLD: 4.1. (SAPv0) announcement. SDPng contents MAY be identified by a different NEW: announcement. SDPng contents may be identified by a different OLD: 4.3 3rd paragraph A SIP UAC MAY use an SDPng message body in a SIP INVITE (or other) NEW: A SIP UAC may use an SDPng message body in a SIP INVITE (or other) OLD: 4.3 4th paragraph of a peer to understand SDPng in addition (or instead) plain SDP. Methods such as OPTIONS MAY be used to determine a peer's support for NEW: of a peer to understand SDPng in addition (or instead) plain SDP. Methods such as OPTIONS may be used to determine a peer's support for _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 17:53:13 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 RAA04484 for ; Mon, 16 Jun 2003 17:53:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GLqkN07894 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 17:52:46 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLqkm07891 for ; Mon, 16 Jun 2003 17:52:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04473 for ; Mon, 16 Jun 2003 17:52:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1rw-0007MU-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 17:50:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S1rw-0007MQ-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 17:50:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGU1a16095; Mon, 16 Jun 2003 12:30:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGTEm16068 for ; Mon, 16 Jun 2003 12:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19895 for ; Mon, 16 Jun 2003 12:29:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rwor-0003oN-00 for mmusic@ietf.org; Mon, 16 Jun 2003 12:26:57 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19Rwoq-0003ma-00 for mmusic@ietf.org; Mon, 16 Jun 2003 12:26:56 -0400 Received: by fox.iptel.org (Postfix, from userid 534) id 306351C8; Mon, 16 Jun 2003 18:28:29 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-172-56.reverse.qdsl-home.de [212.202.172.56]) by fox.iptel.org (Postfix) with ESMTP id 4BBD3178; Mon, 16 Jun 2003 18:28:28 +0200 (CEST) Message-Id: <5.2.0.9.0.20030616182209.0293f920@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 18:25:58 +0200 To: mmusic@ietf.org From: Jiri Kuthan Cc: David Yon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-16.9 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) Subject: [MMUSIC] re: what happens if both SIP UAs want to be active Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , [sorry, misthreaded -- I copy'n'pasted from archive since I was stripped off the recepient list] What does it mean SIP-wise that negotiation fails? I mean it would be great to have a special code for this error which allows SIP entities to recognized these conditions and act approprietly. -Jiri on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: > If they both want to be active, the negotiation fails. >> At 12:47 PM 6/7/2003, Jiri Kuthan wrote: >> David, >> >> can you please explain me how SIP signaling proceeds if two UAs both >> with to have direction=active, since they are behind symmetric NATs? >> >> Thanks, >> >> -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 18:05: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 SAA05129 for ; Mon, 16 Jun 2003 18:05:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GM5TP08407 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 18:05:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GM5Sm08404 for ; Mon, 16 Jun 2003 18:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05079 for ; Mon, 16 Jun 2003 18:05:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S24F-0007S0-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 18:03:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S24E-0007Rx-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 18:03:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GH92a19526; Mon, 16 Jun 2003 13:09:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GH8Lm19508 for ; Mon, 16 Jun 2003 13:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21192 for ; Mon, 16 Jun 2003 13:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RxQW-00048I-00 for mmusic@ietf.org; Mon, 16 Jun 2003 13:05:52 -0400 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 19RxQV-00048F-00 for mmusic@ietf.org; Mon, 16 Jun 2003 13:05:51 -0400 Received: from yon-lattitude.rfdsoftware.com (host98.216.41.119.conversent.net [216.41.119.98]) (authenticated) by host110.216.41.119.conversent.net (8.10.2/8.10.2) with ESMTP id h5GH8Mr01998; Mon, 16 Jun 2003 13:08:22 -0400 Message-Id: <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 16 Jun 2003 13:07:56 -0400 To: Jiri Kuthan , mmusic@ietf.org From: David Yon In-Reply-To: <5.2.0.9.0.20030616182209.0293f920@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] re: what happens if both SIP UAs want to be active Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 SIP gurus can chime in, but seems to me it would be in the same category as not being able to come to an agreement vis-a-vis which codec to use. At 12:25 PM 6/16/2003, Jiri Kuthan wrote: >[sorry, misthreaded -- I copy'n'pasted from archive since I was stripped > off the recepient list] > >What does it mean SIP-wise that negotiation fails? > >I mean it would be great to have a special code for this error which >allows SIP entities to recognized these conditions and act approprietly. > >-Jiri > >on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: > > If they both want to be active, the negotiation fails. > > >> At 12:47 PM 6/7/2003, Jiri Kuthan wrote: > >> David, > >> > >> can you please explain me how SIP signaling proceeds if two UAs both > >> with to have direction=active, since they are behind symmetric NATs? > >> > >> Thanks, > >> > >> -jiri > >-- >Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 20:03:29 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 UAA09343 for ; Mon, 16 Jun 2003 20:03:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H031m16914 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 20:03:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H031m16909 for ; Mon, 16 Jun 2003 20:03:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09333 for ; Mon, 16 Jun 2003 20:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S3u0-0000X9-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 20:00:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S3tz-0000X6-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 20:00:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEQ0a06720; Mon, 16 Jun 2003 10:26:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEP2m06664 for ; Mon, 16 Jun 2003 10:25:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15777 for ; Mon, 16 Jun 2003 10:24:59 -0400 (EDT) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rusf-0002vH-00 for mmusic@ietf.org; Mon, 16 Jun 2003 10:22:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Ruse-0002vE-00 for mmusic@ietf.org; Mon, 16 Jun 2003 10:22:44 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5GEOv925798 for ; Mon, 16 Jun 2003 17:24:57 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 17:24:56 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 17:24:56 +0300 Received: from trebe006.NOE.Nokia.com ([172.22.232.181]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 17:24:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Date: Mon, 16 Jun 2003 17:24:55 +0300 Message-ID: Thread-Topic: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt Thread-Index: AcM0CT2bcburrUEoSm+bEZEXW9GFxgACXvSA To: Cc: X-OriginalArrivalTime: 16 Jun 2003 14:24:55.0937 (UTC) FILETIME=[0F214F10:01C33413] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GEP2m06665 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Magnus, > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 16 June, 2003 16:10 > To: Aksu Emre (NMP/Tampere) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Questions/Comments on > draft-ietf-mmusic-sdp-bwparam-03.txt > > > Hi Emre, > > emre.aksu@nokia.com wrote: > > Simply, I propose to change the MUST statement in the > session level TIAS value to a MAY statement and an > explanation of the above case (sum of media level TIAS <= > session level TIAS). An SDP generator can be clever enough to > calculate the actual bandwidth needed by analysing the > content, if available. Or it can just add up the media level > TIAS values. The MUST statement omits the first possibility. > > > > I hope that you mean: (sum of media level TIAS >= session level TIAS) > Yes definitely! That was a typo in my previous mail. > Okay, I can agree to do that. There will be a paragraph or two to > explain the implications of a session level TIAS smaller than > the sum of > them. > That sounds good enough to me. Best Regards, Emre Emre Baris Aksu Nokia Mobile Phones > 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@ericsson.com > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 21: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 VAA11980 for ; Mon, 16 Jun 2003 21:25:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H1OmB22908 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 21:24:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H1Omm22905 for ; Mon, 16 Jun 2003 21:24:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11974 for ; Mon, 16 Jun 2003 21:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S5B9-0001M2-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 21:22:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S5B8-0001Lz-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 21:22:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFL2a11028; Mon, 16 Jun 2003 11:21:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFKpm11007 for ; Mon, 16 Jun 2003 11:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17590 for ; Mon, 16 Jun 2003 11:20:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rvkh-0003JP-00 for mmusic@ietf.org; Mon, 16 Jun 2003 11:18:35 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19Rvkg-0003JM-00 for mmusic@ietf.org; Mon, 16 Jun 2003 11:18:34 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA09324 for ; Mon, 16 Jun 2003 17:20:46 +0200 (MET DST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id RAA00196 for ; Mon, 16 Jun 2003 17:19:47 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 17:20:17 +0200 Message-ID: From: Belling Thomas To: "'mmusic@ietf.org'" Date: Mon, 16 Jun 2003 17:20:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GFKpm11008 Subject: [MMUSIC] RTP bandwidth for multiple media streams Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5GFL2a11028 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H1Omm22905 Content-Transfer-Encoding: 8bit Hy Everybody, as suggested by Colin, I put my question on the mailing list. Comments are more then welcome. Is there an agreement to update the sdp-new draft according to Colin´s and my own interpretation? Cheers, Thomas ---------- From: Colin Perkins [mailto:csp@csperkins.org] Thomas, The spec is not clear, but I think I agree with your interpretation. I would suggest you also ask this question on the mmusic@ietf.org mailing list, so we can be sure there is consensus (and update the draft if necessary). cheers, Colin --> Belling Thomas writes: > Dear Mr. Handley, Mr. Jakobson, and Mr. Perkins, > > I wanted to ask you as the authors of the SDP new draft for your > interpretation of a problem we a currently discussing within 3GPP (The 3 > Generation Parnership Project standardizing mobile GSM and UMTS > networks). > > Consider the following SDP: > > c=IN IP4 224.2.1.1/127/2 > m=video 49170/2 RTP/AVP 31 > b=AS:64 > > My problem: How much bandwidth is associated with this "m=" line - > 64kbits or 128kbits? > > In the draft, you state that "b=AS" is similar to the RTP "session > bandwidth", as defined in RFC 1889. Consulting this RFC, I got stuck with > the definition of the "RTP Session". Consulting the definition in the RTP > new draft instead seems to suggest that the "m=" line describes two RTP > sessions. Therefore it seems that 128kbits may be the correct answer. Do > you agree with my interpretation? > > Clarity on this point is quite important for 3GPP, as the derived > bandwidth will be granted at the air interface, which is a scarce > resource where a factor of two makes a lot of difference. > > Best Regards and thank you very much for your help > > Th Belling > > > ---------------------------------- > Dr. Thomas Belling > Siemens AG > Sankt-Martinsstr. 76 > D-81542 München Germany > ICM N PG SP ST N1 > MCH M 34 307 > Tel +49 89 636 75207 > Fax +49 89 636 75577 > Mobile +49 172 2974678 > Email Thomas.Belling@siemens.com > > > > -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 22:41: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 WAA13569 for ; Mon, 16 Jun 2003 22:41:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H2evH28563 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 22:40:57 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H2evm28560 for ; Mon, 16 Jun 2003 22:40:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13562 for ; Mon, 16 Jun 2003 22:40:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S6Mp-0001kj-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 22:38:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S6Mo-0001kg-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 22:38:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGh2a17534; Mon, 16 Jun 2003 12:43:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGgwm17515 for ; Mon, 16 Jun 2003 12:42:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20226 for ; Mon, 16 Jun 2003 12:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rx2A-0003u1-00 for mmusic@ietf.org; Mon, 16 Jun 2003 12:40:42 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Rx29-0003ty-00 for mmusic@ietf.org; Mon, 16 Jun 2003 12:40:41 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GGgtG5017829 for ; Mon, 16 Jun 2003 18:42:55 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP83DG5; Mon, 16 Jun 2003 18:43:12 +0200 Message-ID: <3EEDF2D7.8000809@ericsson.com> Date: Mon, 16 Jun 2003 18:39:51 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET References: <3EE9DCF2.8050807@ericsson.com> Content-Type: text/plain; charset=UTF-8; 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 everyone, Today's telecon was short on people so we didn't discuss any technical issues. We did however discuss the next IETF meeting. The conclusion of the discussion was that Colin and Joerg will try to get an extra 2 hour WG session for only discussing RTSP. They will also try to get a smaller room that makes it easier to have the discussion in a circle or something. If you have items/issues that needs to be discussed please send them to me. Best Regards Magnus Magnus Westerlund wrote: > Hi, > > Sorry that I am late. There is a teleconference scheduled for monday > (16th of June) at 18.00 CET. Included is the contact information and > agenda. > > Cheers > > Magnus > > > Conference Details: > > Telephone nr: +46 8 71 99500 > Participant PIN: 21158 > Date 06/16/2003 (MM/DD/YYYY) > Start Time 18:00 (HH:MM) CET > > Agenda: > ------- > 1. Opening of meeting. > 2. Administrative > a. IETF Vienna > b. Authoring and Specification > - Aravind co-author > - Working on the specification. > 3. Since last meeting (28th of May). > a. Bug 533691 & 513880 > - Updated text received, include in specification? > b. http://rtsp.org/bug556295 - Text received, include in specification? > c. Multiple SSRC in RTSP. > - Text received, include in specification? > d. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration > and clear rules > - Magnus to write text and question to list. > f. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Magnus to write text. > g. http://rtsp.org/742348 - Usage of implicit REDIRECT. > - Philippe and Yves has written to the list. Resolve discussion. > > 3. New Things > > a. REDIRECT to automatically close session. > > Problem description: > With the clarification the result of the REDIRECT request without > session header closes the RTSP message connection, does this mean that > the session has automatically been closed? If Yes, should the same > behaviour be used also when session header is present? > > 5. Any other Issues > 6. Next meeting - Proposal: IETF meeting? > 7. End meeting > > -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Jun 16 23:23: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 XAA14686 for ; Mon, 16 Jun 2003 23:23:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H3MX131161 for mmusic-archive@odin.ietf.org; Mon, 16 Jun 2003 23:22:33 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H3MOm31157 for ; Mon, 16 Jun 2003 23:22:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14643 for ; Mon, 16 Jun 2003 23:22:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S70v-00023d-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 23:20:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S70n-00023X-00 for mmusic-web-archive@ietf.org; Mon, 16 Jun 2003 23:19:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GKe2a02354; Mon, 16 Jun 2003 16:40:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GKdUm02311 for ; Mon, 16 Jun 2003 16:39:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01297 for ; Mon, 16 Jun 2003 16:39:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S0j4-0006Tl-00 for mmusic@ietf.org; Mon, 16 Jun 2003 16:37:14 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19S0j2-0006TH-00 for mmusic@ietf.org; Mon, 16 Jun 2003 16:37:13 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn3-403.cisco.com [10.21.65.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5GKcr6q018595; Mon, 16 Jun 2003 13:38:54 -0700 (PDT) Message-Id: <5.1.1.5.2.20030616133516.05ad13c0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 16 Jun 2003 13:38:52 -0700 To: From: Mark Baugher Subject: Re: [MMUSIC] SSRC in SDP Cc: In-Reply-To: <003c01c33111$2b78fbe0$1703a8c0@EDLUFF> 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: , Ed, At 02:33 PM 6/12/2003 -0400, Ed Luff wrote: >The Synchronization Source (SSRC) is passed in the RTP and RTCP headers, >which uniquely identifies a particular media stream. > >There are some good benefits to including the Synchronization Source >(SSRC) within the SDP, including the prevention of uncontrolled barge-in >or eavesdropping (within the network) and multiplexing media streams >over the same receiving port. The only downside that I have come across >is the need for the application to appropriately handle the possibility >of two clients generating the same random SSRC, which seems minor in >nature. > >Instead of having each session oriented protocol (SIP, RTSP, MGCP and >H.323) include support through an extension, would it not be a good idea >simply to have the SSRC included within the SDP? I have seen proposals >in H.323 and RTSP, where the extension is a bit messy, as the clients >must signal their support of the extension in the call setup... > >I have included some references and information below, which support the >need for SSRC signaling. > >Thoughts? I think that including the SSRC is a necessary evil for SRTP. Ideally, we would not need to interfere with normal RTP processing in this way by requiring that the SSRC be pre-determined. But the SSRC is used for the lookup of the SRTP cryptographic context and for computation of the initialization vector. I think we would prefer to avoid forcing SSRC determination prior to session commencement when possible. Mark >Ed > >- "SDP Security Descriptions for Media Streams", >, February 2003. > >- "How to make Real-Time Streaming Protocol (RTSP) traverse Network >Address Translators (NAT) and interact with Firewalls", >, February 2003. > >- H.323 has proposed the use of signaling the SSRC in the H.245 >signaling channel. The primary purpose is for multiplexing media >streams over the same receiving port. The proposal is shown below. > >H2250LogicalChannelParameters ::=SEQUENCE >{. > willUseSSRC NULL OPTIONAL, > ssrc INTEGER(0..4294967295) >OPTIONAL >} > H2250LogicalChannelAckParameters ::=SEQUENCE > { . > ssrc INTEGER(0..4294967295) >OPTIONAL > } > > >_______________________________________________ >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 Tue Jun 17 01:33:12 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 BAA17606 for ; Tue, 17 Jun 2003 01:33:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H5WiX08060 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 01:32:44 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H5Whm08057 for ; Tue, 17 Jun 2003 01:32:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17599 for ; Tue, 17 Jun 2003 01:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S933-0002mX-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 01:30:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S933-0002mU-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 01:30:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GG02a13733; Mon, 16 Jun 2003 12:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFxIm13675 for ; Mon, 16 Jun 2003 11:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18745 for ; Mon, 16 Jun 2003 11:59:15 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RwLt-0003WE-00 for mmusic@ietf.org; Mon, 16 Jun 2003 11:57:01 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19RwLt-0003WB-00 for mmusic@ietf.org; Mon, 16 Jun 2003 11:57:01 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id E84F655BB1; Mon, 16 Jun 2003 17:59:14 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA21596; Mon, 16 Jun 2003 17:59:14 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p2/8.8.5-1.2.2m-19990317) with ESMTP id RAA01567; Mon, 16 Jun 2003 17:59:13 +0200 (MEST) Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 16 Jun 2003 17:50:26 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 16/06/2003 18:00:17 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, all, here is the sumary/result after the reflector exchanges: ***************************** 1) The core RTSP spec needs a few clarifications about redirection (that -in short- [redirection=failure]) 1.A) There is a need for a piece of text explaining that in general the server providing the RTSP streaming service (i.e. SETUP etc ...) is assumed to also be the one that provides the session description (i.e. DESCRIBE) [reasons: simplicity/logic, easier to do interrop testing, backward compatibility] 1.B) Specifically a minimal RTSP client implementation does not need to expect that the response to DESCRIBE would be used to point to another server whatever mean would be used for that (i.e. content-location, absolute URL is SDP etc) unless it is signaled *explicitely* as a redirection: 1.C) Specifically if a server wishes to redirect a client at DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx code (TBD) and the answer MUST NOT contain any SDP (i.e. this is the single minimal interoperable RTSP redirection behavior). The "Location" header MUST be used to point out the new server. (magnus westerlung wrote: "This MUST level may not be totally clear in draft-03 and should be reviewed"). 1.D) following which a minimal RTSP client implementation MUST issue a DESCRIBE on the alternate server (i.e. start from scratch) designated in the "Location" header. ***************************** 2) However a separately documented (and separately interop tested) improvement would be to define "implicit RTSP redirection" i.e. -in short- [redirection=success] 2.A) "implicit RTSP redirection" is an *optional* "optimization" which usage involves a *feature tag*. Such advanced client would issue the DESCRIBE with the corresponding feature tag (TBD) signaling that it is able to receive an "implicit redirection" (servers MUST NOT use implicit RTSP redirection if the feature tag was not present in the DESCRIBE request) OPEN ISSUE: the name of the feature tag, should it be "implicit-redir" ? 2.B) An "implicit redirection" is defined as a DESCRIBE response with a 2XX code (TBD) -because it contains a valid SDP- and it also contains a mean to redirect the client toward another (alternate) server. OPEN ISSUE: 200 or 2XX is open, minor benefit in using xx!= 00 2.C) The mean to indicate the new server is "Content-Base". 2.D) The client MAY then directly SETUP to the alternate server. NB:The purpose is to save one round trip. ************************** 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 Monday 16th of June 18.00 CET Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 13/06/2003 16:17 Hi, Sorry that I am late. There is a teleconference scheduled for monday (16th of June) at 18.00 CET. Included is the contact information and agenda. Cheers Magnus Conference Details: Telephone nr: +46 8 71 99500 Participant PIN: 21158 Date 06/16/2003 (MM/DD/YYYY) Start Time 18:00 (HH:MM) CET Agenda: ------- 1. Opening of meeting. 2. Administrative a. IETF Vienna b. Authoring and Specification - Aravind co-author - Working on the specification. 3. Since last meeting (28th of May). a. Bug 533691 & 513880 - Updated text received, include in specification? b. http://rtsp.org/bug556295 - Text received, include in specification? c. Multiple SSRC in RTSP. - Text received, include in specification? d. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration and clear rules - Magnus to write text and question to list. f. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Magnus to write text. g. http://rtsp.org/742348 - Usage of implicit REDIRECT. - Philippe and Yves has written to the list. Resolve discussion. 3. New Things a. REDIRECT to automatically close session. Problem description: With the clarification the result of the REDIRECT request without session header closes the RTSP message connection, does this mean that the session has automatically been closed? If Yes, should the same behaviour be used also when session header is present? 5. Any other Issues 6. Next meeting - Proposal: IETF meeting? 7. End meeting -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jun 17 02:00:06 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 CAA18197 for ; Tue, 17 Jun 2003 02:00:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H5xb010395 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 01:59:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H5xbm10392 for ; Tue, 17 Jun 2003 01:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18113 for ; Tue, 17 Jun 2003 01:59:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S9T5-0002uX-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 01:57:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S9T4-0002uU-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 01:57:18 -0400 Received: from www1.ietf.org (a.mx.viagraonlinenow.biz [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GIx1a26678; Mon, 16 Jun 2003 14:59:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GIwhm26652 for ; Mon, 16 Jun 2003 14:58:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25442 for ; Mon, 16 Jun 2003 14:58:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rz9W-0005Eu-00 for mmusic@ietf.org; Mon, 16 Jun 2003 14:56:26 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19Rz9V-0005El-00 for mmusic@ietf.org; Mon, 16 Jun 2003 14:56:25 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5GIw94Z015137 for ; Mon, 16 Jun 2003 11:58:09 -0700 (PDT) Received: from sun.com (vpn-129-150-19-103.SFBay.Sun.COM [129.150.19.103]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id LAA20010 for ; Mon, 16 Jun 2003 11:58:08 -0700 (PDT) Message-ID: <3EEE131D.4060407@sun.com> Date: Mon, 16 Jun 2003 14:57:33 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] Clarification of use and association of SSRCs in RTSP References: <3ED4CB4B.10607@sun.com> In-Reply-To: <3ED4CB4B.10607@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm clarifying the edits I had proposed before the May 28th concall in the RTSP draft with regards to the SSRC field. See inline for comments. Aravind Aravind Narasimhan wrote: > Hi folks, > This is two-fold attempt to clarify how ssrc's are dealt with in > RTSP. First, is a clarification of the use of the ssrc fields in the > Transport header. Next is a clarification of the association of > stream ssrcs with other stream information in the RTP-Info header. [snip] > Reword To: > RTCP: Is used to report transport statistics and SHALL also work as > keep alive. The server can determine the client by used net- > work address and port together with the fact that the client > is reporting on the server's SSRC(s). The first source > being | > reported on in a Reciever Report should be the SSRC of > the | > server as established from the ssrc field of the > transport | > header of the SETUP response. A downside of using RTCP > is | > that it gives lower statistical guarantees to reach > the | > server. However that probability is so little that it can be > ignored in most cases. For example, a session with 60 seconds > timeout and enough bitrate assigned to the RTCP messages, so > the client sends a message on average every 5 seconds. That > session have for a network with 5 % packet loss the probabil- > ity to not get a liveness sign over to the server in the time- > out interval is 2.4*E-16. In sessions with shorter timeout > times, or much higher packet loss, or small RTCP bandwidths > SHOULD use any of the mechanisms below. In light of comments from the concall of May 28th, I am removing the edits made to the above paragraph. The full body of edits made to the spec with regards to clarification of the use of SSRCs is included below: Section 13.40, Page 79: ssrc: The ssrc parameter indicates the RTP SSRC [23] value that should be (request) or will be (response) used by the media server. This parameter is only valid for unicast transmission. It identifies the synchronization source to be associated with the media stream, and is expressed as an eight digit hexideci- mal value. In cases that a sender will use multiple SSRCs it SHOULD NOT use this parameter. Reword To: ssrc: The ssrc parameter, if included in a SETUP response, | indicates the RTP SSRC [23] value that will be used by the | media server within the stream. It is expressed as an eight | digit hexadecimal value. If the server does not act as a syn- | chronization source for stream data (for instance, server is a | translator or reflector, etc.) the value will be the "packet | sender's SSRC" that would be used in the RTCP Receiver Reports | generated by the server, regardless of whether the server | actually generates RTCP RRs. If there are mutiple sources | within the stream, the ssrc parameter only indicates the value | for a single sychronization source. Other sources must be | deduced from the actual RTP/RTCP stream. | The functionality of specifing the ssrc parameter in a SETUP | request is deprecated as it is incompatible with the specifica- | tion of RTP in RFC 1889. If the parameter is included in the | transport header of a SETUP request, the server may ignore the | it, and choose an appropriate SSRC for the stream. It MAY set | the ssrc parameter in the transport header of the response. | Section 13.40, Page 79: client_ssrc: The client_ssrc parameter indicates the RTP SSRC [23] value that will be used by the client. This parameter is only valid for unicast transmission. It identifies the synchroniza- tion source to be associated with the media stream, and is expressed as an eight digit hexidecimal value. In cases that a client will use multiple SSRCs it SHOULD NOT use this parame- ter. Reword To: client_ssrc: The client_ssrc parameter, if included in a SETUP | request, indicates the RTP SSRC [23] value that will be used by | the client. It is expressed as an eight digit hexadecimal | value. If the client does not act as a sychronization source | for stream data (for instance, client is a player or proxy or | intermediary, etc.) the value will be the "packet sender's | SSRC" that would be used in the RTCP Receiver Reports generated | by the client. If there are mutiple sources within the stream, | the client_ssrc parameter only indicates the value for a single | sychronization source. Other sources must be deduced from the | actual RTP/RTCP stream. | A server SHALL NOT specify the client_ssrc parameter in a SETUP | response. Section 13.33, Page 70 13.33 RTP-Info The RTP-Info response-header field is used to set RTP-specific param- eters in the PLAY response. For streams using RTP as transport proto- col the RTP-Info header SHALL be part of a 200 response to PLAY. url: Indicates the stream URL which for which the following RTP parameters correspond, this URL MUST be the same used in the SETUP request for this media stream. Any relative URL SHALL use the request URL as base URL. seq: Indicates the sequence number of the first packet of the stream. This allows clients to gracefully deal with packets when seeking. The client uses this value to differentiate packets that originated before the seek from packets that originated after the seek. rtptime: Indicates the RTP timestamp corresponding to the time value in the Range response header. (Note: For aggregate con- trol, a particular stream may not actually generate a packet for the Range time value returned or implied. Thus, there is no guarantee that the packet with the sequence number indicated by seq actually has the timestamp indicated by rtp- time.) The client uses this value to calculate the mapping of RTP time to NPT. A mapping from RTP timestamps to NTP timestamps (wall clock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP times- tamps to NPT. Furthermore, in order to ensure that this information is available at the necessary time (immedi- ately at startup or after a seek), and that it is deliv- ered reliably, this mapping is placed in the RTSP control channel. In order to compensate for drift for long, uninterrupted pre- sentations, RTSP clients should additionally map NPT to NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping. Reword to: 13.33 RTP-Info The RTP-Info response-header field is used to set RTP-specific param- eters in the PLAY response. These parameters correspond to the syn- | chronization source indentified by the 'ssrc' parameter of the | Transport response header in the SETUP reponse. For streams using | RTP as transport protocol the RTP-Info header SHALL be part of a 200 | response to PLAY. | url: Indicates the stream URL which for which the following RTP parameters correspond, this URL MUST be the same used in the SETUP request for this media stream. Any relative URL SHALL use the request URL as base URL. seq: Indicates the sequence number of the first packet of the stream. This allows clients to gracefully deal with packets when seeking. The client uses this value to differentiate packets that originated before the seek from packets that originated after the seek. rtptime: Indicates the RTP timestamp corresponding to the time value in the Range response header. (Note: For aggregate con- trol, a particular stream may not actually generate a packet for the Range time value returned or implied. Thus, there is no guarantee that the packet with the sequence number indicated by seq actually has the timestamp indicated by rtp- time.) The client uses this value to calculate the mapping of RTP time to NPT. A mapping from RTP timestamps to NTP timestamps (wall clock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP times- tamps to NPT. Furthermore, in order to ensure that this information is available at the necessary time (immedi- ately at startup or after a seek), and that it is deliv- ered reliably, this mapping is placed in the RTSP control channel. In order to compensate for drift for long, uninterrupted pre- sentations, RTSP clients should additionally map NPT to NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping. Additionally, the RTP-Info header parameter fields only apply | to a single SSRC within a stream (the SSRC reported in the | transport response header; see 13.40). If there are multiple | synchronization sources present within a RTP session, RTCP must | be used to map RTP and NTP timestamps for those sources, for | both synchronization and drift-checking. | _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Jun 17 03:26:32 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 DAA01776 for ; Tue, 17 Jun 2003 03:26:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H7Q3831459 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 03:26:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7Q3m31456 for ; Tue, 17 Jun 2003 03:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01761 for ; Tue, 17 Jun 2003 03:26:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SAoj-0003hW-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 03:23:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SAoj-0003hT-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 03:23:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLw2a08062; Mon, 16 Jun 2003 17:58:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLvhm08033 for ; Mon, 16 Jun 2003 17:57:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04622 for ; Mon, 16 Jun 2003 17:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1wj-0007OM-00 for mmusic@ietf.org; Mon, 16 Jun 2003 17:55:25 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19S1wg-0007OJ-00 for mmusic@ietf.org; Mon, 16 Jun 2003 17:55:22 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Mon, 16 Jun 2003 14:45:53 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Mon, 16 Jun 2003 14:45:52 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Mon, 16 Jun 2003 11:59:01 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19RzCR-0007vZ-00 for ; Mon, 16 Jun 2003 11:59:27 -0700 Date: Mon, 16 Jun 2003 11:58:16 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_20,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #78 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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-742328 ] How to handle PLAY request when at the end of a media clip (SourceForge.net) 2. [ rtspspec-Bugs-631957 ] Use of # and ? in RTSP URLs (SourceForge.net) 3. [ rtspspec-Bugs-513888 ] RTSP and NAT (SourceForge.net) 4. [ rtspspec-Bugs-477400 ] Play without range while playing (SourceForge.net) 5. [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range (SourceForge.net) 6. [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter (SourceForge.net) 7. [ rtspspec-Bugs-477424 ] How to queue timed plays? (SourceForge.net) 8. [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl (SourceForge.net) 9. [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method (SourceForge.net) 10. [ rtspspec-Bugs-513875 ] Play when in state ready after playing (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 13 Jun 2003 07:08:52 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip Bugs item #742328, was opened at 2003-05-23 15:44 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194 Category: None >Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: How to handle PLAY request when at the end of a media clip Initial Comment: This is a problem that has surfaced in interoperability test. It shouldn't surface in a correct implemented client talking to a correct server. However how should the server handle it if still happens. The scenario is: The server is playing a stored media clip to the client. The client has a certain amount of buffer space. The client hits PAUSE. However when the PAUSE request reaches the server the server has played all media for the clip. The server respond to the PAUSE request with a Range header containing the pause point. The problem arise when the client likes to resume the playout of the media to the end. The client has all the rest of the media already in its buffer and this should be totally local operation. There are three reasons I see why the client may not know that this is a local operation: 1. The client has not been informed about the duration of the media. Therefore it can use the pause point in the response to determine that the server is at the end of the media clip. 2. The server has not included the pause point in the PAUSE response, may happen for RFC 2326 servers. This is a MUST in the new specification. 3. The client does not check the duration against the given pause point. This the client SHOULD do to prevent this from happening. Any of the three above would result in that the client sends a PLAY request to resume playing (no range header) at the pause point. However the server is already at the of the media clip. So the big question is how the server handles this PLAY request? I can see two ways of resolving it and would like some input on which is the recommended one. A. The server sends a 200 OK on the request to continue. The RTP-Info is for the next packet which will not be sent as result of this PLAY request. The Range header response indicate that the server will play from the given end of the clip to the end of the clip. Then no RTP packets are sent. B. The server sends a 457 (Invalid Range) including in the response the range header for the pause point. In my opinion the best alternative is B. This clearly indicate to the client that no media will be delivered. Also it is in line with the semantics that a PLAY request is only performed when the range is within the media clip. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-13 16:08 Message: Logged In: YES user_id=302620 At the telecon 28th of May 2003 it was the conclusion to use resoultion b. Needs to be written up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:05:09 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-631957 ] Use of # and ? in RTSP URLs Bugs item #631957, was opened at 2002-11-01 09:49 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631957&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: Magnus Westerlund (magwes) Summary: Use of # and ? in RTSP URLs Initial Comment: The current BNF definition does not allow for use of # (fragments) but use of ? (Query). The text in chapter 3.2: "Note that fragment and query identifiers do not have a well-defined meaning at this time, with the interpretation left to the RTSP server." Seems to indicate that it should be allowed. How should the be resolved? Add # to url definition and don't define the behavior. Rewrite the note and say that they are not allowed. Or do we have any usefull meaning for it today? ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:05 Message: Logged In: YES user_id=302620 This needs to be reviewed further. Should look at the informational RFC regariding defining URL schemes: Guidelines for new URL Schemes ftp://ftp.rfc-editor.org/in-notes/rfc2718.txt And look what should be done to register it corretly: Registration Procedures for URL Scheme Names ftp://ftp.rfc-editor.org/in-notes/rfc2717.txt At the same time there is need to consider bug 707252. The definitions should be very clear on where one can include fragement and query and where not. It is also important to ensure that litteral IPv6 addresses are allowed. Se RFC 2732. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:27 Message: Logged In: YES user_id=3796 Minutes from 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html) # Magnus: new spec includes query and fragment # Rob: how does that work with streamids # Magnus: streamids are transparent to the server # Magnus: host part comes from RFC 2732 to allow for IPv6 # Magnus: Rest comes from RFC 2396 # Rob: We should rely on update to RFC 2396 # Magnus: There's work to update 2396, we can monitor that work # Magnus: Proposal allow fragment and query in RTSP URLs # Rob: is fragment allowed in HTTP spec? # Magnus: not sure # Anders: I've never seen it sent by a web browser # Magnus: any objections to including both # Rob: we should say no more, no less than HTTP spec # Anders: I thought that it was to reference an anchor in doc # Magnus: yes # Anders: client would probably use this then # RESOLUTION: Update RTSP URI spec to be standard URI and look at HTTP spec for use of fragment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631957&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:07:30 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513888 ] RTSP and NAT Bugs item #513888, was opened at 2002-02-06 19:53 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513888&group_id=23194 Category: General >Group: Fix - Discussed/Resolved >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: RTSP and NAT Initial Comment: RTSP today is not that NAT friendly. Can something be done to fix that problem or shouldn't at least a note about it be written in the new spec? If you don't have a ALG can this problem be fixed? Known NAT issues with RTSP is and possible solutions based on NAT and SIP work: 1. Receiver ports are specifed in transport header. Needs to either be translated by ALG or client must find out the ports that will be used on the public side of the NAT. Mechanism for this has been proposed for SIP. 2. Transport header does not support explicit specification of RTCP ports. This seem to be required if any NAT port discovery will be possible to use. 3. Keep alive traffic needs to be sent over NAT translated ports when in pause to prevent binding timeout. Not an issue for RTCP port but also RTP ports needs to receive traffic. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:07 Message: Logged In: YES user_id=302620 This issue has been moved into a seperate RTSP draft named: draft-ietf-mmusic-rtsp-nat-??.txt. Any discussion around this should be done in that drafts context. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 18:44 Message: Logged In: YES user_id=302620 A chapter has been created but needs more text. Please sign up for writing it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513888&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:11:51 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477400 ] Play without range while playing Bugs item #477400, was opened at 2001-11-02 08:15 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Play without range while playing Initial Comment: A PLAY request without a Range header is legal. It starts playing a stream from the beginning unless the stream has been paused. If a stream has been paused via PAUSE, stream delivery resumes at the pause point. If a stream is playing, such a PLAY request causes no ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ further action and can be used by the client to test server liveness. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In a response to play without range while playing, what shall the server do with RTP-Info? The RTP-Info is required according to table in the beginning of chapter 12, but my opinion is that it lacks meaning in this case. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:11 Message: Logged In: YES user_id=302620 A correction to previous comment, it is of course depreciated. This change has been editied in. No comments for a long while. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 10:25 Message: Logged In: YES user_id=302620 Further the use of PLAY for keep-alive is decapitaited. A 455 response will be received when used. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-05-24 20:01 Message: Logged In: YES user_id=3796 Added PING method: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.3&r2=1.4 ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 18:49 Message: Logged In: YES user_id=3796 We should deprecate this use of PLAY, and add a PING method (so that we can explicitly ensure there are no side effects) The nice thing about PING is that we can define it as bidirectional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:34:03 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range Bugs item #477423, was opened at 2001-11-02 08:45 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Unclearities regarding pause with range Initial Comment: How shall the pause point be specifed? Is the only correct way to do it "(start time)- "? The use of range with time? It seem to be unecessary as play with range works instead. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:34 Message: Logged In: YES user_id=302620 use of range is resolved and edited in. No comments for a year on this resolution. Closing bug. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-05-21 02:16 Message: Logged In: YES user_id=3796 Resolved with the following change: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.1&r2=1.2 ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-13 02:12 Message: Logged In: YES user_id=437905 RESOLVED: Only a single range specifier (format "value-" where "value" is a time) is allowed for pause. time="execution time in UTC" may also be used, but if multiple range specifiers are present, npt/smpte takes precence over time. A new example will be provided. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:03 Message: Logged In: YES user_id=3796 Does need clarification in specification, but probably warrents discussion. Recommendation: end time in range is ignored ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:37:45 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter Bugs item #755472, was opened at 2003-06-16 20:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194 Category: None Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Restricted use of Range header time parameter Initial Comment: The Range header's time parameter has been deprecated from use in PLAY and PAUSE method. The only method still using the time parameter is REDIRECT. The decision to stop using time= for PAUSE and PLAY was discussed at the 56th IETF and at the April 16th telecon. Reasons is that they create hard synchronization problems and possilbe failure modes that does not give the client any error codes. There was also no need seen for the functionality. The change has been edited in and will be published from version 4 of the draft. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:43:30 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477424 ] How to queue timed plays? Bugs item #477424, was opened at 2001-11-02 08:47 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: How to queue timed plays? Initial Comment: When you queue items that has a activation time, does that override the order of the events that are queued? Play(1) has time A, Play(2) has time B, time A are after time B. Assumption on how it work: First Play(2) activated at time B, then at time B Play(1) tries to start, if already playing, it is queued as a normal untimed event. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:43 Message: Logged In: YES user_id=302620 As also time plays has been removed this can definitly not happen. Closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 10:46 Message: Logged In: YES user_id=302620 A Queued play is removed, a timed play being activated while the session is in playing state will result in failure of type 455. This has been written up and checked in CVS. See new text for the PLAY method. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex?rev=1.12&content-type=text/vnd.viewcvs-markup Resolution needs review on spec text. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-13 02:44 Message: Logged In: YES user_id=437905 RESOLVED: Propose elimination of queued play to list. Separate email necessary. RESOLVED: postpone 477424 until queue play is resolved. ACTION ITEM (RL): submit proposal to eliminate queued play. ACTION ITEM (MW): continuous sequence number filing. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:04 Message: Logged In: YES user_id=3796 Interpretation is correct. Do you (or anyone in the working group) have a proposal for text to drop into the spec? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:49:40 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl Bugs item #477428, was opened at 2001-11-02 08:51 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Priorites between aggregated & non cntrl Initial Comment: A single media stream is playing. Then an aggregated control which include this stream is issued a play. How should this be interpreted? I use that it is queue and waits until all single streams under that aggregated control finish their play. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:49 Message: Logged In: YES user_id=302620 Has been resolved, no comment. Closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 10:59 Message: Logged In: YES user_id=302620 Aggregated control has been resolved so that it is determined by the sessions state. If more than one stream is set up in a RTSP session only aggregated control is allowed. This has been incorperated into the draft. Changes in PLAY, PAUSE and state machine to explain this. Further work on RECORD needs to incorperate this also. A note is added to that chapter. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-13 02:45 Message: Logged In: YES user_id=437905 RESOLVED: Await resolution of queued play. Aggregate control issue needs larger discussion. ACTION ITEM: Write up aggregate URL proposal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:52:16 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method Bugs item #513891, was opened at 2002-02-06 19:56 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513891&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Magnus Westerlund (magwes) Summary: Clarify use of Range in REDIRECT method Initial Comment: Section 10.10 says that the REDIRECT command can specify the Range header, to specify when the redirection should take place. The example shows a Range header that specificies an absolute time (UTC time.) Is it also possible to specify an NPT time for the REDIRECT command? How should a client interpret the end of the range when the Range header appears in the REDIRECT command? One way to interpret the end range time is to say that the client should connect back to the original server after that time. So, for example, if ServerA sends this command: REDIRECT rtsp://ServerB/foo RTSP/1.0 Range: npt=45-60 It could mean that the client should keep streaming from ServerA for time being, but when it reaches time NPT=45 in the presentation, then it should connect to ServerB and keep streaming from there for 15 seconds. After the time of the presentation reaches NPT=60, then the client will connect back to ServerA and continue streaming from there. Somehow, I feel that this might not be exactly what the authors of the spec had in mind. The spec needs to be clarified so that there is no ambiguity about how to interpret the Range header in this case. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:52 Message: Logged In: YES user_id=302620 The text has been updated and contains a resolution that support all time formats and a wall clock time for when a REDIRECT shall take place. Has been present for a while without comments. Closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-24 15:44 Message: Logged In: YES user_id=302620 New text is proposed on how range should work for REDIRECT. A issue remains for the proposed solution. If conent has UTC time scale and one desires a redirect relative to the media this solution does not work. Also see bug #531189 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513891&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:57:41 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513875 ] Play when in state ready after playing Bugs item #513875, was opened at 2002-02-06 19:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513875&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Play when in state ready after playing Initial Comment: A client has been playing for a while and reaches the end of either media or range. At that time the state machine goes to state ready. When in state ready a play without range is issued. The question is what happends at this point: 1. The play starts from the begining of the media. 2. If at end of media directly revert to ready, or if a play with range was the previous play continue at the end of that range. Both interpretations has been implemented. So please give your opinion on this, especially if you have arguments supporting one or the other, like usage cases. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:57 Message: Logged In: YES user_id=302620 Has been resolved for a while. No comment. closing bug. Text present in specifaction. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 18:28 Message: Logged In: YES user_id=302620 This has been discussed and the propsed change is: A PLAY request must contain a range header that rewinds to the beginning. A PAUSE will be required to make the state machine go to ready state before issuing the rewinding PLAY. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513875&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 Tue Jun 17 10:24:56 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 KAA19112 for ; Tue, 17 Jun 2003 10:24:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HEOSH32559 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 10:24:28 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEOSm32556 for ; Tue, 17 Jun 2003 10:24:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19012 for ; Tue, 17 Jun 2003 10:24:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHLc-0007iZ-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 10:22:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SHLb-0007he-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 10:22:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8E2a04717; Tue, 17 Jun 2003 04:14:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8DPm04686 for ; Tue, 17 Jun 2003 04:13:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03285 for ; Tue, 17 Jun 2003 04:13:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBYZ-00042C-00 for mmusic@ietf.org; Tue, 17 Jun 2003 04:11:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19SBYY-000422-00 for mmusic@ietf.org; Tue, 17 Jun 2003 04:11:06 -0400 Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5H8Cmsm002484; Tue, 17 Jun 2003 04:12:50 -0400 (EDT) Message-ID: <3EEECD7C.8020101@dynamicsoft.com> Date: Tue, 17 Jun 2003 04:12:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: Jiri Kuthan , mmusic@ietf.org Subject: Re: [MMUSIC] re: what happens if both SIP UAs want to be active References: <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> In-Reply-To: <5.1.1.6.0.20030616130712.03a3d008@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 Right. That would be a 488 or 606 response code. We also use the Warning header to convey more detailed information on exactly what happened. It might be useful to register, through IANA, a new warn-code for this particular case. -Jonathan R. David Yon wrote: > The SIP gurus can chime in, but seems to me it would be in the same > category as not being able to come to an agreement vis-a-vis which codec > to use. > > At 12:25 PM 6/16/2003, Jiri Kuthan wrote: > >> [sorry, misthreaded -- I copy'n'pasted from archive since I was stripped >> off the recepient list] >> >> What does it mean SIP-wise that negotiation fails? >> >> I mean it would be great to have a special code for this error which >> allows SIP entities to recognized these conditions and act approprietly. >> >> -Jiri >> >> on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: >> > If they both want to be active, the negotiation fails. >> >> >> At 12:47 PM 6/7/2003, Jiri Kuthan wrote: >> >> David, >> >> >> >> can you please explain me how SIP signaling proceeds if two UAs both >> >> with to have direction=active, since they are behind symmetric NATs? >> >> >> >> Thanks, >> >> >> >> -jiri >> >> -- >> Jiri Kuthan http://iptel.org/~jiri/ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 17 14:15:56 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 OAA29891 for ; Tue, 17 Jun 2003 14:15:55 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFQJ12882 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKsC-0002Y2-Sg for mmusic-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:08:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29151 for ; Tue, 17 Jun 2003 14:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKpx-0002Tp-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 14:05:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKpw-0002Tm-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 14:05:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEs2a02595; Tue, 17 Jun 2003 10:54:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HErVm02560 for ; Tue, 17 Jun 2003 10:53:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20645 for ; Tue, 17 Jun 2003 10:53:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHnk-0000FZ-00 for mmusic@ietf.org; Tue, 17 Jun 2003 10:51:12 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SHnj-0000FT-00 for mmusic@ietf.org; Tue, 17 Jun 2003 10:51:11 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HEsHcv003062; Tue, 17 Jun 2003 16:54:18 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ1XY7; Tue, 17 Jun 2003 16:54:53 +0200 Message-ID: <3EEF2AAD.3080209@ericsson.com> Date: Tue, 17 Jun 2003 16:50:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: philippe.gentric@philips.com, IETF MMUSIC WG References: <20030617142012.GA14599@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Implicit redirection Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Philippe and Tom, I agree with Tom here. It would be much simpler to just specify that any received SDP can point to another host using the a=control URLs. If you do DESCRIBE on the aggregated control URL you should receive the same SDP description. The only implementation simplifying restriction I would like to introduce is that all media streams SHOULD be served by the same server. Any counter reasons? Best Regards Magnus Tom Marshall wrote: > This all seems overly complex and inconsistent to me. Why are people > trying > so hard to insist that the SDP come from the same server as the media? > If > we simply require that the client honor the hostname in the complete > stream > urls (whether from Content-Base or a=control) everything becomes very > simple > and constistent. > > If we require the client to make different assumptions based on whether > the > SDP came from the current RTSP control connection or via another means, > we > require a series of workarounds to make it work properly: > > - An inconsistent message with respect to urls. We are requiring that > clients explicitly ignore the hostname in certain situations. > > - Inconsistent behavior through proxies. A proxy will always honor the > hostname but clients are forbidden from doing so. > > - More complexity: another feature tag and 2xx response code to > support. > > If we simply require the client to honor the hostname in the stream > urls, > all of the above issues go away. The only changes are as follows: > > - The client MUST be prepared to examine the hostname and, if > necessary, > reconnect for the SETUP. This seems a pretty simple thing to > implement. > > - The typical non-redirecting server SHOULD take care to echo the > hostname > exactly as it appears in the client request in order to make the > client's > hostname comparison easy. The server should already be doing this. > > Remember, the notion that a DESCRIBE response not redirect the client > was > only added in an attempt to reduce the complexity of RTSP. If it is not > serving that purpose, it should be removed. > > -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 17 15:23:48 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 PAA06034 for ; Tue, 17 Jun 2003 15:23:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNIP11337 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLVe-0005xk-8I for mmusic-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:48:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02464 for ; Tue, 17 Jun 2003 14:48:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLTN-0003Bu-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 14:46:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLTN-0003Bq-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 14:46:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEK2a32256; Tue, 17 Jun 2003 10:20:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEJgm32200 for ; Tue, 17 Jun 2003 10:19:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18580 for ; Tue, 17 Jun 2003 10:19:38 -0400 (EDT) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHH0-0007c1-00 for mmusic@ietf.org; Tue, 17 Jun 2003 10:17:22 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SHH0-0007bx-00 for mmusic@ietf.org; Tue, 17 Jun 2003 10:17:22 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5HEJba16709 for ; Tue, 17 Jun 2003 17:19:37 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Jun 2003 17:19:37 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 17:19:36 +0300 Received: from trebe006.NOE.Nokia.com ([172.22.232.181]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 17:19:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET Date: Tue, 17 Jun 2003 17:19:35 +0300 Message-ID: Thread-Topic: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET Thread-Index: AcM0kN53iN/Q0SyOSQKmrhpuO9lhuwARhIbQ To: Cc: X-OriginalArrivalTime: 17 Jun 2003 14:19:36.0504 (UTC) FILETIME=[7B257380:01C334DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HEJgm32201 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Philippe, all, I have some comments on the redirection at DESCRIBE phase. My concern is on the explicit redirection, not the implicit redirection, on which I agree with you. > 1.C) Specifically if a server wishes to redirect a client at > DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx > code (TBD) and the answer MUST NOT contain any SDP (i.e. this is > the single minimal interoperable RTSP redirection behavior). The > "Location" header MUST be used to point out the new server. > (magnus westerlung wrote: "This MUST level may not be totally > clear in draft-03 and should be reviewed"). > So, does this mean that a REDIRECT request sent by the server to a DESCRIBE request (before any DESCRIBE response, which may not even be sent by the server) would be invalid? The following scenario: Client->Server1: DESCRIBE .... Server1->Client REDIRECT .... (with Location header pointing to the Server2's location) Server1 sends a REDIRECT request containing the Location header to the client, instead of sending the SDP description in a DESCRIBE response. Client simply disconnects from Server1, and connects to Server2, if it wishes to. I guess this is not an invalid scenario, right? > 1.D) following which a minimal RTSP client implementation MUST > issue a DESCRIBE on the alternate server (i.e. start from > scratch) designated in the "Location" header. I think it would be better to add: "if the RTSP client is willing to have an RTSP session with the redirected server" to the beginning of this statement. The above statement sounds as if a DESCRIBE request is mandatory to be sent after a redirection, regardless of the client's will to start a new session. Best Regards, Emre Emre Baris Aksu Nokia Mobile Phones > -----Original Message----- > From: ext philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: 16 June, 2003 18:50 > To: Magnus Westerlund > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET > > > Magnus, all, > > > here is the sumary/result after the reflector exchanges: > > > ***************************** > 1) The core RTSP spec needs a few clarifications about > redirection (that -in short- [redirection=failure]) > > 1.A) There is a need for a piece of text explaining that in > general the server providing the RTSP streaming service (i.e. > SETUP etc ...) is assumed to also be the one that provides the > session description (i.e. DESCRIBE) [reasons: simplicity/logic, > easier to do interrop testing, backward compatibility] > > 1.B) Specifically a minimal RTSP client implementation does not > need to expect that the response to DESCRIBE would be used to > point to another server whatever mean would be used for that > (i.e. content-location, absolute URL is SDP etc) unless it is > signaled *explicitely* as a redirection: > > 1.C) Specifically if a server wishes to redirect a client at > DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx > code (TBD) and the answer MUST NOT contain any SDP (i.e. this is > the single minimal interoperable RTSP redirection behavior). The > "Location" header MUST be used to point out the new server. > (magnus westerlung wrote: "This MUST level may not be totally > clear in draft-03 and should be reviewed"). > > 1.D) following which a minimal RTSP client implementation MUST > issue a DESCRIBE on the alternate server (i.e. start from > scratch) designated in the "Location" header. > > ***************************** > 2) However a separately documented (and separately interop > tested) improvement would be to define "implicit RTSP > redirection" i.e. -in short- [redirection=success] > > 2.A) "implicit RTSP redirection" is an *optional* "optimization" > which usage involves a *feature tag*. Such advanced client would > issue the DESCRIBE with the corresponding feature tag (TBD) > signaling that it is able to receive an "implicit redirection" > (servers MUST NOT use implicit RTSP redirection if the feature > tag was not present in the DESCRIBE request) > > OPEN ISSUE: the name of the feature tag, should it be > "implicit-redir" ? > > 2.B) An "implicit redirection" is defined as a DESCRIBE response > with a 2XX code (TBD) -because it contains a valid SDP- and it > also contains a mean to redirect the client toward another > (alternate) server. > > OPEN ISSUE: 200 or 2XX is open, minor benefit in using xx!= 00 > > 2.C) The mean to indicate the new server is "Content-Base". > > 2.D) The client MAY then directly SETUP to the alternate server. > > NB:The purpose is to save one round trip. > > > ************************** > > 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 Monday 16th of June 18.00 > CET > > > > Magnus Westerlund > Classification: > > > > com> > > > > > > Sent by: > > > mmusic-admin@ietf.org > > > > > > 13/06/2003 16:17 > > > > > > > > > > > > > Hi, > > Sorry that I am late. There is a teleconference scheduled for monday > (16th of June) at 18.00 CET. Included is the contact > information and agenda. > > Cheers > > Magnus > > > Conference Details: > > Telephone nr: +46 8 71 99500 > Participant PIN: 21158 > Date 06/16/2003 (MM/DD/YYYY) > Start Time 18:00 (HH:MM) CET > > Agenda: > ------- > 1. Opening of meeting. > 2. Administrative > a. IETF Vienna > b. Authoring and Specification > - Aravind co-author > - Working on the specification. > 3. Since last meeting (28th of May). > a. Bug 533691 & 513880 > - Updated text received, include in specification? > b. http://rtsp.org/bug556295 - Text received, include in > specification? > c. Multiple SSRC in RTSP. > - Text received, include in specification? > d. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration > and clear rules > - Magnus to write text and question to list. > f. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Magnus to write text. > g. http://rtsp.org/742348 - Usage of implicit REDIRECT. > - Philippe and Yves has written to the list. Resolve discussion. > > 3. New Things > > a. REDIRECT to automatically close session. > > Problem description: > With the clarification the result of the REDIRECT request without > session header closes the RTSP message connection, does this mean that > the session has automatically been closed? If Yes, should the same > behaviour be used also when session header is present? > > 5. Any other Issues > 6. Next meeting - Proposal: IETF meeting? > 7. End meeting > > > -- > > > 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@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 17 15:23: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 PAA06050 for ; Tue, 17 Jun 2003 15:23:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNID11319 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLUO-0005t3-Oj for mmusic-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02362 for ; Tue, 17 Jun 2003 14:47:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLS8-0003AZ-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 14:45:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLS7-0003AW-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 14:45:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEM1a32377; Tue, 17 Jun 2003 10:22:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HELEm32334 for ; Tue, 17 Jun 2003 10:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18703 for ; Tue, 17 Jun 2003 10:21:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHIU-0007dg-00 for mmusic@ietf.org; Tue, 17 Jun 2003 10:18:54 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19SHIT-0007cU-00 for mmusic@ietf.org; Tue, 17 Jun 2003 10:18:53 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19SHJk-0003oN-00; Tue, 17 Jun 2003 07:20:12 -0700 Date: Tue, 17 Jun 2003 07:20:12 -0700 From: Tom Marshall To: philippe.gentric@philips.com Cc: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET Message-ID: <20030617142012.GA14599@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This all seems overly complex and inconsistent to me. Why are people trying so hard to insist that the SDP come from the same server as the media? If we simply require that the client honor the hostname in the complete stream urls (whether from Content-Base or a=3Dcontrol) everything becomes very sim= ple and constistent. If we require the client to make different assumptions based on whether the SDP came from the current RTSP control connection or via another means, we require a series of workarounds to make it work properly: - An inconsistent message with respect to urls. We are requiring that clients explicitly ignore the hostname in certain situations. - Inconsistent behavior through proxies. A proxy will always honor the hostname but clients are forbidden from doing so. - More complexity: another feature tag and 2xx response code to support. If we simply require the client to honor the hostname in the stream urls, all of the above issues go away. The only changes are as follows: - The client MUST be prepared to examine the hostname and, if necessary, reconnect for the SETUP. This seems a pretty simple thing to implement. - The typical non-redirecting server SHOULD take care to echo the hostname exactly as it appears in the client request in order to make the client's hostname comparison easy. The server should already be doing this. Remember, the notion that a DESCRIBE response not redirect the client was only added in an attempt to reduce the complexity of RTSP. If it is not serving that purpose, it should be removed. On Mon, Jun 16, 2003 at 05:50:26PM +0200, philippe.gentric@philips.com wrot= e: > Magnus, all, >=20 >=20 > here is the sumary/result after the reflector exchanges: >=20 >=20 > ***************************** > 1) The core RTSP spec needs a few clarifications about > redirection (that -in short- [redirection=3Dfailure]) >=20 > 1.A) There is a need for a piece of text explaining that in > general the server providing the RTSP streaming service (i.e. > SETUP etc ...) is assumed to also be the one that provides the > session description (i.e. DESCRIBE) [reasons: simplicity/logic, > easier to do interrop testing, backward compatibility] >=20 > 1.B) Specifically a minimal RTSP client implementation does not > need to expect that the response to DESCRIBE would be used to > point to another server whatever mean would be used for that > (i.e. content-location, absolute URL is SDP etc) unless it is > signaled *explicitely* as a redirection: >=20 > 1.C) Specifically if a server wishes to redirect a client at > DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx > code (TBD) and the answer MUST NOT contain any SDP (i.e. this is > the single minimal interoperable RTSP redirection behavior). The > "Location" header MUST be used to point out the new server. > (magnus westerlung wrote: "This MUST level may not be totally > clear in draft-03 and should be reviewed"). >=20 > 1.D) following which a minimal RTSP client implementation MUST > issue a DESCRIBE on the alternate server (i.e. start from > scratch) designated in the "Location" header. >=20 > ***************************** > 2) However a separately documented (and separately interop > tested) improvement would be to define "implicit RTSP > redirection" i.e. -in short- [redirection=3Dsuccess] >=20 > 2.A) "implicit RTSP redirection" is an *optional* "optimization" > which usage involves a *feature tag*. Such advanced client would > issue the DESCRIBE with the corresponding feature tag (TBD) > signaling that it is able to receive an "implicit redirection" > (servers MUST NOT use implicit RTSP redirection if the feature > tag was not present in the DESCRIBE request) >=20 > OPEN ISSUE: the name of the feature tag, should it be "implicit-redir" ? >=20 > 2.B) An "implicit redirection" is defined as a DESCRIBE response > with a 2XX code (TBD) -because it contains a valid SDP- and it > also contains a mean to redirect the client toward another > (alternate) server. >=20 > OPEN ISSUE: 200 or 2XX is open, minor benefit in using xx!=3D 00 >=20 > 2.C) The mean to indicate the new server is "Content-Base". >=20 > 2.D) The client MAY then directly SETUP to the alternate server. >=20 > NB:The purpose is to save one round trip. >=20 >=20 > ************************** >=20 > regards, >=20 >=20 > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com >=20 >=20 > = =20 > = =20 > To: IETF MMUSIC = WG =20 > cc: (bcc: Philip= pe Gentric/MP4-SUR/CE/PHILIPS) =20 > Subject: [MMUSI= C] RTSP telecon Monday 16th of June 18.00 CET =20 > = =20 > Magnus Westerlund Classification: = =20 > com> = =20 > = =20 > Sent by: = =20 > mmusic-admin@ietf.org = =20 > = =20 > 13/06/2003 16:17 = =20 > = =20 > = =20 >=20 >=20 >=20 >=20 > Hi, >=20 > Sorry that I am late. There is a teleconference scheduled for monday > (16th of June) at 18.00 CET. Included is the contact information and agen= da. >=20 > Cheers >=20 > Magnus >=20 >=20 > Conference Details: >=20 > Telephone nr: +46 8 71 99500 > Participant PIN: 21158 > Date 06/16/2003 (MM/DD/YYYY) > Start Time 18:00 (HH:MM) CET >=20 > Agenda: > ------- > 1. Opening of meeting. > 2. Administrative > a. IETF Vienna > b. Authoring and Specification > - Aravind co-author > - Working on the specification. > 3. Since last meeting (28th of May). > a. Bug 533691 & 513880 > - Updated text received, include in specification? > b. http://rtsp.org/bug556295 - Text received, include in specification? > c. Multiple SSRC in RTSP. > - Text received, include in specification? > d. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > e. http://rtsp.org/bug739845 - "a=3Drange" is missing IANA registration > and clear rules > - Magnus to write text and question to list. > f. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Magnus to write text. > g. http://rtsp.org/742348 - Usage of implicit REDIRECT. > - Philippe and Yves has written to the list. Resolve discussion. >=20 > 3. New Things >=20 > a. REDIRECT to automatically close session. >=20 > Problem description: > With the clarification the result of the REDIRECT request without > session header closes the RTSP message connection, does this mean that > the session has automatically been closed? If Yes, should the same > behaviour be used also when session header is present? >=20 > 5. Any other Issues > 6. Next meeting - Proposal: IETF meeting? > 7. End meeting >=20 >=20 > -- >=20 >=20 > Magnus Westerlund >=20 > 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@ericsson.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Biology is the only science in which multiplication means the same thing as division. --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+7yOcqznSmcYu2m8RAjn2AJ93HqBL1AF9bs3OKuKbJ0CzYF0otQCeLtSF jpTFLWfW1UUya01HHHgZx7Q= =q93h -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 17 20:38: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 UAA17317 for ; Tue, 17 Jun 2003 20:38:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I0c6K31559 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 20:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SQxi-0008Cw-0t for mmusic-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 20:38:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17310 for ; Tue, 17 Jun 2003 20:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SQvS-0006CX-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 20:35:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SQvS-0006CT-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 20:35:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SQxd-0008CY-2l; Tue, 17 Jun 2003 20:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SQwm-00082W-SO for mmusic@optimus.ietf.org; Tue, 17 Jun 2003 20:37:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17299 for ; Tue, 17 Jun 2003 20:37:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SQuX-0006CO-00 for mmusic@ietf.org; Tue, 17 Jun 2003 20:34:49 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19SQuW-0006C9-00 for mmusic@ietf.org; Tue, 17 Jun 2003 20:34:48 -0400 Received: from BuffaloJump (vpnclient18103.mcs.anl.gov [140.221.18.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h5I0aQt88374; Tue, 17 Jun 2003 19:36:26 -0500 Reply-To: From: "Ivan R. Judson" To: "'Magnus Westerlund'" , "'Tom Marshall'" Cc: , "'IETF MMUSIC WG'" Subject: RE: [MMUSIC] RTSP: Implicit redirection Date: Tue, 17 Jun 2003 19:36:24 -0500 Organization: Futures Laboratory Message-ID: <001901c33531$a5b75130$da15620c@mcs.anl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EEF2AAD.3080209@ericsson.com> Importance: Normal Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17317 > > The only implementation simplifying restriction I would like to > introduce is that all media streams SHOULD be served by the > same server. The only thing that springs to mind is the scalability constraint. If I understand this correctly, correctly synchronized playback of a session with a large number of streams becomes difficult. It's a moderately academic scaling point, but as we start recording and playing back 20-40 streams simultaneously on a regular basis (we've done it irregularly for years) it might become an issue. I haven't been following the details of this particular conversation, but this point did pique my interest -- what's the cost savings of requiring all streams from the same server? --Ivan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 17 22:31:30 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 WAA19693 for ; Tue, 17 Jun 2003 22:31:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I2V3q08709 for mmusic-archive@odin.ietf.org; Tue, 17 Jun 2003 22:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SSj1-0002GO-9a for mmusic-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 22:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19675 for ; Tue, 17 Jun 2003 22:30:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SSgk-0006oB-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 22:28:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SSgk-0006o8-00 for mmusic-web-archive@ietf.org; Tue, 17 Jun 2003 22:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SSiz-0002G0-F4; Tue, 17 Jun 2003 22:31:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G9Iem18356 for ; Mon, 16 Jun 2003 05:18:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06123 for ; Mon, 16 Jun 2003 05:18:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rq6C-0000uE-00 for mmusic@ietf.org; Mon, 16 Jun 2003 05:16:24 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19Rq6B-0000uB-00 for mmusic@ietf.org; Mon, 16 Jun 2003 05:16:23 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA13355; Mon, 16 Jun 2003 11:18:20 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA14434; Mon, 16 Jun 2003 11:17:22 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Mon, 16 Jun 2003 11:17:53 +0200 Message-ID: From: Belling Thomas To: "'mmusic@ietf.org'" Cc: "'mjh@icir.org'" , "'van@packetdesign.com'" , Schramm Mirko , "'juha.a.rasanen@NOKIA.COM'" , Klehn Norbert , "'ggfj@NORTELNETWORKS.COM'" , "'Reidar.Ericsson@emp.ericsson.se'" Date: Mon, 16 Jun 2003 11:17:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G9Iem18357 Subject: [MMUSIC] RTP bandwidth for multiple media streams Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA19675 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA19693 Hy Everybody, as suggested by Colin, I put my question on the mailing list. Comments are more then welcome. Is there an agreement to update the sdp-new draft according to Colin´s and my own interpretation? Cheers, Thomas ---------- From: Colin Perkins [mailto:csp@csperkins.org] Thomas, The spec is not clear, but I think I agree with your interpretation. I would suggest you also ask this question on the mmusic@ietf.org mailing list, so we can be sure there is consensus (and update the draft if necessary). cheers, Colin --> Belling Thomas writes: > Dear Mr. Handley, Mr. Jakobson, and Mr. Perkins, > > I wanted to ask you as the authors of the SDP new draft for your > interpretation of a problem we a currently discussing within 3GPP (The 3 > Generation Parnership Project standardizing mobile GSM and UMTS > networks). > > Consider the following SDP: > > c=IN IP4 224.2.1.1/127/2 > m=video 49170/2 RTP/AVP 31 > b=AS:64 > > My problem: How much bandwidth is associated with this "m=" line - > 64kbits or 128kbits? > > In the draft, you state that "b=AS" is similar to the RTP "session > bandwidth", as defined in RFC 1889. Consulting this RFC, I got stuck with > the definition of the "RTP Session". Consulting the definition in the RTP > new draft instead seems to suggest that the "m=" line describes two RTP > sessions. Therefore it seems that 128kbits may be the correct answer. Do > you agree with my interpretation? > > Clarity on this point is quite important for 3GPP, as the derived > bandwidth will be granted at the air interface, which is a scarce > resource where a factor of two makes a lot of difference. > > Best Regards and thank you very much for your help > > Th Belling > > > ---------------------------------- > Dr. Thomas Belling > Siemens AG > Sankt-Martinsstr. 76 > D-81542 München Germany > ICM N PG SP ST N1 > MCH M 34 307 > Tel +49 89 636 75207 > Fax +49 89 636 75577 > Mobile +49 172 2974678 > Email Thomas.Belling@siemens.com > > > > -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 18 10:10:53 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 KAA08691 for ; Wed, 18 Jun 2003 10:10:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEAQO11559 for mmusic-archive@odin.ietf.org; Wed, 18 Jun 2003 10:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdHI-0001Y1-Dq for mmusic-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 09:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06806 for ; Wed, 18 Jun 2003 09:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdF1-0004mO-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 09:44:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SdF0-0004mL-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 09:44:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9Q-0001Fd-KE; Wed, 18 Jun 2003 09:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SckS-000086-PY for mmusic@optimus.ietf.org; Wed, 18 Jun 2003 09:13:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04708 for ; Wed, 18 Jun 2003 09:13:00 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Schp-00049J-00 for mmusic@ietf.org; Wed, 18 Jun 2003 09:10:29 -0400 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 19Scho-00049G-00 for mmusic@ietf.org; Wed, 18 Jun 2003 09:10:28 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id DCD306C74A; Wed, 18 Jun 2003 15:12:45 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA27805; Wed, 18 Jun 2003 15:12:44 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA14197; Wed, 18 Jun 2003 15:12:36 +0200 (MEST) To: Tom Marshall Cc: Magnus Westerlund , IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 18 Jun 2003 15:01:42 +0200 Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/06/2003 15:13:40 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBE7DADFD4FEFC8f9e8a93df938690918c4EBBE7DADFD4FEFC" Content-Disposition: inline Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --0__=4EBBE7DADFD4FEFC8f9e8a93df938690918c4EBBE7DADFD4FEFC Content-type: text/plain; charset=us-ascii Tom, I agree. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: Magnus Westerlund IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET Tom Marshall Classification: 17/06/2003 16:20 This all seems overly complex and inconsistent to me. Why are people trying so hard to insist that the SDP come from the same server as the media? If we simply require that the client honor the hostname in the complete stream urls (whether from Content-Base or a=control) everything becomes very simple and constistent. If we require the client to make different assumptions based on whether the SDP came from the current RTSP control connection or via another means, we require a series of workarounds to make it work properly: - An inconsistent message with respect to urls. We are requiring that clients explicitly ignore the hostname in certain situations. - Inconsistent behavior through proxies. A proxy will always honor the hostname but clients are forbidden from doing so. - More complexity: another feature tag and 2xx response code to support. If we simply require the client to honor the hostname in the stream urls, all of the above issues go away. The only changes are as follows: - The client MUST be prepared to examine the hostname and, if necessary, reconnect for the SETUP. This seems a pretty simple thing to implement. - The typical non-redirecting server SHOULD take care to echo the hostname exactly as it appears in the client request in order to make the client's hostname comparison easy. The server should already be doing this. Remember, the notion that a DESCRIBE response not redirect the client was only added in an attempt to reduce the complexity of RTSP. If it is not serving that purpose, it should be removed. On Mon, Jun 16, 2003 at 05:50:26PM +0200, philippe.gentric@philips.com wrote: > Magnus, all, > > > here is the sumary/result after the reflector exchanges: > > > ***************************** > 1) The core RTSP spec needs a few clarifications about > redirection (that -in short- [redirection=failure]) > > 1.A) There is a need for a piece of text explaining that in > general the server providing the RTSP streaming service (i.e. > SETUP etc ...) is assumed to also be the one that provides the > session description (i.e. DESCRIBE) [reasons: simplicity/logic, > easier to do interrop testing, backward compatibility] > > 1.B) Specifically a minimal RTSP client implementation does not > need to expect that the response to DESCRIBE would be used to > point to another server whatever mean would be used for that > (i.e. content-location, absolute URL is SDP etc) unless it is > signaled *explicitely* as a redirection: > > 1.C) Specifically if a server wishes to redirect a client at > DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx > code (TBD) and the answer MUST NOT contain any SDP (i.e. this is > the single minimal interoperable RTSP redirection behavior). The > "Location" header MUST be used to point out the new server. > (magnus westerlung wrote: "This MUST level may not be totally > clear in draft-03 and should be reviewed"). > > 1.D) following which a minimal RTSP client implementation MUST > issue a DESCRIBE on the alternate server (i.e. start from > scratch) designated in the "Location" header. > > ***************************** > 2) However a separately documented (and separately interop > tested) improvement would be to define "implicit RTSP > redirection" i.e. -in short- [redirection=success] > > 2.A) "implicit RTSP redirection" is an *optional* "optimization" > which usage involves a *feature tag*. Such advanced client would > issue the DESCRIBE with the corresponding feature tag (TBD) > signaling that it is able to receive an "implicit redirection" > (servers MUST NOT use implicit RTSP redirection if the feature > tag was not present in the DESCRIBE request) > > OPEN ISSUE: the name of the feature tag, should it be "implicit-redir" ? > > 2.B) An "implicit redirection" is defined as a DESCRIBE response > with a 2XX code (TBD) -because it contains a valid SDP- and it > also contains a mean to redirect the client toward another > (alternate) server. > > OPEN ISSUE: 200 or 2XX is open, minor benefit in using xx!= 00 > > 2.C) The mean to indicate the new server is "Content-Base". > > 2.D) The client MAY then directly SETUP to the alternate server. > > NB:The purpose is to save one round trip. > > > ************************** > > 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 Monday 16th of June 18.00 CET > > Magnus Westerlund Classification: > com> > > Sent by: > mmusic-admin@ietf.org > > 13/06/2003 16:17 > > > > > > > Hi, > > Sorry that I am late. There is a teleconference scheduled for monday > (16th of June) at 18.00 CET. Included is the contact information and agenda. > > Cheers > > Magnus > > > Conference Details: > > Telephone nr: +46 8 71 99500 > Participant PIN: 21158 > Date 06/16/2003 (MM/DD/YYYY) > Start Time 18:00 (HH:MM) CET > > Agenda: > ------- > 1. Opening of meeting. > 2. Administrative > a. IETF Vienna > b. Authoring and Specification > - Aravind co-author > - Working on the specification. > 3. Since last meeting (28th of May). > a. Bug 533691 & 513880 > - Updated text received, include in specification? > b. http://rtsp.org/bug556295 - Text received, include in specification? > c. Multiple SSRC in RTSP. > - Text received, include in specification? > d. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration > and clear rules > - Magnus to write text and question to list. > f. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Magnus to write text. > g. http://rtsp.org/742348 - Usage of implicit REDIRECT. > - Philippe and Yves has written to the list. Resolve discussion. > > 3. New Things > > a. REDIRECT to automatically close session. > > Problem description: > With the clarification the result of the REDIRECT request without > session header closes the RTSP message connection, does this mean that > the session has automatically been closed? If Yes, should the same > behaviour be used also when session header is present? > > 5. Any other Issues > 6. Next meeting - Proposal: IETF meeting? > 7. End meeting > > > -- > > > 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@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Biology is the only science in which multiplication means the same thing as division. (See attached file: attl9e8w.dat) --0__=4EBBE7DADFD4FEFC8f9e8a93df938690918c4EBBE7DADFD4FEFC Content-type: application/octet-stream; name="attl9e8w.dat" Content-Disposition: attachment; filename="attl9e8w.dat" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMSAoR05V L0xpbnV4KQ0KDQppRDhEQlFFKzd5T2Nxem5TbWNZdTJtOFJBam4yQUo5M0hxQkwxQUY5YnMzT0t1 S2JKMEN6WUYwb3RRQ2VMdFNGDQpqcFRGTFdmVzFVVXlhMDFISEhnWng3UT0NCj1xOTNoDQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --0__=4EBBE7DADFD4FEFC8f9e8a93df938690918c4EBBE7DADFD4FEFC-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 18 10:10:54 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 KAA08707 for ; Wed, 18 Jun 2003 10:10:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEARl11645 for mmusic-archive@odin.ietf.org; Wed, 18 Jun 2003 10:10:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdLi-0001j6-Ot for mmusic-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 09:51:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07008 for ; Wed, 18 Jun 2003 09:51:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdJR-0004pw-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 09:49:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SdJR-0004pt-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 09:49:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd9R-0001Fx-KZ; Wed, 18 Jun 2003 09:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sco4-00009o-08 for mmusic@optimus.ietf.org; Wed, 18 Jun 2003 09:16:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05133 for ; Wed, 18 Jun 2003 09:16:53 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Scln-0004Hk-00 for mmusic@ietf.org; Wed, 18 Jun 2003 09:14:35 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19Sclm-0004Hd-00 for mmusic@ietf.org; Wed, 18 Jun 2003 09:14:34 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id D90F254CDB; Wed, 18 Jun 2003 15:16:50 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA03227; Wed, 18 Jun 2003 15:16:49 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA17299; Wed, 18 Jun 2003 15:16:47 +0200 (MEST) Subject: RE: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET To: emre.aksu@nokia.com Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 18 Jun 2003 14:59:58 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/06/2003 15:17:51 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: , emre, sorry with the late reply. I agree with what you wrote. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: Subject: RE: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET emre.aksu@nokia.com Classification: 17/06/2003 16:19 Hi Philippe, all, I have some comments on the redirection at DESCRIBE phase. My concern is on the explicit redirection, not the implicit redirection, on which I agree with you. > 1.C) Specifically if a server wishes to redirect a client at > DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx > code (TBD) and the answer MUST NOT contain any SDP (i.e. this is > the single minimal interoperable RTSP redirection behavior). The > "Location" header MUST be used to point out the new server. > (magnus westerlung wrote: "This MUST level may not be totally > clear in draft-03 and should be reviewed"). > So, does this mean that a REDIRECT request sent by the server to a DESCRIBE request (before any DESCRIBE response, which may not even be sent by the server) would be invalid? The following scenario: Client->Server1: DESCRIBE .... Server1->Client REDIRECT .... (with Location header pointing to the Server2's location) Server1 sends a REDIRECT request containing the Location header to the client, instead of sending the SDP description in a DESCRIBE response. Client simply disconnects from Server1, and connects to Server2, if it wishes to. I guess this is not an invalid scenario, right? > 1.D) following which a minimal RTSP client implementation MUST > issue a DESCRIBE on the alternate server (i.e. start from > scratch) designated in the "Location" header. I think it would be better to add: "if the RTSP client is willing to have an RTSP session with the redirected server" to the beginning of this statement. The above statement sounds as if a DESCRIBE request is mandatory to be sent after a redirection, regardless of the client's will to start a new session. Best Regards, Emre Emre Baris Aksu Nokia Mobile Phones > -----Original Message----- > From: ext philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: 16 June, 2003 18:50 > To: Magnus Westerlund > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET > > > Magnus, all, > > > here is the sumary/result after the reflector exchanges: > > > ***************************** > 1) The core RTSP spec needs a few clarifications about > redirection (that -in short- [redirection=failure]) > > 1.A) There is a need for a piece of text explaining that in > general the server providing the RTSP streaming service (i.e. > SETUP etc ...) is assumed to also be the one that provides the > session description (i.e. DESCRIBE) [reasons: simplicity/logic, > easier to do interrop testing, backward compatibility] > > 1.B) Specifically a minimal RTSP client implementation does not > need to expect that the response to DESCRIBE would be used to > point to another server whatever mean would be used for that > (i.e. content-location, absolute URL is SDP etc) unless it is > signaled *explicitely* as a redirection: > > 1.C) Specifically if a server wishes to redirect a client at > DESCRIBE time (e.g. for load balancing etc) it MUST issue a 3xx > code (TBD) and the answer MUST NOT contain any SDP (i.e. this is > the single minimal interoperable RTSP redirection behavior). The > "Location" header MUST be used to point out the new server. > (magnus westerlung wrote: "This MUST level may not be totally > clear in draft-03 and should be reviewed"). > > 1.D) following which a minimal RTSP client implementation MUST > issue a DESCRIBE on the alternate server (i.e. start from > scratch) designated in the "Location" header. > > ***************************** > 2) However a separately documented (and separately interop > tested) improvement would be to define "implicit RTSP > redirection" i.e. -in short- [redirection=success] > > 2.A) "implicit RTSP redirection" is an *optional* "optimization" > which usage involves a *feature tag*. Such advanced client would > issue the DESCRIBE with the corresponding feature tag (TBD) > signaling that it is able to receive an "implicit redirection" > (servers MUST NOT use implicit RTSP redirection if the feature > tag was not present in the DESCRIBE request) > > OPEN ISSUE: the name of the feature tag, should it be > "implicit-redir" ? > > 2.B) An "implicit redirection" is defined as a DESCRIBE response > with a 2XX code (TBD) -because it contains a valid SDP- and it > also contains a mean to redirect the client toward another > (alternate) server. > > OPEN ISSUE: 200 or 2XX is open, minor benefit in using xx!= 00 > > 2.C) The mean to indicate the new server is "Content-Base". > > 2.D) The client MAY then directly SETUP to the alternate server. > > NB:The purpose is to save one round trip. > > > ************************** > > 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 Monday 16th of June 18.00 > CET > > > > Magnus Westerlund > Classification: > > > > com> > > > > > > Sent by: > > > mmusic-admin@ietf.org > > > > > > 13/06/2003 16:17 > > > > > > > > > > > > > Hi, > > Sorry that I am late. There is a teleconference scheduled for monday > (16th of June) at 18.00 CET. Included is the contact > information and agenda. > > Cheers > > Magnus > > > Conference Details: > > Telephone nr: +46 8 71 99500 > Participant PIN: 21158 > Date 06/16/2003 (MM/DD/YYYY) > Start Time 18:00 (HH:MM) CET > > Agenda: > ------- > 1. Opening of meeting. > 2. Administrative > a. IETF Vienna > b. Authoring and Specification > - Aravind co-author > - Working on the specification. > 3. Since last meeting (28th of May). > a. Bug 533691 & 513880 > - Updated text received, include in specification? > b. http://rtsp.org/bug556295 - Text received, include in > specification? > c. Multiple SSRC in RTSP. > - Text received, include in specification? > d. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration > and clear rules > - Magnus to write text and question to list. > f. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Magnus to write text. > g. http://rtsp.org/742348 - Usage of implicit REDIRECT. > - Philippe and Yves has written to the list. Resolve discussion. > > 3. New Things > > a. REDIRECT to automatically close session. > > Problem description: > With the clarification the result of the REDIRECT request without > session header closes the RTSP message connection, does this mean that > the session has automatically been closed? If Yes, should the same > behaviour be used also when session header is present? > > 5. Any other Issues > 6. Next meeting - Proposal: IETF meeting? > 7. End meeting > > > -- > > > 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@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 18 10:33: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 KAA09950 for ; Wed, 18 Jun 2003 10:33:59 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEXWT15159 for mmusic-archive@odin.ietf.org; Wed, 18 Jun 2003 10:33:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdcT-0002xp-Ln for mmusic-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:09:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08423 for ; Wed, 18 Jun 2003 10:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdaC-00052U-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 10:06:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SdaC-00052R-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 10:06:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdBP-0001KB-Gc; Wed, 18 Jun 2003 09:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd5K-0000mv-CG for mmusic@optimus.ietf.org; Wed, 18 Jun 2003 09:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06252; Wed, 18 Jun 2003 09:34:43 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sd33-0004ef-00; Wed, 18 Jun 2003 09:32:25 -0400 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 19Sd32-0004ec-00; Wed, 18 Jun 2003 09:32:24 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 6E3915A6E0; Wed, 18 Jun 2003 15:34:41 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA05299; Wed, 18 Jun 2003 15:34:40 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA27339; Wed, 18 Jun 2003 15:34:39 +0200 (MEST) Subject: Re: [MMUSIC] RTSP: Implicit redirection To: Magnus Westerlund Cc: IETF MMUSIC WG , mmusic-admin@ietf.org, Tom Marshall X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 18 Jun 2003 15:15:49 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/06/2003 15:35:43 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, Tom, [I was trying to write down what I had though was expressed during the RTSP conf call, apparently I got it wrong ... these transatlantic phone lines are really bad must be the echelon probes injecting static ;-] Again I cannot agree more that it is possible to setup 2 different servers so that one serves the SDP and the other one serves the streams ... the thing that remains unclear is the returned status? in case the DESCRIBE response is: * a Location that points to another server => 3xx ? or * a SDP with absoluted URLs pointing to another server => 2yy ? or * both (are we going to permit it ?) => 2zz ? and then what are the value of xx, yy and zz ? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Tom Marshall cc: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 IETF MMUSIC WG Subject: [MMUSIC] RTSP: Implicit redirection Magnus Westerlund Sent by: mmusic-admin@ietf.org 17/06/2003 16:50 Hi Philippe and Tom, I agree with Tom here. It would be much simpler to just specify that any received SDP can point to another host using the a=control URLs. If you do DESCRIBE on the aggregated control URL you should receive the same SDP description. The only implementation simplifying restriction I would like to introduce is that all media streams SHOULD be served by the same server. Any counter reasons? Best Regards Magnus Tom Marshall wrote: > This all seems overly complex and inconsistent to me. Why are people > trying > so hard to insist that the SDP come from the same server as the media? > If > we simply require that the client honor the hostname in the complete > stream > urls (whether from Content-Base or a=control) everything becomes very > simple > and constistent. > > If we require the client to make different assumptions based on whether > the > SDP came from the current RTSP control connection or via another means, > we > require a series of workarounds to make it work properly: > > - An inconsistent message with respect to urls. We are requiring that > clients explicitly ignore the hostname in certain situations. > > - Inconsistent behavior through proxies. A proxy will always honor the > hostname but clients are forbidden from doing so. > > - More complexity: another feature tag and 2xx response code to > support. > > If we simply require the client to honor the hostname in the stream > urls, > all of the above issues go away. The only changes are as follows: > > - The client MUST be prepared to examine the hostname and, if > necessary, > reconnect for the SETUP. This seems a pretty simple thing to > implement. > > - The typical non-redirecting server SHOULD take care to echo the > hostname > exactly as it appears in the client request in order to make the > client's > hostname comparison easy. The server should already be doing this. > > Remember, the notion that a DESCRIBE response not redirect the client > was > only added in an attempt to reduce the complexity of RTSP. If it is not > serving that purpose, it should be removed. > > -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 18 11:24: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 LAA12422 for ; Wed, 18 Jun 2003 11:24:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IFO0N26969 for mmusic-archive@odin.ietf.org; Wed, 18 Jun 2003 11:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Se7r-0004ki-St for mmusic-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:41:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10198 for ; Wed, 18 Jun 2003 10:41:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Se5a-0005G6-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 10:39:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Se5Z-0005Fz-00 for mmusic-web-archive@ietf.org; Wed, 18 Jun 2003 10:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeS-000364-L1; Wed, 18 Jun 2003 10:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdIP-0001Yh-Ee for mmusic@optimus.ietf.org; Wed, 18 Jun 2003 09:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06870; Wed, 18 Jun 2003 09:48:14 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdG8-0004n7-00; Wed, 18 Jun 2003 09:45:56 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19SdG7-0004n4-00; Wed, 18 Jun 2003 09:45:55 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 96B95572EF; Wed, 18 Jun 2003 15:48:11 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA13818; Wed, 18 Jun 2003 15:48:09 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA06076; Wed, 18 Jun 2003 15:48:08 +0200 (MEST) To: tsvwg@ietf.org Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 18 Jun 2003 15:39:18 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/06/2003 15:49:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] stream switching Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hello TSV, I am trying to get feedback about: http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-req-00.txt and http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-00.txt specifically I would like to validate the idea that stream switching "is a good idea" with respect to the idea that it can be used to "extend" RFC3448 to *any type* of streaming media for rate/congestion control. (quote from RFC3448: "TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion.") (Note that stream switching is used today by the 3GPP PSS spec but so far is restricted to server-side rate changes without changing the codec configuration.) In draft-gentric-mmusic-stream-switching-req-00.txt I am trying to extend stream switching to the general case i.e. being able to switch streams that have different encodings. The document explains why there is a need for "additional control" in order to do that. [... and draft-gentric-mmusic-stream-switching-00.txt is an example of how to bring such control capabilities by extending RTSP] regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 19 09:50:32 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 JAA17970 for ; Thu, 19 Jun 2003 09:50:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDo4w05353 for mmusic-archive@odin.ietf.org; Thu, 19 Jun 2003 09:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szng-0001OG-PY for mmusic-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 09:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17937 for ; Thu, 19 Jun 2003 09:50:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SzlM-0004MB-00 for mmusic-web-archive@ietf.org; Thu, 19 Jun 2003 09:47:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SzlM-0004M7-00 for mmusic-web-archive@ietf.org; Thu, 19 Jun 2003 09:47:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sznd-0001Nq-Cv; Thu, 19 Jun 2003 09:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szmo-0001NO-Ko for mmusic@optimus.ietf.org; Thu, 19 Jun 2003 09:49:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17923 for ; Thu, 19 Jun 2003 09:49:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SzkU-0004Ly-00 for mmusic@ietf.org; Thu, 19 Jun 2003 09:46:46 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SzkT-0004Lv-00 for mmusic@ietf.org; Thu, 19 Jun 2003 09:46:45 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JDn5w2011449; Thu, 19 Jun 2003 15:49:05 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQSHH5; Thu, 19 Jun 2003 15:50:38 +0200 Message-ID: <3EF1BE93.8050305@ericsson.com> Date: Thu, 19 Jun 2003 15:45:55 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG , Tom Marshall Subject: Re: [MMUSIC] RTSP: Implicit redirection References: 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 Philippe, philippe.gentric@philips.com wrote: > Magnus, Tom, > > [I was trying to write down what I had though > was expressed during the RTSP conf call, > apparently I got it wrong ... I just think that we misunderstood each others positions. > Again I cannot agree more that it is possible to setup > 2 different servers so that one serves the SDP > and the other one serves the streams ... Yes, you can, however if you would ask the media server for the SDP I think you SHOULD also get the SDP from that one. > > the thing that remains unclear is the returned status? > > in case the DESCRIBE response is: > > * a Location that points to another server => 3xx ? Use the 3rr code that is suitable for the case. I think usage of any of the 301, 302, and 305 can be used. > or > * a SDP with absoluted URLs pointing to another server => 2yy ? I think simply to use 200. The request has been fulfilled. > or > * both (are we going to permit it ?) => 2zz ? > I would recommend against it. You use either of the behaviour, not both simultaneous. That behaviour is definitely not understood by the deployed clients. I welcome more opinions regarding this. 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jun 20 07:35: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 HAA26423 for ; Fri, 20 Jun 2003 07:35:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBZ7q18349 for mmusic-archive@odin.ietf.org; Fri, 20 Jun 2003 07:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAd-0004ls-MD for mmusic-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 07:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26300 for ; Fri, 20 Jun 2003 07:35:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TK8I-0001gZ-00 for mmusic-web-archive@ietf.org; Fri, 20 Jun 2003 07:32:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TK8H-0001gW-00 for mmusic-web-archive@ietf.org; Fri, 20 Jun 2003 07:32:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAY-0004jJ-SC; Fri, 20 Jun 2003 07:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAL-0004iQ-7y for mmusic@optimus.ietf.org; Fri, 20 Jun 2003 07:34:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26234; Fri, 20 Jun 2003 07:34:47 -0400 (EDT) Message-Id: <200306201134.HAA26234@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org, mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 07:34:47 -0400 Subject: [MMUSIC] I-D ACTION:draft-camarillo-mmusic-alt-01.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Alternative Semantics for the Session Description Protocol Grouping Framework Author(s) : G. Camarillo, J. Rosenberg Filename : draft-camarillo-mmusic-alt-01.txt Pages : 10 Date : 2003-6-19 This document defines the alternative (ALT) semantics for the SDP grouping framework. The ALT semantics allow offering alternative transport addresses to establish a particular media stream. This is useful in scenarios that involve IPv4 and IPv6 and/or network address translators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-alt-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-mmusic-alt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-mmusic-alt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-mmusic-alt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-mmusic-alt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154258.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jun 20 23:41:36 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 XAA18462 for ; Fri, 20 Jun 2003 23:41:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5L3f8h04475 for mmusic-archive@odin.ietf.org; Fri, 20 Jun 2003 23:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TZFU-0001A6-4D for mmusic-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 23:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18450 for ; Fri, 20 Jun 2003 23:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TZFR-0005JX-00 for mmusic-web-archive@ietf.org; Fri, 20 Jun 2003 23:41:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TZFR-0005JT-00 for mmusic-web-archive@ietf.org; Fri, 20 Jun 2003 23:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TZFN-00019i-MN; Fri, 20 Jun 2003 23:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TZEP-00019G-Ul for mmusic@optimus.ietf.org; Fri, 20 Jun 2003 23:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18413 for ; Fri, 20 Jun 2003 23:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TZEN-0005J1-00 for mmusic@ietf.org; Fri, 20 Jun 2003 23:39:59 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19TZEM-0005Ix-00 for mmusic@ietf.org; Fri, 20 Jun 2003 23:39:58 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 20 Jun 2003 20:28:16 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Fri, 20 Jun 2003 20:28:16 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Fri, 20 Jun 2003 20:39:11 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19TZE4-0006Tz-00 for ; Fri, 20 Jun 2003 20:39:40 -0700 Date: Fri, 20 Jun 2003 20:38:42 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_20,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #79 - 3 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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-511233 ] Timed PLAY requests has RTP-Info problem (SourceForge.net) 2. [ rtspspec-Bugs-508211 ] Eliminate play queue feature (SourceForge.net) 3. [ rtspspec-Bugs-526545 ] Multiple range specifiers (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 11:59:11 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem Bugs item #511233, was opened at 2002-01-31 16:37 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=23194 Category: None Group: Fix for DS - Need WG Input >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Timed PLAY requests has RTP-Info problem Initial Comment: In a PLAY with a range header, "time=" can be used to give activation time. This request shall be responded immediately to the client. In the response the server should give synchronization data like RTP TS which will be used when the PLAY is activated sometime in the future. It is hard to impossible for the server to produce such data. If no other PLAY request is done between request time and activation it is possible to give an accurate TS and sequnce number. But if another request is activated in the time between, the given RTP TS or sequnce number will not be correct. This problem is the same that queued plays has, see bugreport #477432, but due to different reasons. One possible solution would be to introduce a SYNC method which a server can send at or slightly before activation of a queued or delayed play. This method would carry a RTP-info header and a range header, giving the information; what is playing and the synchronization information. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 20:59 Message: Logged In: YES user_id=302620 It has been decieded at IETF 56 and confirmed at the 16th of April telecon that time playes are removed. Therefore this issue is closed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:59 Message: Logged In: YES user_id=302620 A light solution is proposed in the document. As long as the session is in READY state when issuing the timed request and not issuing any other request the server can produce the correct values directly in the response. A heavier solution would require of something like a INFO method that is sent in the S->C direction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 16 Jun 2003 12:05:47 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-508211 ] Eliminate play queue feature Bugs item #508211, was opened at 2002-01-25 00:48 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=508211&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: Fixed Priority: 9 Submitted By: Rob Lanphier (robla) Assigned to: Magnus Westerlund (magwes) Summary: Eliminate play queue feature Initial Comment: This issue came up in the RTSP teleconference: http://rtsp.org/2002/telecon/minutes23Jan.html Queued playing, as describe in section 10.5, is a feature that has many problems with it (e.g. #477424) The members on the telecon felt that support for this feature is sufficiently weak that rather than fixing this feature, it may be more appropriate to eliminate it, and come up with a simpler play/pause model to replace it. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-16 21:05 Message: Logged In: YES user_id=302620 No comments. closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 17:55 Message: Logged In: YES user_id=302620 The queued play functionality has been eliminated in the version checked in CVS. It can in the future be brought back with extension draft. However for the moment no one is intressted in doing the work necessary to fix it. If no protest has been raised after this next version 02 has been out a while this issue will be closed. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-05-24 20:58 Message: Logged In: YES user_id=3796 From the minutes at IETF 53: http://www.dmn.tzi.org/ietf/mmusic/53/53-mmusic-minutes.txt Queued play (multiple PLAY requests, with the server responsible for serializing them): makes the state machine much more complex. The proposal is to allow multiple ranges in PLAY as a substitute, to be specified as an extension to the core document. Henning Schulzrinne maintained that the Queued play mechanism does not really affect the state machine. Magnus replied that this was technically correct, but it raises other issues. Henning argued that removal from the core specification could remove functionality needed by every server. He was concerned that mapping of multiple ranges (the proposed substitute) might be difficult. This subject will be discussed further as part of Thursday's lunch meeting -- and subsequently on the list. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-05-24 20:42 Message: Logged In: YES user_id=3796 Last email discussion (starting point): http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00105.html ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-05-24 20:36 Message: Logged In: YES user_id=3796 Discussed on April 17 telecon: http://rtsp.org/2002/telecon/minutes17Apr.html#section3.5 * RESOLUTION: take discussion to list: starting proposal: multiple ranges put forward as substitution for queued play * RESOLUTION: group recommends that this is optional, but client needs a way to negotiate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=508211&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 17 Jun 2003 07:18:13 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-526545 ] Multiple range specifiers Bugs item #526545, was opened at 2002-03-06 19:47 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Multiple range specifiers Initial Comment: In the RFC the BNF allows for multiple range specifiers. This was intended to be used to specify diffrent formats of the same range. But the text and BNF does not express this. Therefore it has been interpreted by me (Magnus Westerlund) to be a possibility to specify multiple different ranges. The main question is if this functionallity is useful at all? It is similar to queued plays but have some differencies; 1. Does not allow addition after the first play has been issued; 2. Have fewer issues on how to be handled, like, no RTP-Info, state transitions problems. It seems fairly obvious that it should be an optional behavior but should it be part of the core spec or an extension? What mechanism should be used for discovery of support? If implementing this feature the behavior related to pause need to be resolved. To be able to resume a play request containing multiple ranges the server must singal unambigous in what range and point it actually did pause. A proposal discussed during the telecon 6 march 2002 was to do the following: 1. C->S PLAY range=10-20,30-60,15-45. 2. S->C 200 OK 3. wait approx 11 sec. 4. C->S PAUSE 5. S->C 200 OK, range=31.2-60,15-45 6. User wants to resume. 7. C->S PLAY range=-60,15-45 8. S->C 200 ok By removing the inital range in point 5 the client ensures that the server continues where it halted. And by specifying all the ranges remaining it will play exactly the intended. If point 7 would be done without range the playback would be from 31.2 to end of media. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-17 16:18 Message: Logged In: YES user_id=302620 No comment received on this. closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 18:58 Message: Logged In: YES user_id=302620 This has been written up and included in the CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jun 21 00:41:29 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 AAA19621 for ; Sat, 21 Jun 2003 00:41:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5L4f2T12791 for mmusic-archive@odin.ietf.org; Sat, 21 Jun 2003 00:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TaBS-0003KE-GI for mmusic-web-archive@optimus.ietf.org; Sat, 21 Jun 2003 00:41:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19611 for ; Sat, 21 Jun 2003 00:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TaBQ-0005e0-00 for mmusic-web-archive@ietf.org; Sat, 21 Jun 2003 00:41:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TaBP-0005dx-00 for mmusic-web-archive@ietf.org; Sat, 21 Jun 2003 00:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TaBR-0003Jp-3d; Sat, 21 Jun 2003 00:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TaB5-0003Jb-Cg for mmusic@optimus.ietf.org; Sat, 21 Jun 2003 00:40:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19608 for ; Sat, 21 Jun 2003 00:40:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TaB2-0005du-00 for mmusic@ietf.org; Sat, 21 Jun 2003 00:40:36 -0400 Received: from [210.32.0.6] (helo=zju.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19TaB1-0005dr-00 for mmusic@ietf.org; Sat, 21 Jun 2003 00:40:35 -0400 Received: (eyou send program); Sat, 21 Jun 2003 12:39:48 +0800 Received: from 10.10.2.41 by sun.zju.edu.cn with HTTP; Sat, 21 Jun 2003 12:39:48 +0800 X-WebMAIL-MUA: [10.10.2.41] From: "" To: mmusic@ietf.org Date: Sat, 21 Jun 2003 12:39:48 +0800 Reply-To: "" Content-Type: text/plain Message-Id: Subject: [MMUSIC] quit the mail list! Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½: >From:rtspspec-bugs-request@lists.sourceforge.net >Reply-To: mmusic@ietf.org >To: mmusic@ietf.org >Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #79 - 3 msgs > > > > >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-511233 ] Timed PLAY requests has RTP-Info problem (SourceForge.net) > 2. [ rtspspec-Bugs-508211 ] Eliminate play queue feature (SourceForge.net) > 3. [ rtspspec-Bugs-526545 ] Multiple range specifiers (SourceForge.net) > >--__--__-- > >Message: 1 >To: noreply@sourceforge.net >From: "SourceForge.net" >Date: Mon, 16 Jun 2003 11:59:11 -0700 >Subject: [rtspspec-bugs] [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem > >Bugs item #511233, was opened at 2002-01-31 16:37 >Message generated for change (Comment added) made by magwes >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=2319 4 > >Category: None >Group: Fix for DS - Need WG Input >>Status: Closed >>Resolution: Wont Fix >Priority: 5 >Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) >Summary: Timed PLAY requests has RTP-Info problem > >Initial Comment: >In a PLAY with a range header, "time=" can be used to give activation time. This request shall be >responded immediately to the client. In the response the server should give synchronization data >like RTP TS which will be used when the PLAY is activated sometime in the future. It is hard to >impossible for the server to produce such data. If no other PLAY request is done between request >time and activation it is possible to give an accurate TS and sequnce number. But if another >request is activated in the time between, the given RTP TS or sequnce number will not be correct. > >This problem is the same that queued plays has, see bugreport #477432, but due to different >reasons. > >One possible solution would be to introduce a SYNC method which a server can send at or slightly >before activation of a queued or delayed play. This method would carry a RTP-info header and a >range header, giving the information; what is playing and the synchronization information. > >---------------------------------------------------------------------- > >>Comment By: Magnus Westerlund (magwes) >Date: 2003-06-16 20:59 > >Message: >Logged In: YES >user_id=302620 > >It has been decieded at IETF 56 and confirmed at the 16th of >April telecon that time playes are removed. Therefore this >issue is closed. > > > >---------------------------------------------------------------------- > >Comment By: Magnus Westerlund (magwes) >Date: 2002-10-30 17:59 > >Message: >Logged In: YES >user_id=302620 > >A light solution is proposed in the document. As long as the >session is in READY state when issuing the timed request and >not issuing any other request the server can produce the >correct values directly in the response. > >A heavier solution would require of something like a INFO >method that is sent in the S->C direction. > >---------------------------------------------------------------------- > >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=2319 4 > > >--__--__-- > >Message: 2 >To: noreply@sourceforge.net >From: "SourceForge.net" >Date: Mon, 16 Jun 2003 12:05:47 -0700 >Subject: [rtspspec-bugs] [ rtspspec-Bugs-508211 ] Eliminate play queue feature > >Bugs item #508211, was opened at 2002-01-25 00:48 >Message generated for change (Comment added) made by magwes >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=377744&aid=508211&group_id=2319 4 > >Category: General >Group: Fixed in CVS/Need WG Approval >>Status: Closed >Resolution: Fixed >Priority: 9 >Submitted By: Rob Lanphier (robla) >Assigned to: Magnus Westerlund (magwes) >Summary: Eliminate play queue feature > >Initial Comment: >This issue came up in the RTSP teleconference: >http://rtsp.org/2002/telecon/minutes23Jan.html > >Queued playing, as describe in section 10.5, is a feature that has many problems with it (e.g. >#477424) The members on the telecon felt that support for this feature is sufficiently weak that >rather than fixing this feature, it may be more appropriate to eliminate it, and come up with a >simpler play/pause model to replace it. > >---------------------------------------------------------------------- > >>Comment By: Magnus Westerlund (magwes) >Date: 2003-06-16 21:05 > >Message: >Logged In: YES >user_id=302620 > >No comments. closing bug. > >---------------------------------------------------------------------- > >Comment By: Magnus Westerlund (magwes) >Date: 2002-10-30 17:55 > >Message: >Logged In: YES >user_id=302620 > >The queued play functionality has been eliminated in the >version checked in CVS. It can in the future be brought back >with extension draft. However for the moment no one is >intressted in doing the work necessary to fix it. > >If no protest has been raised after this next version 02 has >been out a while this issue will be closed. > >---------------------------------------------------------------------- > >Comment By: Rob Lanphier (robla) >Date: 2002-05-24 20:58 > >Message: >Logged In: YES >user_id=3796 > >From the minutes at IETF 53: >http://www.dmn.tzi.org/ietf/mmusic/53/53-mmusic-minutes.txt > >Queued play (multiple PLAY requests, with the server >responsible for serializing them): makes the state machine >much more complex. The proposal is to allow multiple ranges >in PLAY as a substitute, to be specified as an extension to >the core document. Henning Schulzrinne > maintained that the Queued play >mechanism does not really affect the state machine. Magnus >replied that this was technically correct, but it raises >other issues. Henning argued that removal from the core >specification could remove functionality needed by every >server. He was concerned that mapping of multiple ranges >(the proposed substitute) might be difficult. This subject >will be discussed further as part of Thursday's lunch >meeting -- and subsequently on the list. > > > >---------------------------------------------------------------------- > >Comment By: Rob Lanphier (robla) >Date: 2002-05-24 20:42 > >Message: >Logged In: YES >user_id=3796 > >Last email discussion (starting point): >http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00105.html > >---------------------------------------------------------------------- > >Comment By: Rob Lanphier (robla) >Date: 2002-05-24 20:36 > >Message: >Logged In: YES >user_id=3796 > >Discussed on April 17 telecon: >http://rtsp.org/2002/telecon/minutes17Apr.html#section3.5 > >* RESOLUTION: take discussion to list: starting proposal: >multiple ranges put forward as substitution for queued play >* RESOLUTION: group recommends that this is optional, but >client needs a way to negotiate > > > >---------------------------------------------------------------------- > >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=377744&aid=508211&group_id=2319 4 > > >--__--__-- > >Message: 3 >To: noreply@sourceforge.net >From: "SourceForge.net" >Date: Tue, 17 Jun 2003 07:18:13 -0700 >Subject: [rtspspec-bugs] [ rtspspec-Bugs-526545 ] Multiple range specifiers > >Bugs item #526545, was opened at 2002-03-06 19:47 >Message generated for change (Comment added) made by magwes >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&group_id=2319 4 > >Category: General >Group: Fixed in CVS/Need WG Approval >>Status: Closed >>Resolution: Fixed >Priority: 5 >Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) >Summary: Multiple range specifiers > >Initial Comment: >In the RFC the BNF allows for multiple range >specifiers. This was intended to be used to specify >diffrent formats of the same range. But the text and >BNF does not express this. Therefore it has been >interpreted by me (Magnus Westerlund) to be a >possibility to specify multiple different ranges. > >The main question is if this functionallity is useful >at all? It is similar to queued plays but have some >differencies; 1. Does not allow addition after the >first play has been issued; 2. Have fewer issues on how >to be handled, like, no RTP-Info, state transitions >problems. > >It seems fairly obvious that it should be an optional >behavior but should it be part of the core spec or an >extension? What mechanism should be used for discovery >of support? > >If implementing this feature the behavior related to >pause need to be resolved. To be able to resume a play >request containing multiple ranges the server must >singal unambigous in what range and point it actually >did pause. A proposal discussed during the telecon 6 >march 2002 was to do the following: > >1. C->S PLAY range=10-20,30-60,15-45. >2. S->C 200 OK >3. wait approx 11 sec. >4. C->S PAUSE >5. S->C 200 OK, range=31.2-60,15-45 >6. User wants to resume. >7. C->S PLAY range=-60,15-45 >8. S->C 200 ok > >By removing the inital range in point 5 the client >ensures that the server continues where it halted. And >by specifying all the ranges remaining it will play >exactly the intended. > >If point 7 would be done without range the playback >would be from 31.2 to end of media. > > > > >---------------------------------------------------------------------- > >>Comment By: Magnus Westerlund (magwes) >Date: 2003-06-17 16:18 > >Message: >Logged In: YES >user_id=302620 > >No comment received on this. closing bug. > >---------------------------------------------------------------------- > >Comment By: Magnus Westerlund (magwes) >Date: 2002-10-30 18:58 > >Message: >Logged In: YES >user_id=302620 > >This has been written up and included in the CVS. > >---------------------------------------------------------------------- > >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&group_id=2319 4 > > > > >End of Rtspspec-bugs Digest > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jun 21 10:21:32 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 KAA09237 for ; Sat, 21 Jun 2003 10:21:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5LEL5D01157 for mmusic-archive@odin.ietf.org; Sat, 21 Jun 2003 10:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TjEn-0000Ia-Na for mmusic-web-archive@optimus.ietf.org; Sat, 21 Jun 2003 10:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09221 for ; Sat, 21 Jun 2003 10:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TjEl-0007Yo-00 for mmusic-web-archive@ietf.org; Sat, 21 Jun 2003 10:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TjEk-0007Yl-00 for mmusic-web-archive@ietf.org; Sat, 21 Jun 2003 10:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TjEj-0000I8-Nd; Sat, 21 Jun 2003 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TjEL-0000Gl-Fb for mmusic@optimus.ietf.org; Sat, 21 Jun 2003 10:20:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09218 for ; Sat, 21 Jun 2003 10:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TjEJ-0007Yd-00 for mmusic@ietf.org; Sat, 21 Jun 2003 10:20:35 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19TjEI-0007Ya-00 for mmusic@ietf.org; Sat, 21 Jun 2003 10:20:34 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 4847E684; Sat, 21 Jun 2003 16:20:08 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-40-87.reverse.qsc.de [212.202.40.87]) by fox.iptel.org (Postfix) with ESMTP id 708B2683; Sat, 21 Jun 2003 16:20:07 +0200 (CEST) Message-Id: <5.2.0.9.0.20030621151348.033aa858@fox.iptel.org> X-Sender: jiri@fox.iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 21 Jun 2003 16:18:03 +0200 To: Jonathan Rosenberg , David Yon From: Jiri Kuthan Subject: Re: [MMUSIC] re: what happens if both SIP UAs want to be active Cc: mmusic@ietf.org In-Reply-To: <3EEECD7C.8020101@dynamicsoft.com> References: <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Jonathan, is there any border line between what deserves to be a response code and warning code? Do you think it make sense to write a tiny I-D for this code or is it better specified in the comedia draft? thanks, -jiri At 10:12 AM 6/17/2003, Jonathan Rosenberg wrote: >Right. That would be a 488 or 606 response code. We also use the Warning header to convey more detailed information on exactly what happened. It might be useful to register, through IANA, a new warn-code for this particular case. > >-Jonathan R. > >David Yon wrote: >>The SIP gurus can chime in, but seems to me it would be in the same category as not being able to come to an agreement vis-a-vis which codec to use. >>At 12:25 PM 6/16/2003, Jiri Kuthan wrote: >> >>>[sorry, misthreaded -- I copy'n'pasted from archive since I was stripped >>> off the recepient list] >>> >>>What does it mean SIP-wise that negotiation fails? >>> >>>I mean it would be great to have a special code for this error which >>>allows SIP entities to recognized these conditions and act approprietly. >>> >>>-Jiri >>> >>>on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: >>>> If they both want to be active, the negotiation fails. >>> >>>>> At 12:47 PM 6/7/2003, Jiri Kuthan wrote: >>>>> David, >>>>> >>>>> can you please explain me how SIP signaling proceeds if two UAs both >>>>> with to have direction=active, since they are behind symmetric NATs? >>>>> >>>>> Thanks, >>>>> >>>>> -jiri >>> >>>-- >>>Jiri Kuthan http://iptel.org/~jiri/ >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Scientist Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jun 22 00:07: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 AAA22482 for ; Sun, 22 Jun 2003 00:07:17 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5M46E903832 for mmusic-archive@odin.ietf.org; Sun, 22 Jun 2003 00:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw7K-0000zj-Rp for mmusic-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 00:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22462 for ; Sun, 22 Jun 2003 00:06:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tw7I-0002TD-00 for mmusic-web-archive@ietf.org; Sun, 22 Jun 2003 00:06:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Tw7C-0002T9-00 for mmusic-web-archive@ietf.org; Sun, 22 Jun 2003 00:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw77-0000zE-Mt; Sun, 22 Jun 2003 00:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw62-0000yo-Eq for mmusic@optimus.ietf.org; Sun, 22 Jun 2003 00:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22445 for ; Sun, 22 Jun 2003 00:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tw5l-0002T1-00 for mmusic@ietf.org; Sun, 22 Jun 2003 00:04:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Tw5k-0002So-00 for mmusic@ietf.org; Sun, 22 Jun 2003 00:04:36 -0400 Received: from dynamicsoft.com ([63.113.46.135]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5M443sm007093; Sun, 22 Jun 2003 00:04:05 -0400 (EDT) Message-ID: <3EF52AB3.4090104@dynamicsoft.com> Date: Sun, 22 Jun 2003 00:04:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: David Yon , mmusic@ietf.org Subject: Re: [MMUSIC] re: what happens if both SIP UAs want to be active References: <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> <5.2.0.9.0.20030621151348.033aa858@fox.iptel.org> In-Reply-To: <5.2.0.9.0.20030621151348.033aa858@fox.iptel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Its easy. 488 indicates a problem with the session description, and Warning carries additional information on what happened. Warnings arent used for anything else but that. -Jonathan R. Jiri Kuthan wrote: > Jonathan, > > is there any border line between what deserves to be a response code > and warning code? > > Do you think it make sense to write a tiny I-D for this > code or is it better specified in the comedia draft? > > thanks, > > -jiri > > At 10:12 AM 6/17/2003, Jonathan Rosenberg wrote: > >>Right. That would be a 488 or 606 response code. We also use the Warning header to convey more detailed information on exactly what happened. It might be useful to register, through IANA, a new warn-code for this particular case. >> >>-Jonathan R. >> >>David Yon wrote: >> >>>The SIP gurus can chime in, but seems to me it would be in the same category as not being able to come to an agreement vis-a-vis which codec to use. >>>At 12:25 PM 6/16/2003, Jiri Kuthan wrote: >>> >>> >>>>[sorry, misthreaded -- I copy'n'pasted from archive since I was stripped >>>>off the recepient list] >>>> >>>>What does it mean SIP-wise that negotiation fails? >>>> >>>>I mean it would be great to have a special code for this error which >>>>allows SIP entities to recognized these conditions and act approprietly. >>>> >>>>-Jiri >>>> >>>>on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: >>>> >>>>>If they both want to be active, the negotiation fails. >>>> >>>>>>At 12:47 PM 6/7/2003, Jiri Kuthan wrote: >>>>>>David, >>>>>> >>>>>>can you please explain me how SIP signaling proceeds if two UAs both >>>>>>with to have direction=active, since they are behind symmetric NATs? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>-jiri >>>> >>>>-- >>>>Jiri Kuthan http://iptel.org/~jiri/ >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Scientist Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com > > > -- > Jiri Kuthan http://iptel.org/~jiri/ > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jun 23 03:32: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 DAA11551 for ; Mon, 23 Jun 2003 03:32:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N7WDd21640 for mmusic-archive@odin.ietf.org; Mon, 23 Jun 2003 03:32:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ULoD-0005cx-41 for mmusic-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 03:32:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11540 for ; Mon, 23 Jun 2003 03:32:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ULoA-0000Gt-00 for mmusic-web-archive@ietf.org; Mon, 23 Jun 2003 03:32:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ULo5-0000Gm-00 for mmusic-web-archive@ietf.org; Mon, 23 Jun 2003 03:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ULo1-0005cH-Cw; Mon, 23 Jun 2003 03:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ULn8-0005aq-6Y for mmusic@optimus.ietf.org; Mon, 23 Jun 2003 03:31:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11526 for ; Mon, 23 Jun 2003 03:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ULn5-0000GV-00 for mmusic@ietf.org; Mon, 23 Jun 2003 03:31:04 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ULmv-0000GS-00 for mmusic@ietf.org; Mon, 23 Jun 2003 03:30:53 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5N7UWG5004564; Mon, 23 Jun 2003 09:30:32 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ8VY0; Mon, 23 Jun 2003 09:32:16 +0200 Message-ID: <3EF6ABD1.9000500@ericsson.com> Date: Mon, 23 Jun 2003 09:27:13 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Belling Thomas CC: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] RTP bandwidth for multiple media streams References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I would agree with the interpretation, at least when it comes to b=AS as it clearly specifies that this is the RTP session bandwidth. When one uses a m= line with port/2 it becomes two RTP sessions. However I am not certain over how one should in this case interpret any of the other bandwidth attributes. The available bandwidth modifiers are: CT RR RS Lets look at them: CT is defined in draft-ietf-mmusic-sdp-new-12 as: CT Conference Total If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=CT:..." line should be supplied for the session giving the proposed upper limit to the bandwidth used. The primary purpose of this is to give an approximate idea as to whether two or more sessions can co-exist simultaneously. Based on this I would interpret that a given CT value should be for the complete media, i.e. counting the total of both RTP sessions. When it comes to RR and RS I think they can also be interpreted on a per RTP session level. I base this on the fundamental definition of these attributes. From draft-ietf-avt-rtcp-bw-05: This memo defines two additional bandwidth modifiers: b=RS: b=RR: where "RS" indicates the RTCP bandwidth allocated to active data senders (as defined by the RTP spec) and "RR" indicates the RTCP bandwidth allocated to other participants in the RTP session (i.e., receivers). When it concerns TIAS I will do the same interpretation that the bandwidth value apply per RTP session. My concern is that this simplistic model is probably not what you would like if you would actually use this functionality. If one uses multiple RTP sessions for a single media you are probably doing some form of scalability, etc., and would like to specify the values independently per RTP session. Fortunately there exist today alternatives to achieve this behaviour today. With the help of grouping of media lines it is possible to specify that several m= lines are part of the same media. Using FID there is only a pitfall with the following sentence: "A media agent handling a media flow that comprises several "m" lines MUST send a copy of the media to every "m" line part of the flow as long as the codecs and the direction attribute present in a particular "m" line allow it." If that is a problem it might be easier to define a new grouping attribute for that situation. Finally I have a question to the group, has anyone seen that "m= port/2 ..." ever been used. And in that case how. Best Regards Magnus Belling Thomas wrote: >>c=IN IP4 224.2.1.1/127/2 >>m=video 49170/2 RTP/AVP 31 >>b=AS:64 >> >>My problem: How much bandwidth is associated with this "m=" line - >>64kbits or 128kbits? >> -- 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jun 23 07:41: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 HAA16904 for ; Mon, 23 Jun 2003 07:41:16 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NBelS20113 for mmusic-archive@odin.ietf.org; Mon, 23 Jun 2003 07:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPgl-0005EK-Rn for mmusic-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 07:40:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16881 for ; Mon, 23 Jun 2003 07:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UPgl-0001ZJ-00 for mmusic-web-archive@ietf.org; Mon, 23 Jun 2003 07:40:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UPgf-0001ZG-00 for mmusic-web-archive@ietf.org; Mon, 23 Jun 2003 07:40:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPg1-0005Ag-19; Mon, 23 Jun 2003 07:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPfu-0005A6-Tn for mmusic@optimus.ietf.org; Mon, 23 Jun 2003 07:39:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16845 for ; Mon, 23 Jun 2003 07:39:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UPfu-0001Yf-00 for mmusic@ietf.org; Mon, 23 Jun 2003 07:39:54 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19UPfj-0001Yc-00 for mmusic@ietf.org; Mon, 23 Jun 2003 07:39:43 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5NBdbw2022323 for ; Mon, 23 Jun 2003 13:39:37 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9T42F; Mon, 23 Jun 2003 13:40:21 +0200 Message-ID: <3EF6E631.9000207@ericsson.com> Date: Mon, 23 Jun 2003 13:36:17 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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] [Fwd: Re: Last Call: SDP attribute for qualifying Media Formats with Generic Parameters to a Proposed Standard] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI /Magnus -------- Original Message -------- Subject: Re: Last Call: SDP attribute for qualifying Media Formats with Generic Parameters to a Proposed Standard Date: Fri, 20 Jun 2003 07:44:09 -0700 (PDT) From: ned.freed@mrochek.com To: iesg@ietf.org CC: ietf@ietf.org References: > The IESG has received a request from Individual Submissions WG to consider > the following Internet-Draft(s) as a Proposed Standard. This has been > reviewed in the IETF but is not the product of an IETF Working Group. > o Individual Submissions (NONE): SDP attribute for qualifying Media > Formats with Generic Parameters > > Proposed Standard This looks to me like a substantive duplication of the media features facility defined in RFC 2533 and elaborated on in RFCs 2506, 2530, 2534, 2738, 2912, 2913, 2938, and 2987. Not only does this set of documents provide a full-featured media feature tagging and content negotiation facility, the relationship to MIME media types and parameters has also been worked out. Although the media features facility defined in these various RFCs is perhaps too elaborate for SDP's needs, it should at least be possible to reuse the basic descriptive elements of media features and the corresponding media features registry. At a minimum this draft needs to explain why the existing media features facility is unsuitable for SDP's use and another, similar facility needs to be defined. Ned -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 24 15:20: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 PAA05626 for ; Tue, 24 Jun 2003 15:20:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJKD908647 for mmusic-archive@odin.ietf.org; Tue, 24 Jun 2003 15:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtKv-0002FO-JZ for mmusic-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 15:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05599 for ; Tue, 24 Jun 2003 15:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtKu-0006G7-00 for mmusic-web-archive@ietf.org; Tue, 24 Jun 2003 15:20:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UtKo-0006Fz-00 for mmusic-web-archive@ietf.org; Tue, 24 Jun 2003 15:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtKj-0002DN-SM; Tue, 24 Jun 2003 15:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtKO-0002CD-8R for mmusic@optimus.ietf.org; Tue, 24 Jun 2003 15:19:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05553 for ; Tue, 24 Jun 2003 15:19:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtKN-0006Ez-00 for mmusic@ietf.org; Tue, 24 Jun 2003 15:19:39 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtKC-0006Dw-00 for mmusic@ietf.org; Tue, 24 Jun 2003 15:19:28 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH000DDQ2V6W3@firewall.wcom.com> for mmusic@ietf.org; Tue, 24 Jun 2003 19:16:20 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HH000B012V2A0@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:18 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.122.248]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH0009472V1NX@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:15 +0000 (GMT) Date: Tue, 24 Jun 2003 14:16:13 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: mmusic@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20030624141303.023a43d8@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [MMUSIC] Centralized Conferencing (xcon) BOF Announcement Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , FYI. Centralized Conferencing BOF (xcon) Tuesday, July 15 at 1700-1800 ============================== CHAIRS: Alan Johnston (alan.johnston@mci.com) Adam Roach (adam@dynamicsoft.com) AGENDA: - Intro and Agenda Bashing (5 min) - Problem Statement and Overview of Scope (10 min) - Charter Discussion (15 min) - Open Discussion (30 min) Description of Proposed Working Group The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly-coupled conference need not be performed centrally, however. Unlike previous attempts at standardizing conferencing-related activities, the scope of this effort is intentionally very narrow, and is intended to enable interoperability in a commercial environment which already has a number of implementations. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be completely invisible or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Initially this combination of protocols will be specified with respect to session setup with SIP, but most of the specific components would be applicable to conferences setup using other protocols. [None of the protocols defined by this group will be SIP or require SIP extensions.] The group will use the high-level requirements and framework already described by documents published by the SIPPING WG. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "layout" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a roster) - A basic floor control protocol - Peer-to-peer cascading of conferences (one conference is a participant in another and vice versa) The following items are specifically out-of-scope: - Voting - Multicast media (due to security concerns) - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts (a non-exhaustive list is included below) as input to the working group. Related documents in other working groups: - draft-ietf-sipping-conferencing-requirements-00.txt - draft-ietf-sipping-conferencing-framework-00.txt - draft-ietf-sipping-cc-conferencing-00.txt - draft-ietf-sipping-cc-framework-02.txt - draft-ietf-sipping-conference-package-00.txt Partial list of input documents: (All documents available at http://ee.wustl.edu/~alan/xcon/ until they appear in the IETF archives.) - draft-even-xcon-conference-scenarios-00.txt - draft-koskelainen-xcon-cpcp-reqs-00.txt - draft-even-xcon-media-policy-requirements-00.txt - draft-koskelainen-xcon-floor-control-req-00.txt - draft-koskelainen-xcon-xcap-cpcp-usage-00.txt - draft-levin-xcon-cpcp-00.txt - draft-mahy-xcon-media-policy-control-00.txt Comments on the above drafts are welcome on the xcon mailing list: Mailing-List: xcon@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jun 24 15:42:39 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 PAA06932 for ; Tue, 24 Jun 2003 15:42:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJgAJ12502 for mmusic-archive@odin.ietf.org; Tue, 24 Jun 2003 15:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtgA-0003FZ-Ht for mmusic-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 15:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06883 for ; Tue, 24 Jun 2003 15:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Utg9-0006Vx-00 for mmusic-web-archive@ietf.org; Tue, 24 Jun 2003 15:42:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Utg3-0006Vu-00 for mmusic-web-archive@ietf.org; Tue, 24 Jun 2003 15:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Utg1-0003Bu-Nr; Tue, 24 Jun 2003 15:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Utfe-0003BF-66 for mmusic@optimus.ietf.org; Tue, 24 Jun 2003 15:41:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06875 for ; Tue, 24 Jun 2003 15:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Utfc-0006Vf-00 for mmusic@ietf.org; Tue, 24 Jun 2003 15:41:36 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19UtfM-0006Vb-00 for mmusic@ietf.org; Tue, 24 Jun 2003 15:41:20 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h5OJfAas037643 for ; Tue, 24 Jun 2003 12:41:10 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h5OJfAA5037641; Tue, 24 Jun 2003 12:41:10 -0700 (PDT) Message-Id: <4.3.1.1.20030624123845.00c31a00@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 24 Jun 2003 12:40:06 -0700 To: mmusic@ietf.org From: Ross Finlayson Subject: Re: [MMUSIC] Centralized Conferencing (xcon) BOF Announcement In-Reply-To: <5.2.1.1.0.20030624141303.023a43d8@pop.mcit.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: , >Description of Proposed Working Group Why a new working group? MMUSIC would seem to be the logical place for this. >The following items are specifically out-of-scope: [...] >- Multicast media (due to security concerns) This sounds a bit bogus to me... Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 11:56: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 LAA18456 for ; Wed, 25 Jun 2003 11:56:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFuFK00419 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 11:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCd5-00006g-Eu for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:56:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18440 for ; Wed, 25 Jun 2003 11:56:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCd3-0004t9-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 11:56:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCct-0004t4-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 11:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCcr-0008T8-P1; Wed, 25 Jun 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCcm-0008Sd-LS for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 11:55:56 -0400 Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18415 for ; Wed, 25 Jun 2003 11:55:54 -0400 (EDT) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PFsoh20903; Wed, 25 Jun 2003 11:54:50 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV6AJH2; Wed, 25 Jun 2003 11:54:51 -0400 Received: from nortelnetworks.com (acart1en.ca.nortel.com [47.129.129.130]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLV9J6C8; Wed, 25 Jun 2003 11:54:50 -0400 Message-ID: <3EF9C5C5.2050108@nortelnetworks.com> Date: Wed, 25 Jun 2003 11:54:45 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Magnus Westerlund CC: Belling Thomas , "'mmusic@ietf.org'" Subject: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams References: <3EF95489.6050406@ericsson.com> In-Reply-To: <3EF95489.6050406@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Speaking of implementations and moving to draft standard: I have had absolutely no reports and no substantive comments on my interoperability report draft. Magnus Westerlund wrote: [snip] > > My thinking is actually along the lines, if no one uses it, why not > remove it, we will still have to if no implementations are identified > when going to draft standard. > > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 12:18: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 MAA19683 for ; Wed, 25 Jun 2003 12:18:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGILk08262 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 12:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJz-0002Ia-TK for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:36:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16253 for ; Wed, 25 Jun 2003 11:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJU-00020j-Io; Wed, 25 Jun 2003 11:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxR-0008Cz-8d for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 11:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05477 for ; Wed, 25 Jun 2003 05:24:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V6W8-0002yz-00 for mmusic@ietf.org; Wed, 25 Jun 2003 05:24:40 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19V6Vx-0002yt-00 for mmusic@ietf.org; Wed, 25 Jun 2003 05:24:29 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA13150; Wed, 25 Jun 2003 11:24:10 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA05120; Wed, 25 Jun 2003 11:24:10 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 25 Jun 2003 11:23:39 +0200 Message-ID: From: Belling Thomas To: "'Magnus Westerlund'" Cc: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] RTP bandwidth for multiple media streams Date: Wed, 25 Jun 2003 11:23:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus, I could also agree with removing "m=3D port/2 ", if nobody uses it. Obviously, that would also remove the ambiguities with the bandwidth = modifiers that are the cause of my concerns. Thomas -----Urspr=FCngliche Nachricht----- Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Gesendet: Mittwoch, 25. Juni 2003 09:52 An: Belling Thomas Cc: 'mmusic@ietf.org' Betreff: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams Hi Thomas, Even more inline: Belling Thomas wrote: > Hi Magnus, >=20 > My answers are inline >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Gesendet: Montag, 23. Juni 2003 09:27 > An: Belling Thomas > Cc: 'mmusic@ietf.org' > Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams >=20 >=20 > Hi, >=20 > I would agree with the interpretation, at least when it comes to = b=3DAS as=20 > it clearly specifies that this is the RTP session bandwidth. When one = > uses a m=3D line with port/2 it becomes two RTP sessions. However I = am not=20 > certain over how one should in this case interpret any of the other=20 > bandwidth attributes. >=20 > [Thomas] Fine, but is that 100 Percent clear from the wording of the = RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a clarification = there Yes, this should probably be clarified. I don't think it is obvious. >=20 > The available bandwidth modifiers are: > CT > RR > RS >=20 > Lets look at them: >=20 > CT is defined in draft-ietf-mmusic-sdp-new-12 as: > CT Conference Total > If the bandwidth of a session or media in a session is > different from the bandwidth implicit from the scope, a > "b=3DCT:..." line should be supplied for the session = giving > the proposed upper limit to the bandwidth used. The = primary > purpose of this is to give an approximate idea as to = whether > two or more sessions can co-exist simultaneously. >=20 > Based on this I would interpret that a given CT value should be for = the=20 > complete media, i.e. counting the total of both RTP sessions. >=20 > [Thomas] I agree that this is an interpretation in line with my = understanding of the intentions of the CT bandwidth modifier. However, = the wording is not so clear. What is a "session"? If you understand = "RTP session", this would contradict your interpretation. As an aside: = 3GPP ignores this parameter, so from that perspective a clarification = is less urgent than for the AS modifier. Yes, the session in the quote is a bit unclear. I think it is a larger=20 session concept, like the complete streaming session, or probably when=20 it was written the conferencing session with all the media included. On = media level the text indicates the complete media, which in this case = is=20 transported over several RTP sessions. So based on these two=20 interpretations I arrive at my conclusion. > When it concerns TIAS I will do the same interpretation that the=20 > bandwidth value apply per RTP session. >=20 > [Thomas] Makes sense if you take TIAS as a kind of refinement of the = AS modifier. I did not yet read the draft with that question in mind, = and the draft is still in a stage where this can be clarified. Yes, it can still be modified. I have made an update and I did not=20 address the issue. The reason being is that I think the SDP draft = should=20 first address this. Based on this clarification I would add to the=20 TIAS draft if necessary. >=20 > My concern is that this simplistic model is probably not what you = would=20 > like if you would actually use this functionality. If one uses = multiple=20 > RTP sessions for a single media you are probably doing some form of=20 > scalability, etc., and would like to specify the values independently = > per RTP session. Fortunately there exist today alternatives to = achieve > this behaviour today. With the help of grouping of media lines it is=20 > possible to specify that several m=3D lines are part of the same = media.=20 > Using FID there is only a pitfall with the following sentence: > "A media agent handling a media flow that comprises several "m" > lines MUST send a copy of the media to every "m" line part of the > flow as long as the codecs and the direction attribute present in = a > particular "m" line allow it." >=20 > If that is a problem it might be easier to define a new grouping=20 > attribute for that situation. > Finally I have a question to the group, has anyone seen that "m=3D = port/2=20 > ..." ever been used. And in that case how. >=20 > [Thomas] Take the simple example of stereo sound. Why not use the = "m=3D port/2 " notification for that? Something in that direction might = have been the original motification. From a 3GPP perspective, where = this relates to thev bandwidth on the air and possibly the rate charged = for a service, we should have a clear understanding as this possibility = exists and might also be misused otherwise. I don't think stereo is a good example. First reason is that you=20 normally don't split left and right channel into different packets,=20 unless they are really big, reasons are like synchronization. Therefore = most audio codecs are possible to transport over RTP using a single=20 source. The sample based codec normally only specify that every other=20 sample is left and the other are right. Frame based codec normally = have=20 more advanced schemes where they encode left and right together to take = advantage of the similarities between channels. My thinking is actually along the lines, if no one uses it, why not=20 remove it, we will still have to if no implementations are identified=20 when going to draft standard. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 12:50: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 MAA20980 for ; Wed, 25 Jun 2003 12:50:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGoCE14204 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 12:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDTI-0003h1-TN for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:50:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20966 for ; Wed, 25 Jun 2003 12:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDTI-0005Li-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 12:50:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VDTC-0005Lc-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 12:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDT7-0003cD-LG; Wed, 25 Jun 2003 12:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDST-0003bh-7t for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 12:49:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20948 for ; Wed, 25 Jun 2003 12:49:18 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDSS-0005LE-00 for mmusic@ietf.org; Wed, 25 Jun 2003 12:49:20 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19VDSH-0005Kq-00 for mmusic@ietf.org; Wed, 25 Jun 2003 12:49:09 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 48BD355D32 for ; Wed, 25 Jun 2003 18:47:01 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA08034 for ; Wed, 25 Jun 2003 18:47:00 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA13746 for ; Wed, 25 Jun 2003 18:47:00 +0200 (MEST) To: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 25 Jun 2003 18:38:04 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/06/2003 18:48:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] material for RTSP spec clarification Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 RTSP server MAY redirect a client in reply to DESCRIBE... sure, but there are several ways to do that ... after the last discussions on the reflector and during the conference call, I would like to try to re-sumarize what I hope is a correct understanding of the consensus ;-) NB: this is intended as possible material for a clarification in the next release of the RTSP specification 1) SDP redirection The server MAY reply 200 with absolute URLs in the SDP response where another server is indicated by these absolute URLs. A client MUST be ready to examine the SDP for absolute URLs. The client (if it wants to...) SHOULD connect to the other server and MAY start the session with SETUP since the information in the SDP is deemed valid. The absolute URLs -in case there are several of them e.g. audio and video- MUST point to the same streaming server. Example: C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 M->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 164 v=0 o=- 2890844256 2890842807 IN IP4 172.16.2.93 s=RTSP Session i=An Example of RTSP Session Usage a=control:rtsp://123.34.322.67:554/foo/twister t=0 0 m=audio 0 RTP/AVP 0 a=control:rtsp://123.34.322.67:554/foo/twister/audio m=video 0 RTP/AVP 26 a=control:rtsp://123.34.322.67:554/foo/twister/video 2) Explicit RTSP redirection The server MAY reply 3xx (possible status values are described in RFC2616 section 10.3). This response MUST NOT contain any SDP. The alternate server MUST be indicated in the Location header. The client (if it wants to...) SHOULD connect to the other server and restart the session with DESCRIBE. For load balancing and other temporary redirection 307 SHOULD be used. Example: C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 M->C: RTSP/1.0 307 Temporary Redirect CSeq: 1 Location: rtsp://123.34.322.67:554/foo/twister 3) Explicit RTSP redirection (bis) using REDIRECT
The server MAY reply by sending a REDIRECT instead of answering the DESCRIBE. The alternate server MUST be indicated in the Location header. The client (if it wants to...) SHOULD connect to the other server and start the session with DESCRIBE. Example: C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 M->C: REDIRECT rtsp://foo/twister RTSP/1.0 CSeq: 1 Location: rtsp://123.34.322.67:554/foo/twister regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 13: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 NAA21384 for ; Wed, 25 Jun 2003 13:04:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PH48p15330 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 13:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDgm-0003yX-GG for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 13:04:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21369 for ; Wed, 25 Jun 2003 13:04:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDgl-0005Qu-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 13:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VDgg-0005Qr-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 13:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDgf-0003vg-Lz; Wed, 25 Jun 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDgA-0003ug-9r for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 13:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21354 for ; Wed, 25 Jun 2003 13:03:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDg9-0005QW-00 for mmusic@ietf.org; Wed, 25 Jun 2003 13:03:29 -0400 Received: from wireless206.east.isi.edu ([65.123.202.206] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19VDfy-0005Q3-00 for mmusic@ietf.org; Wed, 25 Jun 2003 13:03:18 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h5PH2iSR003243; Wed, 25 Jun 2003 13:02:44 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 25 Jun 2003 13:02:44 -0400 From: Colin Perkins To: Magnus Westerlund Cc: thomas.belling@siemens.com, mmusic@ietf.org Subject: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams Message-Id: <20030625130244.055bd715.csp@csperkins.org> In-Reply-To: <3EF95489.6050406@ericsson.com> References: <3EF95489.6050406@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Can you suggest explicit wording changes to clarify the draft? There is probably still time to incorporate minor edits for clarification. Colin --> Magnus Westerlund writes: > Hi Thomas, >=20 > Even more inline: >=20 > Belling Thomas wrote: > > Hi Magnus, > >=20 > > My answers are inline > >=20 > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Gesendet: Montag, 23. Juni 2003 09:27 > > An: Belling Thomas > > Cc: 'mmusic@ietf.org' > > Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams > >=20 > >=20 > > Hi, > >=20 > > I would agree with the interpretation, at least when it comes to b=3DAS > > as it clearly specifies that this is the RTP session bandwidth. When > > one uses a m=3D line with port/2 it becomes two RTP sessions. However I > > am not certain over how one should in this case interpret any of the > > other bandwidth attributes. > >=20 > > [Thomas] Fine, but is that 100 Percent clear from the wording of the > > RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a clarification > > there >=20 > Yes, this should probably be clarified. I don't think it is obvious. >=20 > >=20 > > The available bandwidth modifiers are: > > CT > > RR > > RS > >=20 > > Lets look at them: > >=20 > > CT is defined in draft-ietf-mmusic-sdp-new-12 as: > > CT Conference Total > > If the bandwidth of a session or media in a session is > > different from the bandwidth implicit from the scope, a > > "b=3DCT:..." line should be supplied for the session giving > > the proposed upper limit to the bandwidth used. The > > primary purpose of this is to give an approximate idea as > > to whether two or more sessions can co-exist > > simultaneously. > >=20 > > Based on this I would interpret that a given CT value should be for the > > complete media, i.e. counting the total of both RTP sessions. > >=20 > > [Thomas] I agree that this is an interpretation in line with my > > understanding of the intentions of the CT bandwidth modifier. However, > > the wording is not so clear. What is a "session"? If you understand > > "RTP session", this would contradict your interpretation. As an aside: > > 3GPP ignores this parameter, so from that perspective a clarification > > is less urgent than for the AS modifier. >=20 > Yes, the session in the quote is a bit unclear. I think it is a larger=20 > session concept, like the complete streaming session, or probably when=20 > it was written the conferencing session with all the media included. On=20 > media level the text indicates the complete media, which in this case is= =20 > transported over several RTP sessions. So based on these two=20 > interpretations I arrive at my conclusion. >=20 > > When it concerns TIAS I will do the same interpretation that the=20 > > bandwidth value apply per RTP session. > >=20 > > [Thomas] Makes sense if you take TIAS as a kind of refinement of the AS > > modifier. I did not yet read the draft with that question in mind, and > > the draft is still in a stage where this can be clarified. >=20 > Yes, it can still be modified. I have made an update and I did not=20 > address the issue. The reason being is that I think the SDP draft should= =20 > first address this. Based on this clarification I would add to the=20 > TIAS draft if necessary. >=20 > >=20 > > My concern is that this simplistic model is probably not what you would > > like if you would actually use this functionality. If one uses multiple > > RTP sessions for a single media you are probably doing some form of=20 > > scalability, etc., and would like to specify the values independently=20 > > per RTP session. Fortunately there exist today alternatives to achieve= =20 > > this behaviour today. With the help of grouping of media lines it is=20 > > possible to specify that several m=3D lines are part of the same media.= =20 > > Using FID there is only a pitfall with the following sentence: > > "A media agent handling a media flow that comprises several "m" > > lines MUST send a copy of the media to every "m" line part of the > > flow as long as the codecs and the direction attribute present in a > > particular "m" line allow it." > >=20 > > If that is a problem it might be easier to define a new grouping=20 > > attribute for that situation. > > Finally I have a question to the group, has anyone seen that "m=3D port= /2 > > ..." ever been used. And in that case how. > >=20 > > [Thomas] Take the simple example of stereo sound. Why not use the "m=3D > > port/2 " notification for that? Something in that direction might have > > been the original motification. From a 3GPP perspective, where this > > relates to thev bandwidth on the air and possibly the rate charged for > > a service, we should have a clear understanding as this possibility > > exists and might also be misused otherwise. >=20 > I don't think stereo is a good example. First reason is that you=20 > normally don't split left and right channel into different packets,=20 > unless they are really big, reasons are like synchronization. Therefore=20 > most audio codecs are possible to transport over RTP using a single=20 > source. The sample based codec normally only specify that every other=20 > sample is left and the other are right. Frame based codec normally have= =20 > more advanced schemes where they encode left and right together to take=20 > advantage of the similarities between channels. >=20 > My thinking is actually along the lines, if no one uses it, why not=20 > remove it, we will still have to if no implementations are identified=20 > when going to draft standard. >=20 >=20 > Best Regards >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 14:00: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 OAA23100 for ; Wed, 25 Jun 2003 14:00:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PI08M26878 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 14:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEYy-0006zR-N8 for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 14:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23089 for ; Wed, 25 Jun 2003 14:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEYx-0005iZ-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 14:00:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VEYs-0005iW-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 14:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEYr-0006yM-5k; Wed, 25 Jun 2003 14:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEXt-0006wL-Ng for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 13:59:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23058 for ; Wed, 25 Jun 2003 13:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEXs-0005iA-00 for mmusic@ietf.org; Wed, 25 Jun 2003 13:59:00 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19VEXh-0005i7-00 for mmusic@ietf.org; Wed, 25 Jun 2003 13:58:49 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19VEXL-0001Mb-00; Wed, 25 Jun 2003 10:58:27 -0700 Date: Wed, 25 Jun 2003 10:58:27 -0700 From: Tom Marshall To: philippe.gentric@philips.com Cc: mmusic@ietf.org Subject: Re: [MMUSIC] material for RTSP spec clarification Message-ID: <20030625175827.GA5096@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 25, 2003 at 06:38:04PM +0200, philippe.gentric@philips.com wrot= e: > A RTSP server MAY redirect a client in reply to DESCRIBE... >=20 >=20 > sure, but there are several ways to do that ... > after the last discussions on the reflector and during the > conference call, I would like to try to re-sumarize > what I hope is a correct understanding of the consensus ;-) >=20 > NB: this is intended as possible material for a > clarification in the next release of the RTSP specification >=20 >=20 > 1) SDP redirection >=20 >=20 > The server MAY reply 200 with absolute URLs in the SDP response > where another server is indicated by these absolute URLs. >=20 > A client MUST be ready to examine the SDP for absolute URLs. The > client (if it wants to...) SHOULD connect to the other server and > MAY start the session with SETUP since the information in the SDP > is deemed valid. >=20 > The absolute URLs -in case there are several of them e.g. audio > and video- MUST point to the same streaming server. has been recently proposed by Magnus> This is good. But I would prefer SHOULD instead of MUST here. It would also be good to mention and provide an example for redirection via the Content-Base header. An example for a load-balanced virtual server foo.example.com with actual servers foo-1 .. foo-N might look like this (note I did not recalculate Content-Length): C->M: DESCRIBE rtsp://foo.example.com/twister RTSP/1.0 CSeq: 1 M->C: RTSP/1.0 200 OK CSeq: 1 Content-Base: rtsp://foo-3.example.com/twister/ Content-Type: application/sdp Content-Length: 164 v=3D0 o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 s=3DRTSP Session i=3DAn Example of RTSP Session Usage a=3Dcontrol:* t=3D0 0 m=3Daudio 0 RTP/AVP 0 a=3Dcontrol:audio m=3Dvideo 0 RTP/AVP 26 a=3Dcontrol:video And finally, a note that the client logic is the same in all of these cases might be good. This would clarify that each example is not a special case, but rather that the client need only follow the rules set forth in C.1.1 to compute the proper stream urls. --=20 Old timer, n.: One who remembers when charity was a virtue and not an organization. --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE++eLDqznSmcYu2m8RApoiAJsHZSc/k2o4dBB+fwt/6ctrGxBlUQCeMyeQ 0oqqMNzsft1kFeD8cP+ex1A= =JrMx -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 14:37: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 OAA24589 for ; Wed, 25 Jun 2003 14:37:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PIbEm03222 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 14:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF8s-0000pt-Ee for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 14:37:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24526 for ; Wed, 25 Jun 2003 14:37:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VF7n-0005z0-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 14:36:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VF7i-0005yx-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 14:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF7h-0000bM-Sy; Wed, 25 Jun 2003 14:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VF6n-0000YW-Nt for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 14:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24437 for ; Wed, 25 Jun 2003 14:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VF6l-0005yD-00 for mmusic@ietf.org; Wed, 25 Jun 2003 14:35:03 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VF6a-0005x5-00 for mmusic@ietf.org; Wed, 25 Jun 2003 14:34:52 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PIX0w2001018; Wed, 25 Jun 2003 20:33:00 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP0HQG6; Wed, 25 Jun 2003 20:32:51 +0200 Message-ID: <3EF9EA0F.4090504@ericsson.com> Date: Wed, 25 Jun 2003 20:29:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] material for RTSP spec clarification References: 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 philippe.gentric@philips.com wrote: > A RTSP server MAY redirect a client in reply to DESCRIBE... > > > sure, but there are several ways to do that ... > after the last discussions on the reflector and during the > conference call, I would like to try to re-sumarize > what I hope is a correct understanding of the consensus ;-) > > NB: this is intended as possible material for a > clarification in the next release of the RTSP specification > > > 1) SDP redirection > > > The server MAY reply 200 with absolute URLs in the SDP response > where another server is indicated by these absolute URLs. > > A client MUST be ready to examine the SDP for absolute URLs. The > client (if it wants to...) SHOULD connect to the other server and > MAY start the session with SETUP since the information in the SDP > is deemed valid. > > The absolute URLs -in case there are several of them e.g. audio > and video- MUST point to the same streaming server. has been recently proposed by Magnus> I think a MUST is to strong, a RECOMMENDED and then add a note in the minimal implementation for client that they do not need to handle redirections that result in that sessions must be setup as several non-aggregated sessions to different servers. This will in fact have the effect that no one will use unless they know they have support for it, based on client or application context. > > retrieving the session information in the sense that the same SDP > may be obtained in several alternative ways. Specifically this > "redirection" is actually similar to what happens when a > streaming session is initiated by retrieving a SDP from a web > (HTTP) server (or via Email etc) i.e. it would not make sense to > exclude the case where that same SDP would be served by a RTSP > server under the pretext that that server is not the final > streaming server.> > > > Example: > > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > M->C: RTSP/1.0 200 OK > CSeq: 1 > Content-Type: application/sdp > Content-Length: 164 > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > i=An Example of RTSP Session Usage > a=control:rtsp://123.34.322.67:554/foo/twister > t=0 0 > m=audio 0 RTP/AVP 0 > a=control:rtsp://123.34.322.67:554/foo/twister/audio > m=video 0 RTP/AVP 26 > a=control:rtsp://123.34.322.67:554/foo/twister/video > > > 2) Explicit RTSP redirection > > > The server MAY reply 3xx (possible status values are described in > RFC2616 section 10.3). > > This response MUST NOT contain any SDP. "really" missing> > I agree that we should clarify this. In the spec this will be formulated as a 3rr response SHALL NOT contain any body. I need to think a bit more about this and if no body at all is the right decision. > The alternate server MUST be indicated in the Location header. > The client (if it wants to...) SHOULD connect to the other server > and restart the session with DESCRIBE. > > For load balancing and other temporary redirection 307 SHOULD be > used. since the text in RFC2616 about the various 3xx status is pretty > complicated (and very HTTP focused ;-)> I don't think we need 307, when 302 is written as intended for this. The current text for 302 from version 03 of the draft: 12.3.3 302 Found The requested resource reside temporarily at the URI given by the Location header. The Location header MUST be included. Is intended to be used for many types of temporary redirects, e.g. load balancing. It is RECOMMENDED that one set the reason phrase to something more meaningful than "Found" in these cases. > > Example: > > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > M->C: RTSP/1.0 307 Temporary Redirect > CSeq: 1 > Location: rtsp://123.34.322.67:554/foo/twister > > > 3) Explicit RTSP redirection (bis) using REDIRECT > >
does not address explicitely the case> > I don't think this is how this should be solved. If a client has an outstanding request with the server, it should simply respond to the request. If one is going to shutdown a server, or other drastic things that forces a server to use REDIRECT, then he has probably some time to answer any request with REDIRECT codes. Then for the already established sessions it needs to send REDIRECT. > The server MAY reply by sending a REDIRECT instead of answering > the DESCRIBE. > > The alternate server MUST be indicated in the Location header. > The client (if it wants to...) SHOULD connect to the other server > and start the session with DESCRIBE. > > Example: > > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > M->C: REDIRECT rtsp://foo/twister RTSP/1.0 > CSeq: 1 > Location: rtsp://123.34.322.67:554/foo/twister > > So scrape this case in my opinion. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 15:24:15 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 PAA27256 for ; Wed, 25 Jun 2003 15:24:15 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PJNmr14261 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 15:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFrv-0003hw-Sx for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 15:23:47 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27217 for ; Wed, 25 Jun 2003 15:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFrB-0003df-Mp; Wed, 25 Jun 2003 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFrA-0003dT-79 for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 15:23:00 -0400 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27202 for ; Wed, 25 Jun 2003 15:22:57 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PJMvw2005072 for ; Wed, 25 Jun 2003 21:22:58 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRSTN2; Wed, 25 Jun 2003 21:24:49 +0200 Message-ID: <3EF9F5C4.7040702@ericsson.com> Date: Wed, 25 Jun 2003 21:19:32 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: REDIRECT issues Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have thought of a couple of issues regarding the use of REDIRECT, especially the new * requests, i.e. without session header. 1. When using REDIRECT without session header what a client can expect regarding outstanding request should be clarified. In the current text it is not very clear how to handle these. I think it is okay to consider these as lost, however this should be clear. However I think there should be recommendations to respond to outstanding requests. 2. When using REDIRECT without session header are the sessions at this server closed automatically by acknowledging the request? If yes, then why no have the same behaviour for all REDIRECT, also the explicitly noted sessions except for those with Range Header. I think we should try to harmonize the behaviour here. Also having automatic session termination saves us some request that in my opinion are not needed. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jun 25 23:41: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 XAA24233 for ; Wed, 25 Jun 2003 23:41:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q3fDD00975 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 23:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VNdJ-0000Fe-Bt for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 23:41:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24206 for ; Wed, 25 Jun 2003 23:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNdH-0005AC-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 23:41:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VNdB-0005A4-00 for mmusic-web-archive@ietf.org; Wed, 25 Jun 2003 23:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VNd6-000050-O0; Wed, 25 Jun 2003 23:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VNcL-0008Ve-0f for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 23:40:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24186 for ; Wed, 25 Jun 2003 23:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNc3-00059u-00 for mmusic@ietf.org; Wed, 25 Jun 2003 23:39:55 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19VNbs-00059q-00 for mmusic@ietf.org; Wed, 25 Jun 2003 23:39:44 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 25 Jun 2003 20:27:41 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Wed, 25 Jun 2003 20:27:40 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Wed, 25 Jun 2003 20:36:03 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19VNYo-00033T-00 for ; Wed, 25 Jun 2003 20:36:34 -0700 Date: Wed, 25 Jun 2003 20:35:14 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_20,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #80 - 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-557045 ] Need "Supported" header (SourceForge.net) 2. [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification (SourceForge.net) 3. [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method (SourceForge.net) 4. [ rtspspec-Bugs-531189 ] How does REDIRECT method work (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 25 Jun 2003 11:12:32 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-557045 ] Need "Supported" header Bugs item #557045, was opened at 2002-05-17 04:05 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=557045&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Magnus Westerlund (magwes) Summary: Need "Supported" header Initial Comment: This is added to resolve http://rtsp.org/bug477427 There needs to be a way for non-fatal queries which can be issued with methods. The current proposal is to use the SIP "Supported" header. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 20:12 Message: Logged In: YES user_id=302620 The supported header has been in added an in there for quite a while. No comments. Closing bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:23 Message: Logged In: YES user_id=302620 The Supported header is added to the text. Including usage under options. One consideration has been rasied that the message size can be rather big if many option tags are defined. Due to interoperability it seems that rather many tags need to be defined. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-05-21 02:20 Message: Logged In: YES user_id=3796 Current proposal checked into CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/headers.tex.diff?r1=1.15&r2=1.16 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=557045&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 25 Jun 2003 11:43:34 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification Bugs item #608365, was opened at 2002-09-12 15:23 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: 3xx codes overhaul and clarification Initial Comment: The 3xx codes are all directly taken from HTTP. There seem that not all are suitable for RTSP. A review of the codes and the needs should be perforemed. Also the usage of 3xx responses needs some work. What headers to include, etc. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 20:43 Message: Logged In: YES user_id=302620 Tom marshall wrote up a proposal for new text regarding the 3xx codes that seperate 304 from the rest. This has been edited in since the 03 version of the draft. No new codes has been specified. The use of 303 is still deprecatied. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:27 Message: Logged In: YES user_id=302620 I have written up a proposal for fixing this within the spec. Two new codes are defiend 350, and 351. 303 is suggested to be decapitated. 304 needs further discussion. Also user comments has been added to the status chapter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 25 Jun 2003 12:05:31 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method Bugs item #492546, was opened at 2001-12-13 18:44 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=492546&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) >Assigned to: Magnus Westerlund (magwes) Summary: Shouldn't close on unsupported method Initial Comment: When a server (or client) receives an unsupported method, and the request is well-formed (complies with BNF for Request, and contains CSeq), we should mandate that a server MUST not close down an existing playback session. This is an extensibility issue. If, during playback, the client requests a certain method that the server doesn't support, and we allow session shutdown, then we've painted ourselves in a corner where we can't comfortably extend the protocol. The client may determine that support for a method is required, at which point, the client may disconnect the session. However, the client should be given the option to account for the error and continue playback. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 21:05 Message: Logged In: YES user_id=302620 Some text on this has been edited in to the specification in the chapter regarding TCP connections. There is also a clarification regarding the use of the "Connetion" header and the option "close". Please review these changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=492546&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 25 Jun 2003 12:11:12 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-531189 ] How does REDIRECT method work Bugs item #531189, was opened at 2002-03-18 05:14 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=531189&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: Magnus Westerlund (magwes) Summary: How does REDIRECT method work Initial Comment: In the spec there is conflicting wording on what will happend when the server sends a REDIRECT to the client. In the state machine part the RFC says that the server should go to init state. Section 10.10 REDIRECT says that the client must do TEARDOWN on the session. How is it supposed to work espically combined with RANGE needs to be clarified also see #513891 ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 21:11 Message: Logged In: YES user_id=302620 There has been updated text on the use of REDIRECT. The usage of Range has also been clarified and solution for all use cases exist. Two issue remains regarding redirect. 1. Should acknowleging a REDIRECT request mean that the session is closed? Currently there exist on special case regarding the use of * in the request that indicates that transport link shall be closed, the session should be closed automatically. However for the other cases when sessions is targeted directly they are supposed to send a TEARDOWN for that session. 2. How should the client handle any outstanding request when it receives a REDIRECT request with *? ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-18 17:12 Message: Logged In: YES user_id=302620 The proposed solution for ranges does not work for content that uses UTC for positioning, like surveilance tapes. Suggestions on how to solve this, please. In case that the location header only contains a server adress the client may assume that the media is identical and does not need to send a DESCRIBE before setting up a new session. Otherwise it needs to do it as media may be different. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-12 15:12 Message: Logged In: YES user_id=302620 One more problem is that a client does not know if it should issue a play with the range where it was redirected or start from the begining. In the case of a media on deman and it gets identical media from the new server it seems more valid to resume at the position it was redirected at. However if it gets redirected to another media it should start from the beginng. And in the case of live media it should simply not use any range in its PLAY request. A mechanism needs to be added that solves this problem. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-12 15:08 Message: Logged In: YES user_id=302620 The result of a MMUSIC discussion is: 3xx Responses: The server should use this to signal the client that it should go find the media somewhere else. This answer can be used on the methods that do inquires regarding the media or tries to establish a session, i.e. OPTIONS (with media URL), DESCRIBE, SETUP, and perhaps ANNOUNCE. It should not be used when a server has an already established session and needs to move that session to another server, i.e. don't use them on PAUSE, PLAY, RECORD. The client after receiving a REDIRECT must restart its work on getting session information and setting up the session. REDIRECT request: This method shall be used when the server needs to move already established session from this server. So it shall not be used unless there is a session identifier to reference. The redirect request SHOULD use contain the session control URL and MUST include a session header. This enables the client a unambiguous identification of which session it should move. I don't know if the server should go directly to INIT after receiving the response from the client on the REDIRECT. This would allow the server to reclaim any resources as fast as possible. Alternatively the server should wait for a teardown, but this seem to waste a round trip of time. But as both behaviors are hinted in RFC 2326 it needs clarification. When a client has received a REDIRECT request and acknowledge the redirect it must assume that the session does no longer exist. The exception is if a range header was part of the request, and in that case it will be without a session at the specified moment. So after receiving a redirect the client must start from scratch to establish a new session at the given location. Use of location header: My opinion is that is should be a complete RTSP URL. Use of Range header: Also how the Range header shall be interpreted together with REDIRECT needs to be clarified. As the desired behavior may vary I think we need to be a little bit cleaver here. If a range header is included and contains a time in UTC it shall be interpreted that the server will serve this client until that UTC time, and after that time the client needs to establish a new session at the given location. If a SMPTE or NPT time is given the session will end when the playback reaches the given point in the media. So in the case the client rewinds to the start before reaching specified media point the session will remain. By using UTC time the server can signal that I can't handle your request further than e.g. until 18.00 today. Using NPT will allow a server to redirect a user due to limitations of the media, e.g. charging for rest of movie. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=531189&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 04:25:06 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 EAA12182 for ; Thu, 26 Jun 2003 04:25:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8OcG23182 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3a-00061p-P1 for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11905 for ; Thu, 26 Jun 2003 04:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VS3I-0006aG-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VS3C-0006aB-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3F-0005s9-0T; Thu, 26 Jun 2003 04:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VRnu-0004x4-3O for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 04:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11662 for ; Thu, 26 Jun 2003 04:08:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRnq-0006Vv-00 for mmusic@ietf.org; Thu, 26 Jun 2003 04:08:22 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VRnf-0006Vl-00 for mmusic@ietf.org; Thu, 26 Jun 2003 04:08:12 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q87qG5020472; Thu, 26 Jun 2003 10:07:52 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGMT0DW; Thu, 26 Jun 2003 10:06:34 +0200 Message-ID: <3EFAA90A.2020409@ericsson.com> Date: Thu, 26 Jun 2003 10:04:26 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: emre.aksu@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] material for RTSP spec clarification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Emre, See below: emre.aksu@nokia.com wrote: > Magnus, > > >>>3) Explicit RTSP redirection (bis) using REDIRECT >>> >>>
>>does not address explicitely the case> >>> >>I don't think this is how this should be solved. If a client has an >>outstanding request with the server, it should simply respond to the >>request. If one is going to shutdown a server, or other >>drastic things >>that forces a server to use REDIRECT, then he has probably >>some time to >>answer any request with REDIRECT codes. Then for the already >>established >>sessions it needs to send REDIRECT. >> >> >>> The server MAY reply by sending a REDIRECT instead of answering >>> the DESCRIBE. >>> >>> The alternate server MUST be indicated in the Location header. >>> The client (if it wants to...) SHOULD connect to the other server >>> and start the session with DESCRIBE. >>> >>> Example: >>> >>> >>> C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 >>> CSeq: 1 >>> >>> M->C: REDIRECT rtsp://foo/twister RTSP/1.0 >>> CSeq: 1 >>> Location: rtsp://123.34.322.67:554/foo/twister >>> >>> >> >>So scrape this case in my opinion. > > > I don't think that this case is an illegal or improbable case. It should be up to the server to decide how to initiate the redirection, as long as it is not breaking the RTSP rules. Do you see an illegal RTSP usage here? As I pointed out in another mail we need to resolve what happens when a client receives a REDIRECT request and has outstanding request itself. However in my view this behaviour is not a recommended one, if one has outstanding DESCRIBES or SETUP requests it seems to be much simpler and cleaner for the server to just respond with a 3rr code. So although maybe possible it should not be on the recommended list. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 04:25:06 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 EAA12184 for ; Thu, 26 Jun 2003 04:25:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8OdM23199 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3a-000621-VW for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11908 for ; Thu, 26 Jun 2003 04:24:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VS3I-0006aE-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VS3C-0006a9-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3B-0005na-QO; Thu, 26 Jun 2003 04:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VReu-0003wz-OL for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 03:59:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11562 for ; Thu, 26 Jun 2003 03:58:51 -0400 (EDT) From: emre.aksu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRec-0006UE-00 for mmusic@ietf.org; Thu, 26 Jun 2003 03:58:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19VReS-0006UA-00 for mmusic@ietf.org; Thu, 26 Jun 2003 03:58:40 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5Q7w4927681 for ; Thu, 26 Jun 2003 10:58:04 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Jun 2003 10:58:03 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 26 Jun 2003 10:58:02 +0300 Received: from trebe006.NOE.Nokia.com ([172.22.232.181]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 26 Jun 2003 10:57:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] material for RTSP spec clarification Date: Thu, 26 Jun 2003 10:57:43 +0300 Message-ID: Thread-Topic: [MMUSIC] material for RTSP spec clarification Thread-Index: AcM7SLD4PmfwpzwdTMe5R3XeJzmoUwAbnnqA To: Cc: X-OriginalArrivalTime: 26 Jun 2003 07:57:57.0315 (UTC) FILETIME=[A7E24130:01C33BB8] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Magnus, > > 3) Explicit RTSP redirection (bis) using REDIRECT > >=20 > >
> does not address explicitely the case> > > >=20 > I don't think this is how this should be solved. If a client has an=20 > outstanding request with the server, it should simply respond to the=20 > request. If one is going to shutdown a server, or other=20 > drastic things=20 > that forces a server to use REDIRECT, then he has probably=20 > some time to=20 > answer any request with REDIRECT codes. Then for the already=20 > established=20 > sessions it needs to send REDIRECT. >=20 > > The server MAY reply by sending a REDIRECT instead of answering > > the DESCRIBE. > >=20 > > The alternate server MUST be indicated in the Location header. > > The client (if it wants to...) SHOULD connect to the other server > > and start the session with DESCRIBE. > >=20 > > Example: > >=20 > >=20 > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > > CSeq: 1 > >=20 > > M->C: REDIRECT rtsp://foo/twister RTSP/1.0 > > CSeq: 1 > > Location: rtsp://123.34.322.67:554/foo/twister > >=20 > >=20 >=20 > So scrape this case in my opinion. I don't think that this case is an illegal or improbable case. It should = be up to the server to decide how to initiate the redirection, as long = as it is not breaking the RTSP rules. Do you see an illegal RTSP usage = here? Best Regards, Emre Emre Baris Aksu Nokia Mobile Phones Multimedia Technologies > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 25 June, 2003 21:30 > To: philippe.gentric@philips.com > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] material for RTSP spec clarification >=20 >=20 >=20 >=20 > philippe.gentric@philips.com wrote: > > A RTSP server MAY redirect a client in reply to DESCRIBE... > >=20 > >=20 > > sure, but there are several ways to do that ... > > after the last discussions on the reflector and during the > > conference call, I would like to try to re-sumarize > > what I hope is a correct understanding of the consensus ;-) > >=20 > > NB: this is intended as possible material for a > > clarification in the next release of the RTSP specification > >=20 > >=20 > > 1) SDP redirection > >=20 > >=20 > > The server MAY reply 200 with absolute URLs in the SDP response > > where another server is indicated by these absolute URLs. > >=20 > > A client MUST be ready to examine the SDP for absolute URLs. The > > client (if it wants to...) SHOULD connect to the other server and > > MAY start the session with SETUP since the information in the SDP > > is deemed valid. > >=20 > > The absolute URLs -in case there are several of them e.g. audio > > and video- MUST point to the same streaming server.=20 > > has been recently proposed by Magnus> >=20 > I think a MUST is to strong, a RECOMMENDED and then add a note in the=20 > minimal implementation for client that they do not need to handle=20 > redirections that result in that sessions must be setup as several=20 > non-aggregated sessions to different servers. This will in=20 > fact have the=20 > effect that no one will use unless they know they have=20 > support for it,=20 > based on client or application context. >=20 > >=20 > > in RTSP for > > retrieving the session information in the sense that the same SDP > > may be obtained in several alternative ways. Specifically this > > "redirection" is actually similar to what happens when a > > streaming session is initiated by retrieving a SDP from a web > > (HTTP) server (or via Email etc) i.e. it would not make sense to > > exclude the case where that same SDP would be served by a RTSP > > server under the pretext that that server is not the final > > streaming server.> > >=20 > >=20 > > Example: > >=20 > >=20 > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > > CSeq: 1 > >=20 > > M->C: RTSP/1.0 200 OK > > CSeq: 1 > > Content-Type: application/sdp > > Content-Length: 164 > >=20 > > v=3D0 > > o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 > > s=3DRTSP Session > > i=3DAn Example of RTSP Session Usage > > a=3Dcontrol:rtsp://123.34.322.67:554/foo/twister > > t=3D0 0 > > m=3Daudio 0 RTP/AVP 0 > > a=3Dcontrol:rtsp://123.34.322.67:554/foo/twister/audio > > m=3Dvideo 0 RTP/AVP 26 > > a=3Dcontrol:rtsp://123.34.322.67:554/foo/twister/video > >=20 > >=20 > > 2) Explicit RTSP redirection > >=20 > >=20 > > The server MAY reply 3xx (possible status values are described in > > RFC2616 section 10.3). > >=20 > > This response MUST NOT contain any SDP. > "really" missing> > >=20 > I agree that we should clarify this. In the spec this will be=20 > formulated=20 > as a 3rr response SHALL NOT contain any body. I need to think=20 > a bit more=20 > about this and if no body at all is the right decision. >=20 > > The alternate server MUST be indicated in the Location header. > > The client (if it wants to...) SHOULD connect to the other server > > and restart the session with DESCRIBE. > >=20 > > For load balancing and other temporary redirection 307 SHOULD be > > used. > since the text in RFC2616 about the various 3xx status is pretty > > complicated (and very HTTP focused ;-)> >=20 > I don't think we need 307, when 302 is written as intended for this. >=20 > The current text for 302 from version 03 of the draft: >=20 > 12.3.3 302 Found >=20 > The requested resource reside temporarily at the URI given by the > Location header. The Location header MUST be included. Is=20 > intended to > be used for many types of temporary redirects, e.g. load=20 > balancing. > It is RECOMMENDED that one set the reason phrase to something more > meaningful than "Found" in these cases. >=20 >=20 >=20 > >=20 > > Example: > >=20 > >=20 > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > > CSeq: 1 > >=20 > > M->C: RTSP/1.0 307 Temporary Redirect > > CSeq: 1 > > Location: rtsp://123.34.322.67:554/foo/twister > >=20 > >=20 > > 3) Explicit RTSP redirection (bis) using REDIRECT > >=20 > >
> does not address explicitely the case> > > >=20 > I don't think this is how this should be solved. If a client has an=20 > outstanding request with the server, it should simply respond to the=20 > request. If one is going to shutdown a server, or other=20 > drastic things=20 > that forces a server to use REDIRECT, then he has probably=20 > some time to=20 > answer any request with REDIRECT codes. Then for the already=20 > established=20 > sessions it needs to send REDIRECT. >=20 > > The server MAY reply by sending a REDIRECT instead of answering > > the DESCRIBE. > >=20 > > The alternate server MUST be indicated in the Location header. > > The client (if it wants to...) SHOULD connect to the other server > > and start the session with DESCRIBE. > >=20 > > Example: > >=20 > >=20 > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > > CSeq: 1 > >=20 > > M->C: REDIRECT rtsp://foo/twister RTSP/1.0 > > CSeq: 1 > > Location: rtsp://123.34.322.67:554/foo/twister > >=20 > >=20 >=20 > So scrape this case in my opinion. >=20 > Best Regards >=20 >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 04:39: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 EAA12596 for ; Thu, 26 Jun 2003 04:39:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8d7232286 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 04:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSHb-0008Of-6r for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12575 for ; Thu, 26 Jun 2003 04:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSHY-0006hr-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:39:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VSHS-0006ho-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:38:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSHU-0008O4-OI; Thu, 26 Jun 2003 04:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSGT-0008D6-AS for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 04:38:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12568 for ; Thu, 26 Jun 2003 04:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSGQ-0006he-00 for mmusic@ietf.org; Thu, 26 Jun 2003 04:37:54 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VSGF-0006hV-00 for mmusic@ietf.org; Thu, 26 Jun 2003 04:37:43 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q8bOw2005201; Thu, 26 Jun 2003 10:37:24 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGM4FNQ; Thu, 26 Jun 2003 10:36:05 +0200 Message-ID: <3EFAAFF5.3050708@ericsson.com> Date: Thu, 26 Jun 2003 10:33:57 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] material for RTSP spec clarification References: 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 Philippe, See below: philippe.gentric@philips.com wrote: > magnus you wrote: > > >>>3) Explicit RTSP redirection (bis) using REDIRECT >> >>[...big piece missing here] >> >>So scrape this case in my opinion. >> > > > > What would be the sentence then? > > "Servers MUST NOT use REDIRECT after a DESCRIBE but must use > one of the other redicrection mean, for example return a 3xx code" We need to resolve how to handle outstanding reqests with REDIRECT first before determing this issue. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 04:57: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 EAA12994 for ; Thu, 26 Jun 2003 04:57:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8v8406384 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 04:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSZ2-0001et-H3 for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12962 for ; Thu, 26 Jun 2003 04:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSYz-0006oe-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:57:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VSYt-0006ob-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 04:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSYv-0001eS-UO; Thu, 26 Jun 2003 04:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSYT-0001dk-B4 for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 04:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12944; Thu, 26 Jun 2003 04:56:15 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSYB-0006oM-00; Thu, 26 Jun 2003 04:56:15 -0400 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 19VSY0-0006oJ-00; Thu, 26 Jun 2003 04:56:04 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id 3C25A6C7FC; Thu, 26 Jun 2003 10:25:44 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA23772; Thu, 26 Jun 2003 10:25:43 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA17353; Thu, 26 Jun 2003 10:25:42 +0200 (MEST) Subject: Re: [MMUSIC] material for RTSP spec clarification To: Magnus Westerlund Cc: mmusic@ietf.org, mmusic-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 26 Jun 2003 10:16:43 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/06/2003 10:26: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 you wrote: >> 3) Explicit RTSP redirection (bis) using REDIRECT > > [...big piece missing here] > >So scrape this case in my opinion. > What would be the sentence then? "Servers MUST NOT use REDIRECT after a DESCRIBE but must use one of the other redicrection mean, for example return a 3xx code" regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: mmusic@ietf.org Subject: Re: [MMUSIC] material for RTSP spec clarification Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 25/06/2003 20:29 philippe.gentric@philips.com wrote: > A RTSP server MAY redirect a client in reply to DESCRIBE... > > > sure, but there are several ways to do that ... > after the last discussions on the reflector and during the > conference call, I would like to try to re-sumarize > what I hope is a correct understanding of the consensus ;-) > > NB: this is intended as possible material for a > clarification in the next release of the RTSP specification > > > 1) SDP redirection > > > The server MAY reply 200 with absolute URLs in the SDP response > where another server is indicated by these absolute URLs. > > A client MUST be ready to examine the SDP for absolute URLs. The > client (if it wants to...) SHOULD connect to the other server and > MAY start the session with SETUP since the information in the SDP > is deemed valid. > > The absolute URLs -in case there are several of them e.g. audio > and video- MUST point to the same streaming server. has been recently proposed by Magnus> I think a MUST is to strong, a RECOMMENDED and then add a note in the minimal implementation for client that they do not need to handle redirections that result in that sessions must be setup as several non-aggregated sessions to different servers. This will in fact have the effect that no one will use unless they know they have support for it, based on client or application context. > > retrieving the session information in the sense that the same SDP > may be obtained in several alternative ways. Specifically this > "redirection" is actually similar to what happens when a > streaming session is initiated by retrieving a SDP from a web > (HTTP) server (or via Email etc) i.e. it would not make sense to > exclude the case where that same SDP would be served by a RTSP > server under the pretext that that server is not the final > streaming server.> > > > Example: > > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > M->C: RTSP/1.0 200 OK > CSeq: 1 > Content-Type: application/sdp > Content-Length: 164 > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > i=An Example of RTSP Session Usage > a=control:rtsp://123.34.322.67:554/foo/twister > t=0 0 > m=audio 0 RTP/AVP 0 > a=control:rtsp://123.34.322.67:554/foo/twister/audio > m=video 0 RTP/AVP 26 > a=control:rtsp://123.34.322.67:554/foo/twister/video > > > 2) Explicit RTSP redirection > > > The server MAY reply 3xx (possible status values are described in > RFC2616 section 10.3). > > This response MUST NOT contain any SDP. "really" missing> > I agree that we should clarify this. In the spec this will be formulated as a 3rr response SHALL NOT contain any body. I need to think a bit more about this and if no body at all is the right decision. > The alternate server MUST be indicated in the Location header. > The client (if it wants to...) SHOULD connect to the other server > and restart the session with DESCRIBE. > > For load balancing and other temporary redirection 307 SHOULD be > used. since the text in RFC2616 about the various 3xx status is pretty > complicated (and very HTTP focused ;-)> I don't think we need 307, when 302 is written as intended for this. The current text for 302 from version 03 of the draft: 12.3.3 302 Found The requested resource reside temporarily at the URI given by the Location header. The Location header MUST be included. Is intended to be used for many types of temporary redirects, e.g. load balancing. It is RECOMMENDED that one set the reason phrase to something more meaningful than "Found" in these cases. > > Example: > > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > M->C: RTSP/1.0 307 Temporary Redirect > CSeq: 1 > Location: rtsp://123.34.322.67:554/foo/twister > > > 3) Explicit RTSP redirection (bis) using REDIRECT > >
does not address explicitely the case> > I don't think this is how this should be solved. If a client has an outstanding request with the server, it should simply respond to the request. If one is going to shutdown a server, or other drastic things that forces a server to use REDIRECT, then he has probably some time to answer any request with REDIRECT codes. Then for the already established sessions it needs to send REDIRECT. > The server MAY reply by sending a REDIRECT instead of answering > the DESCRIBE. > > The alternate server MUST be indicated in the Location header. > The client (if it wants to...) SHOULD connect to the other server > and start the session with DESCRIBE. > > Example: > > > C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > M->C: REDIRECT rtsp://foo/twister RTSP/1.0 > CSeq: 1 > Location: rtsp://123.34.322.67:554/foo/twister > > So scrape this case in my opinion. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 11:12:00 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 LAA00886 for ; Thu, 26 Jun 2003 11:11:59 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFBYw01290 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 11:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYPN-0000Kj-VX for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:11:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00830 for ; Thu, 26 Jun 2003 11:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYOs-0000C0-IB; Thu, 26 Jun 2003 11:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYOQ-0008VP-8o for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 11:10:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00582; Thu, 26 Jun 2003 11:10:29 -0400 (EDT) Message-Id: <200306261510.LAA00582@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: Thu, 26 Jun 2003 11:10:29 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-04.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-04.txt Pages : 18 Date : 2003-6-26 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 with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP) and the Real-Time Streaming Protocol (RTSP) and when the involved hosts reside in networks running different IP versions, the interpretation of what lower layer bandwidths are included is not clear. This document 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 maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-04.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-04.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-04.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-6-26110652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-bwparam-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26110652.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 12:33: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 MAA07824 for ; Thu, 26 Jun 2003 12:33:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QGWZ623688 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 12:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZfn-00069z-Ds for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 12:32:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07784 for ; Thu, 26 Jun 2003 12:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZfG-00063r-BZ; Thu, 26 Jun 2003 12:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZev-00060v-Im for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 12:31:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07682 for ; Thu, 26 Jun 2003 12:31:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VZee-0003YB-00 for mmusic@ietf.org; Thu, 26 Jun 2003 12:31:24 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19VZeT-0003XK-00 for mmusic@ietf.org; Thu, 26 Jun 2003 12:31:13 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5QGUBfU011913 for ; Thu, 26 Jun 2003 09:30:11 -0700 (PDT) Received: from sun.com (vpn-129-150-19-178.SFBay.Sun.COM [129.150.19.178]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id JAA11995 for ; Thu, 26 Jun 2003 09:30:10 -0700 (PDT) Message-ID: <3EFB1F66.3070803@sun.com> Date: Thu, 26 Jun 2003 12:29:26 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Definition of a RTSP Sesison Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Hey Folks, In the process of updating the RTSP spec, I've noticed that definition of a RTSP Session needs more work. I have come up with a proposal below. Please send your comments: Current Definiton: A state established on a RTSP server by a client with a SETUP request. The RTSP session exists until it is timed out by the server or is explicitly removed by a TEARDOWN request. A session implies existence of state about the media resources that can be played and their respective transports. My Proposed Definition: A stateful abstraction upon which the main control methods of RTSP operate. A RTSP Session is established by a RTSP server upon the completion of a successful SETUP request and is labelled by a Session Identifier at that time. The session exists until timed out by the server or explicitly removed by a TEARDOWN request. A RTSP Session is a stateful entity; a RTSP server maintains an explicit session state machine (see Appendix A) where most state transitions are triggered by client requests. The existence of a session implies the existence of state about the session's media resources and their respective transports. A given session can have zero or more media resources associated with it. A RTSP server uses the session to aggregate control over multiple media resources. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 13:32: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 NAA10362 for ; Thu, 26 Jun 2003 13:32:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QHW7D05792 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 13:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VabP-0001VL-OK for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 13:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10317 for ; Thu, 26 Jun 2003 13:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VabN-00046C-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 13:32:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VabI-000469-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 13:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VabJ-0001UP-4C; Thu, 26 Jun 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaaV-0001Ow-Vd for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 13:31:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10284; Thu, 26 Jun 2003 13:30:54 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VaaE-00045h-00; Thu, 26 Jun 2003 13:30:54 -0400 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 19Vaa3-00045Y-00; Thu, 26 Jun 2003 13:30:43 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id CBF885B007; Thu, 26 Jun 2003 19:30:12 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA05699; Thu, 26 Jun 2003 19:30:12 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA03537; Thu, 26 Jun 2003 19:30:11 +0200 (MEST) Subject: Re: [MMUSIC] Definition of a RTSP Sesison To: Aravind Narasimhan Cc: mmusic@ietf.org, mmusic-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 26 Jun 2003 19:21:14 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/06/2003 19:31:14 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: , hi aravind, I like your definition, a few remarks: It could be useful (e.g. in the redicrection at DESCRIBE case) to introduce the notion that a RTSP "connection" may be "session-less" or something.... now is it obvious and do we need to define when exactly does the session start from the server point of view (it is when the Session ID is "sent" in the reply to SETUP?) and the client point of view (is it when the session ID is received?)? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: mmusic@ietf.org cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: [MMUSIC] Definition of a RTSP Sesison Aravind Narasimhan Classification: Sent by: mmusic-admin@ietf.org 26/06/2003 18:29 Hey Folks, In the process of updating the RTSP spec, I've noticed that definition of a RTSP Session needs more work. I have come up with a proposal below. Please send your comments: Current Definiton: A state established on a RTSP server by a client with a SETUP request. The RTSP session exists until it is timed out by the server or is explicitly removed by a TEARDOWN request. A session implies existence of state about the media resources that can be played and their respective transports. My Proposed Definition: A stateful abstraction upon which the main control methods of RTSP operate. A RTSP Session is established by a RTSP server upon the completion of a successful SETUP request and is labelled by a Session Identifier at that time. The session exists until timed out by the server or explicitly removed by a TEARDOWN request. A RTSP Session is a stateful entity; a RTSP server maintains an explicit session state machine (see Appendix A) where most state transitions are triggered by client requests. The existence of a session implies the existence of state about the session's media resources and their respective transports. A given session can have zero or more media resources associated with it. A RTSP server uses the session to aggregate control over multiple media resources. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 14:51:23 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 OAA14681 for ; Thu, 26 Jun 2003 14:51:23 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFaTD08728 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 11:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJw-0002Ew-9c for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:36:28 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16238 for ; Wed, 25 Jun 2003 11:36:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJR-0001sM-BM; Wed, 25 Jun 2003 11:35:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBy3-00089b-Rh for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 11:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03988 for ; Wed, 25 Jun 2003 03:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V4mE-0002aU-00 for mmusic@ietf.org; Wed, 25 Jun 2003 03:33:10 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19V4m3-0002aL-00 for mmusic@ietf.org; Wed, 25 Jun 2003 03:32:59 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA05899; Wed, 25 Jun 2003 09:32:36 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id JAA16640; Wed, 25 Jun 2003 09:31:27 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 25 Jun 2003 09:31:58 +0200 Message-ID: From: Belling Thomas To: "'Magnus Westerlund'" , Belling Thomas Cc: "'mmusic@ietf.org'" Subject: AW: [MMUSIC] RTP bandwidth for multiple media streams Date: Wed, 25 Jun 2003 09:31:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus, My answers are inline -----Urspr=FCngliche Nachricht----- Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Gesendet: Montag, 23. Juni 2003 09:27 An: Belling Thomas Cc: 'mmusic@ietf.org' Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams Hi, I would agree with the interpretation, at least when it comes to b=3DAS = as=20 it clearly specifies that this is the RTP session bandwidth. When one=20 uses a m=3D line with port/2 it becomes two RTP sessions. However I am = not=20 certain over how one should in this case interpret any of the other=20 bandwidth attributes. [Thomas] Fine, but is that 100 Percent clear from the wording of the = RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a clarification = there The available bandwidth modifiers are: CT RR RS Lets look at them: CT is defined in draft-ietf-mmusic-sdp-new-12 as: CT Conference Total If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=3DCT:..." line should be supplied for the session = giving the proposed upper limit to the bandwidth used. The = primary purpose of this is to give an approximate idea as to = whether two or more sessions can co-exist simultaneously. Based on this I would interpret that a given CT value should be for the = complete media, i.e. counting the total of both RTP sessions. [Thomas] I agree that this is an interpretation in line with my = understanding of the intentions of the CT bandwidth modifier. However, = the wording is not so clear. What is a "session"? If you understand = "RTP session", this would contradict your interpretation. As an aside: = 3GPP ignores this parameter, so from that perspective a clarification = is less urgent than for the AS modifier. When it comes to RR and RS I think they can also be interpreted on a = per=20 RTP session level. I base this on the fundamental definition of these=20 attributes. From draft-ietf-avt-rtcp-bw-05: This memo defines two additional bandwidth modifiers: b=3DRS: b=3DRR: where "RS" indicates the RTCP bandwidth allocated to active data = senders (as defined by the RTP spec) and "RR" indicates the RTCP bandwidth allocated to other participants in the RTP session (i.e., receivers). [Thomas] Agreement, those parameters are closely linked to the = algothimns to control the RTCP bandwidth and thus make sense only for a = single RTP session. When it concerns TIAS I will do the same interpretation that the=20 bandwidth value apply per RTP session. [Thomas] Makes sense if you take TIAS as a kind of refinement of the AS = modifier. I did not yet read the draft with that question in mind, and = the draft is still in a stage where this can be clarified. My concern is that this simplistic model is probably not what you would = like if you would actually use this functionality. If one uses multiple = RTP sessions for a single media you are probably doing some form of=20 scalability, etc., and would like to specify the values independently=20 per RTP session. Fortunately there exist today alternatives to achieve=20 this behaviour today. With the help of grouping of media lines it is=20 possible to specify that several m=3D lines are part of the same media. = Using FID there is only a pitfall with the following sentence: "A media agent handling a media flow that comprises several "m" lines MUST send a copy of the media to every "m" line part of the flow as long as the codecs and the direction attribute present in a particular "m" line allow it." If that is a problem it might be easier to define a new grouping=20 attribute for that situation. Finally I have a question to the group, has anyone seen that "m=3D = port/2 ..." ever been used. And in that case how. [Thomas] Take the simple example of stereo sound. Why not use the "m=3D = port/2 " notification for that? Something in that direction might have = been the original motification. From a 3GPP perspective, where this = relates to thev bandwidth on the air and possibly the rate charged for = a service, we should have a clear understanding as this possibility = exists and might also be misused otherwise. Best Regards Magnus Belling Thomas wrote: >>c=3DIN IP4 224.2.1.1/127/2 >>m=3Dvideo 49170/2 RTP/AVP 31=20 >>b=3DAS:64 >> >>My problem: How much bandwidth is associated with this "m=3D" line - >>64kbits or 128kbits? >> --=20 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@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 14:52: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 OAA14736 for ; Thu, 26 Jun 2003 14:52:23 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFaOP08554 for mmusic-archive@odin.ietf.org; Wed, 25 Jun 2003 11:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJs-0002Dh-2m for mmusic-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:36:24 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16194 for ; Wed, 25 Jun 2003 11:36:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJM-0001nv-Qn; Wed, 25 Jun 2003 11:35:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxo-00089b-5t for mmusic@optimus.ietf.org; Wed, 25 Jun 2003 11:13:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04206 for ; Wed, 25 Jun 2003 03:56:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V58t-0002fJ-00 for mmusic@ietf.org; Wed, 25 Jun 2003 03:56:35 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19V58i-0002f2-00 for mmusic@ietf.org; Wed, 25 Jun 2003 03:56:25 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5P7t1w2028010; Wed, 25 Jun 2003 09:55:01 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NSLD40Z5; Wed, 25 Jun 2003 09:55:03 +0200 Message-ID: <3EF95489.6050406@ericsson.com> Date: Wed, 25 Jun 2003 09:51:37 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Belling Thomas CC: "'mmusic@ietf.org'" Subject: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Thomas, Even more inline: Belling Thomas wrote: > Hi Magnus, >=20 > My answers are inline >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Gesendet: Montag, 23. Juni 2003 09:27 > An: Belling Thomas > Cc: 'mmusic@ietf.org' > Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams >=20 >=20 > Hi, >=20 > I would agree with the interpretation, at least when it comes to b=3DAS= as=20 > it clearly specifies that this is the RTP session bandwidth. When one=20 > uses a m=3D line with port/2 it becomes two RTP sessions. However I am = not=20 > certain over how one should in this case interpret any of the other=20 > bandwidth attributes. >=20 > [Thomas] Fine, but is that 100 Percent clear from the wording of the RF= Cs and draft-ietf-mmusic-sdp-new-12? It would prefere a clarification the= re Yes, this should probably be clarified. I don't think it is obvious. >=20 > The available bandwidth modifiers are: > CT > RR > RS >=20 > Lets look at them: >=20 > CT is defined in draft-ietf-mmusic-sdp-new-12 as: > CT Conference Total > If the bandwidth of a session or media in a session is > different from the bandwidth implicit from the scope, a > "b=3DCT:..." line should be supplied for the session givin= g > the proposed upper limit to the bandwidth used. The prima= ry > purpose of this is to give an approximate idea as to wheth= er > two or more sessions can co-exist simultaneously. >=20 > Based on this I would interpret that a given CT value should be for the= =20 > complete media, i.e. counting the total of both RTP sessions. >=20 > [Thomas] I agree that this is an interpretation in line with my underst= anding of the intentions of the CT bandwidth modifier. However, the wordi= ng is not so clear. What is a "session"? If you understand "RTP session",= this would contradict your interpretation. As an aside: 3GPP ignores thi= s parameter, so from that perspective a clarification is less urgent than= for the AS modifier. Yes, the session in the quote is a bit unclear. I think it is a larger=20 session concept, like the complete streaming session, or probably when=20 it was written the conferencing session with all the media included. On=20 media level the text indicates the complete media, which in this case is = transported over several RTP sessions. So based on these two=20 interpretations I arrive at my conclusion. > When it concerns TIAS I will do the same interpretation that the=20 > bandwidth value apply per RTP session. >=20 > [Thomas] Makes sense if you take TIAS as a kind of refinement of the AS= modifier. I did not yet read the draft with that question in mind, and t= he draft is still in a stage where this can be clarified. Yes, it can still be modified. I have made an update and I did not=20 address the issue. The reason being is that I think the SDP draft should = first address this. Based on this clarification I would add to the=20 TIAS draft if necessary. >=20 > My concern is that this simplistic model is probably not what you would= =20 > like if you would actually use this functionality. If one uses multiple= =20 > RTP sessions for a single media you are probably doing some form of=20 > scalability, etc., and would like to specify the values independently=20 > per RTP session. Fortunately there exist today alternatives to achieve = > this behaviour today. With the help of grouping of media lines it is=20 > possible to specify that several m=3D lines are part of the same media.= =20 > Using FID there is only a pitfall with the following sentence: > "A media agent handling a media flow that comprises several "m" > lines MUST send a copy of the media to every "m" line part of the > flow as long as the codecs and the direction attribute present in a= > particular "m" line allow it." >=20 > If that is a problem it might be easier to define a new grouping=20 > attribute for that situation. > Finally I have a question to the group, has anyone seen that "m=3D port= /2=20 > ..." ever been used. And in that case how. >=20 > [Thomas] Take the simple example of stereo sound. Why not use the "m=3D= port/2 " notification for that? Something in that direction might have b= een the original motification. From a 3GPP perspective, where this relate= s to thev bandwidth on the air and possibly the rate charged for a servic= e, we should have a clear understanding as this possibility exists and mi= ght also be misused otherwise. I don't think stereo is a good example. First reason is that you=20 normally don't split left and right channel into different packets,=20 unless they are really big, reasons are like synchronization. Therefore=20 most audio codecs are possible to transport over RTP using a single=20 source. The sample based codec normally only specify that every other=20 sample is left and the other are right. Frame based codec normally have = more advanced schemes where they encode left and right together to take=20 advantage of the similarities between channels. My thinking is actually along the lines, if no one uses it, why not=20 remove it, we will still have to if no implementations are identified=20 when going to draft standard. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jun 26 20:10:39 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 UAA28181 for ; Thu, 26 Jun 2003 20:10:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R0ABB04503 for mmusic-archive@odin.ietf.org; Thu, 26 Jun 2003 20:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vgod-0001AY-0Y for mmusic-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 20:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28167 for ; Thu, 26 Jun 2003 20:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vgob-0007KK-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 20:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VgoV-0007KH-00 for mmusic-web-archive@ietf.org; Thu, 26 Jun 2003 20:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgoT-0001A0-TM; Thu, 26 Jun 2003 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vgo9-00019U-H1 for mmusic@optimus.ietf.org; Thu, 26 Jun 2003 20:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28154 for ; Thu, 26 Jun 2003 20:09:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vgns-0007K8-00 for mmusic@ietf.org; Thu, 26 Jun 2003 20:09:24 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19VgnX-0007Ji-00 for mmusic@ietf.org; Thu, 26 Jun 2003 20:09:03 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h5R0832B070614; Thu, 26 Jun 2003 17:08:03 -0700 (PDT) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 17:08:03 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7BD5@MISTY> From: Thomas Zeng To: "'Aravind Narasimhan'" , mmusic@ietf.org Subject: RE: [MMUSIC] Definition of a RTSP Sesison Date: Thu, 26 Jun 2003 17:07:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Aravind: In your proposal, you have: "The existence of a session implies the existence of state about the session's media resources and their respective transports." It is not clear to me what are media resources and their transports -- transport could mean different things, either IP port resource or the dynamic action of moving information from A to B. Wouldn't it be more accurate to say: "The existence of a session implies the existence of state about the session's media control and media transport mechanism." Just a suggestion, - thomas -----Original Message----- From: Aravind Narasimhan [mailto:aravind.narasimhan@sun.com] Sent: Thursday, June 26, 2003 9:29 AM To: mmusic@ietf.org Subject: [MMUSIC] Definition of a RTSP Sesison Hey Folks, In the process of updating the RTSP spec, I've noticed that definition of a RTSP Session needs more work. I have come up with a proposal below. Please send your comments: Current Definiton: A state established on a RTSP server by a client with a SETUP request. The RTSP session exists until it is timed out by the server or is explicitly removed by a TEARDOWN request. A session implies existence of state about the media resources that can be played and their respective transports. My Proposed Definition: A stateful abstraction upon which the main control methods of RTSP operate. A RTSP Session is established by a RTSP server upon the completion of a successful SETUP request and is labelled by a Session Identifier at that time. The session exists until timed out by the server or explicitly removed by a TEARDOWN request. A RTSP Session is a stateful entity; a RTSP server maintains an explicit session state machine (see Appendix A) where most state transitions are triggered by client requests. The existence of a session implies the existence of state about the session's media resources and their respective transports. A given session can have zero or more media resources associated with it. A RTSP server uses the session to aggregate control over multiple media resources. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jun 29 16:33: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 QAA07189 for ; Sun, 29 Jun 2003 16:33:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5TKX4K20028 for mmusic-archive@odin.ietf.org; Sun, 29 Jun 2003 16:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WirA-0005Cx-OI for mmusic-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 16:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07171 for ; Sun, 29 Jun 2003 16:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WiqL-0005N9-00 for mmusic-web-archive@ietf.org; Sun, 29 Jun 2003 16:32:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WiqG-0005N3-00 for mmusic-web-archive@ietf.org; Sun, 29 Jun 2003 16:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wiq9-00056y-8K; Sun, 29 Jun 2003 16:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wipc-00056V-0V for mmusic@optimus.ietf.org; Sun, 29 Jun 2003 16:31:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07165 for ; Sun, 29 Jun 2003 16:31:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wipa-0005MP-00 for mmusic@ietf.org; Sun, 29 Jun 2003 16:31:26 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19WipP-0005Lj-00 for mmusic@ietf.org; Sun, 29 Jun 2003 16:31:15 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5TKUPfU001512; Sun, 29 Jun 2003 13:30:25 -0700 (PDT) Received: from sun.com (vpn-129-150-16-16.SFBay.Sun.COM [129.150.16.16]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id NAA18030; Sun, 29 Jun 2003 13:30:24 -0700 (PDT) Message-ID: <3EFE5A92.4040106@sun.com> Date: Sat, 28 Jun 2003 23:18:42 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Definition of a RTSP Sesison References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit philippe.gentric@philips.com wrote: >hi aravind, > >I like your definition, a few remarks: > >It could be useful (e.g. in the redicrection at DESCRIBE case) to introduce the >notion that a RTSP "connection" may be "session-less" or something.... > I'd rather not introduce the notion of an RTSP "connection", because I think it muddles the picture. The whole point of RTSP is that it is independent of Transport level connections and that it mainly operates on a RTSP Session. Now, if I understand it right, the spirit of your comment is really just to explicitly clarify that there are RTSP methods that do not act on a RTSP session, but rather on underlying media resources or presentation resources. I'll see if I can work it in to the defintion, though it is mentioned elsewhere in the spec, namely section 1.8 on RTSP States. >now is it obvious and do we need to define >when exactly does the session start from the server point of view >(it is when the Session ID is "sent" in the reply to SETUP?) > Yes. This is useful to establish as it clarifies the protocol >and the client point of view (is it when the session ID is received?)? > > A RTSP session is a server entity. It is created, maintained and destroyed by the server. A client is a slave to the server for any session properties, information and state. So from the client point of view a session is really only valid at the instant when a response is received, as the server may go down or decide to time out the session etc. While it is important to clarify this, we need to make sure that there is one unified view of a session and that is the view maintained by the server. I'll see if I can work this in too, but now it's getting complex. We may want to create a new section just to talk about the session and keep the defintion in the glossary section small. Aravind >regards, > >Philippe Gentric >Software Architect >Philips MP4Net >philippe.gentric@philips.com >http://www.platform4.philips.com > > > > > To: mmusic@ietf.org > cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) > Subject: [MMUSIC] Definition of a RTSP Sesison > > Aravind Narasimhan Classification: > com> > > Sent by: > mmusic-admin@ietf.org > > 26/06/2003 18:29 > > > > > > >Hey Folks, > In the process of updating the RTSP spec, I've noticed that >definition of a RTSP Session needs more work. I have come up with a >proposal below. Please send your comments: > >Current Definiton: > >A state established on a RTSP server by a client with a SETUP request. >The RTSP session exists until it is timed out by the server or is >explicitly removed by a TEARDOWN request. A session implies existence of >state about the media resources that can be played and their respective >transports. > >My Proposed Definition: > >A stateful abstraction upon which the main control methods of RTSP >operate. A RTSP Session is established by a RTSP server upon the >completion of a successful SETUP request and is labelled by a Session >Identifier at that time. The session exists until timed out by the >server or explicitly removed by a TEARDOWN request. A RTSP Session is a >stateful entity; a RTSP server maintains an explicit session state >machine (see Appendix A) where most state transitions are triggered by >client requests. The existence of a session implies the existence of >state about the session's media resources and their respective >transports. A given session can have zero or more media resources >associated with it. A RTSP server uses the session to aggregate control >over multiple media resources. > > >Aravind > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jun 29 20:32: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 UAA11708 for ; Sun, 29 Jun 2003 20:32:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U0WEQ18734 for mmusic-archive@odin.ietf.org; Sun, 29 Jun 2003 20:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wmac-0004s5-Ey for mmusic-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 20:32:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11701 for ; Sun, 29 Jun 2003 20:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wmaa-0000iL-00 for mmusic-web-archive@ietf.org; Sun, 29 Jun 2003 20:32:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WmaU-0000iI-00 for mmusic-web-archive@ietf.org; Sun, 29 Jun 2003 20:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WmaP-0004rh-Uw; Sun, 29 Jun 2003 20:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WmZq-0004r9-IM for mmusic@optimus.ietf.org; Sun, 29 Jun 2003 20:31:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11689 for ; Sun, 29 Jun 2003 20:31:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WmZZ-0000h1-00 for mmusic@ietf.org; Sun, 29 Jun 2003 20:31:09 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19WmZO-0000gY-00 for mmusic@ietf.org; Sun, 29 Jun 2003 20:30:58 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5U0UW1J028364 for ; Sun, 29 Jun 2003 18:30:32 -0600 (MDT) Received: from sun.com (vpn-129-150-16-201.SFBay.Sun.COM [129.150.16.201]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id RAA05704 for ; Sun, 29 Jun 2003 17:30:31 -0700 (PDT) Message-ID: <3EFF7BA2.5070705@sun.com> Date: Sun, 29 Jun 2003 19:52:02 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Aggregate Control URI Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Hey Folks, More spec clarifications: This time with regards to the definition and specification of Aggregate control URI. Section 1.4 Old Wording: Aggregate control URI: The URI that represents the whole aggregate. Normally specified in the session description. Proposed New Wording: Aggregate control URI: The URI used in a RTSP request to refer to and control an aggregated session. It normally, but not always, corresponds to the presentation URI specified in the session description. See Section 11.3 for more information. Also added the following to Section 11.3, SETUP Method: An Aggregate control URI MUST be used to control an aggregated session. This URI MUST be different from the stream control URIs of the individual media streams included in the aggregate. The Aggregate control URI SHOULD be specified by the session description since there is no general rule for deriving it from the various stream control URIs in the session. If an Aggregate control URI is not specified in the session description, a client MUST create an URI for aggregate control of the session. This URI MUST contain the servers host address and MUST contain the port, if applicable. Once an URI is used to refer to an aggregation for a given session, that URI MUST be used to refer to that aggregation for the duration of the session. If the contents of the aggregation change, then a different aggregate control URI SHOULD be used. While the session ID has enough information for aggregate control of a session, the Aggregate control URI is still important for some methods such as SET PARAMETER where the control URI enables the resource in question to be easily identified. The Aggregate control URI is also useful for proxies, enabling them to route the request to the appropriate server, and for logging, where it is useful to note the actual resource that a request was operating on. Finally, presence of the Aggregate control URI allows for backwards compatibility with RFC 2326 [21]. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jun 29 21:02:36 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 VAA12192 for ; Sun, 29 Jun 2003 21:02:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U127Q23633 for mmusic-archive@odin.ietf.org; Sun, 29 Jun 2003 21:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wn3X-000696-RA for mmusic-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 21:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12184 for ; Sun, 29 Jun 2003 21:02:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wn3V-0001AG-00 for mmusic-web-archive@ietf.org; Sun, 29 Jun 2003 21:02:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wn3P-0001AD-00 for mmusic-web-archive@ietf.org; Sun, 29 Jun 2003 21:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wn3R-00067S-CK; Sun, 29 Jun 2003 21:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wn2V-00066w-PG for mmusic@optimus.ietf.org; Sun, 29 Jun 2003 21:01:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12175 for ; Sun, 29 Jun 2003 21:01:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wn2T-00019G-00 for mmusic@ietf.org; Sun, 29 Jun 2003 21:01:01 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19Wn2I-000199-00 for mmusic@ietf.org; Sun, 29 Jun 2003 21:00:50 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5U10f1J007493; Sun, 29 Jun 2003 19:00:41 -0600 (MDT) Received: from sun.com (vpn-129-150-16-201.SFBay.Sun.COM [129.150.16.201]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id SAA08215; Sun, 29 Jun 2003 18:00:40 -0700 (PDT) Message-ID: <3EFF8B8D.1070302@sun.com> Date: Sun, 29 Jun 2003 20:59:57 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: mmusic@ietf.org Subject: Re: [MMUSIC] Definition of a RTSP Sesison References: <72263E8E8622D611975C0002B32C19D84A7BD5@MISTY> In-Reply-To: <72263E8E8622D611975C0002B32C19D84A7BD5@MISTY> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Incorporating Philippe's and your comments, I have come up with the following wording: RTSP session: A stateful abstraction upon which the main control methods of RTSP operate. A RTSP session is a server entity; it is created, maintained and destroyed by the server. It is established by a RTSP server upon the completion of a successful SETUP request (when 200 OK response is sent) and is labelled by a session identifier at that time. The session exists until timed out by the server or explicitly removed by a TEARDOWN request. A RTSP session is also a stateful entity; a RTSP server maintains an explicit session state machine (see Appendix A) where most state transitions are triggered by client requests. The existence of a session implies the existence of state about the session's media streams and their respective transport mechanisms. A given session can have zero or more media streams associated with it. A RTSP server uses the session to aggregate control over multiple media streams. I'll add this in the spec for now, but in the future, it may make sense to add a subsection in section 1 to describe an RTSP Session in more detail. Aravind Thomas Zeng wrote: >Aravind: > >In your proposal, you have: > >"The existence of a session implies the existence of >state about the session's media resources and their respective >transports." > >It is not clear to me what are media resources and their transports -- >transport could mean different things, either IP port resource or the >dynamic action of moving information from A to B. > >Wouldn't it be more accurate to say: > >"The existence of a session implies the existence of >state about the session's media control and media transport mechanism." > >Just a suggestion, >- thomas > >-----Original Message----- >From: Aravind Narasimhan [mailto:aravind.narasimhan@sun.com] >Sent: Thursday, June 26, 2003 9:29 AM >To: mmusic@ietf.org >Subject: [MMUSIC] Definition of a RTSP Sesison > > >Hey Folks, > In the process of updating the RTSP spec, I've noticed that >definition of a RTSP Session needs more work. I have come up with a >proposal below. Please send your comments: > >Current Definiton: > >A state established on a RTSP server by a client with a SETUP request. >The RTSP session exists until it is timed out by the server or is >explicitly removed by a TEARDOWN request. A session implies existence of >state about the media resources that can be played and their respective >transports. > >My Proposed Definition: > >A stateful abstraction upon which the main control methods of RTSP >operate. A RTSP Session is established by a RTSP server upon the >completion of a successful SETUP request and is labelled by a Session >Identifier at that time. The session exists until timed out by the >server or explicitly removed by a TEARDOWN request. A RTSP Session is a >stateful entity; a RTSP server maintains an explicit session state >machine (see Appendix A) where most state transitions are triggered by >client requests. The existence of a session implies the existence of >state about the session's media resources and their respective >transports. A given session can have zero or more media resources >associated with it. A RTSP server uses the session to aggregate control >over multiple media resources. > > >Aravind > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jun 30 12:51: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 MAA05795 for ; Mon, 30 Jun 2003 12:51:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UGp8E12220 for mmusic-archive@odin.ietf.org; Mon, 30 Jun 2003 12:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1rw-0003B1-0f for mmusic-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 12:51:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05774 for ; Mon, 30 Jun 2003 12:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X1rt-0002eY-00 for mmusic-web-archive@ietf.org; Mon, 30 Jun 2003 12:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X1ro-0002eV-00 for mmusic-web-archive@ietf.org; Mon, 30 Jun 2003 12:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1rp-0003Ad-MP; Mon, 30 Jun 2003 12:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1rn-0003AI-24 for mmusic@optimus.ietf.org; Mon, 30 Jun 2003 12:50:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05726 for ; Mon, 30 Jun 2003 12:50:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X1rV-0002eD-00 for mmusic@ietf.org; Mon, 30 Jun 2003 12:50:41 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19X1rK-0002cl-00 for mmusic@ietf.org; Mon, 30 Jun 2003 12:50:31 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Mon, 30 Jun 2003 09:48:58 -0700 Date: Mon, 30 Jun 2003 09:55:02 -0700 (PDT) From: Aaron Colwell To: Aravind Narasimhan cc: mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI In-Reply-To: <3EFF7BA2.5070705@sun.com> Message-ID: References: <3EFF7BA2.5070705@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments inline On Sun, 29 Jun 2003, Aravind Narasimhan wrote: > Hey Folks, > > More spec clarifications: This time with regards to the definition and > specification of Aggregate control URI. > > Section 1.4 > Old Wording: > Aggregate control URI: The URI that represents the whole aggregate. > Normally specified in the session description. > > Proposed New Wording: > Aggregate control URI: The URI used in a RTSP request to refer to and > control an aggregated session. It normally, but not always, corresponds > to the presentation URI specified in the session description. See > Section 11.3 for more information. > > > Also added the following to Section 11.3, SETUP Method: > > An Aggregate control URI MUST be used to control an aggregated session. > This URI MUST be different from the stream control URIs of the > individual media streams included in the aggregate. The Aggregate > control URI SHOULD be specified by the session description since there > is no general rule for deriving it from the various stream control URIs > in the session. If an Aggregate control URI is not specified in the > session description, a client MUST create an URI for aggregate control > of the session. This URI MUST contain the servers host address and MUST > contain the port, if applicable. Once an URI is used to refer to an > aggregation for a given session, that URI MUST be used to refer to that > aggregation for the duration of the session. If the contents of the > aggregation change, then a different aggregate control URI SHOULD be used. I'm a little confused about why the client MUST create a aggregate control URI if one does not exist in the content description. I thought the presence of the session level control URI was what signalled whether aggregate control was supported by the server for this piece of content. If this field is not present, I thought the client was to assume that aggregate control was not supported and just control the stream seperately. Is this not the case? It seems to me that the server is the one that know whether it supports aggregate control and should be the one that dictates what the aggregate control URL should be. I don't think that the server should have to deal with something that the client just made up on its own. Aaron > > While the session ID has enough information for aggregate control of a > session, the Aggregate control URI is still important for some methods > such as SET PARAMETER where the control URI enables the resource in > question to be easily identified. The Aggregate control URI is also > useful for proxies, enabling them to route the request to the > appropriate server, and for logging, where it is useful to note the > actual resource that a request was > operating on. Finally, presence of the Aggregate control URI allows for > backwards compatibility with RFC 2326 [21]. > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jun 30 13:43: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 NAA07957 for ; Mon, 30 Jun 2003 13:43:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UHh8323262 for mmusic-archive@odin.ietf.org; Mon, 30 Jun 2003 13:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2gG-000637-QQ for mmusic-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 13:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07927 for ; Mon, 30 Jun 2003 13:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X2gE-00033T-00 for mmusic-web-archive@ietf.org; Mon, 30 Jun 2003 13:43:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X2g8-00033Q-00 for mmusic-web-archive@ietf.org; Mon, 30 Jun 2003 13:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2g9-00062j-DZ; Mon, 30 Jun 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2fz-00062Y-8s for mmusic@optimus.ietf.org; Mon, 30 Jun 2003 13:42:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07918 for ; Mon, 30 Jun 2003 13:42:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X2fw-000339-00 for mmusic@ietf.org; Mon, 30 Jun 2003 13:42:48 -0400 Received: from tog-wakko5.prognet.com ([207.188.29.245] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19X2fl-00032v-00 for mmusic@ietf.org; Mon, 30 Jun 2003 13:42:37 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19X2f5-0006en-00; Mon, 30 Jun 2003 10:41:55 -0700 Date: Mon, 30 Jun 2003 10:41:55 -0700 From: Tom Marshall To: Aaron Colwell Cc: Aravind Narasimhan , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI Message-ID: <20030630174155.GC25404@real.com> References: <3EFF7BA2.5070705@sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > An Aggregate control URI MUST be used to control an aggregated session. > > This URI MUST be different from the stream control URIs of the > > individual media streams included in the aggregate. The Aggregate > > control URI SHOULD be specified by the session description since there > > is no general rule for deriving it from the various stream control URIs > > in the session. If an Aggregate control URI is not specified in the > > session description, a client MUST create an URI for aggregate control > > of the session. This URI MUST contain the servers host address and MUST > > contain the port, if applicable. Once an URI is used to refer to an > > aggregation for a given session, that URI MUST be used to refer to that > > aggregation for the duration of the session. If the contents of the > > aggregation change, then a different aggregate control URI SHOULD be us= ed. >=20 > I'm a little confused about why the client MUST create a aggregate control > URI if one does not exist in the content description. I thought the > presence of the session level control URI was what signalled whether > aggregate control was supported by the server for this piece of content. > If this field is not present, I thought the client was to assume that > aggregate control was not supported and just control the stream > seperately. Is this not the case? It seems to me that the server is the > one that know whether it supports aggregate control and should be the one > that dictates what the aggregate control URL should be. I don't think that > the server should have to deal with something that the client just made up > on its own. Suppose a client wishes to play audio from one file and video from another with an aggregated session. There is no real aggregate control url to use.= =20 The server should be watching for each of the stream urls to determine whether non-aggregate control is in use. In a separate conversation, it was agreed that the Session header is to take precedence over the url in the request in case they don't match. Therefore, in the absence of an obvious aggregate control url, a reasonable fallback is rtsp://host:port/. It will work through proxies and it will not conflict with the stream urls. This is admittedly a corner case. I am not aware of any real world scenarios where it would happen. Magnus filed the bug [1] so he may have a real world scenario in mind. It is obviously preferable to use an aggregate url but we should probably define behavior in case it is not present. [1] http://rtsp.org/bug640272 --=20 Harrison's Postulate: For every action, there is an equal and opposite criticism. --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/AHZjqznSmcYu2m8RAnEiAJ9BEe70Lb3dFJoyMbvZCcA1UQdpxwCfSGGO gDJXWIOf0GtMQiThw9Jr19Y= =0dzM -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jun 30 14:02: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 OAA08819 for ; Mon, 30 Jun 2003 14:02:59 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UI2VX26946 for mmusic-archive@odin.ietf.org; Mon, 30 Jun 2003 14:02:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2z1-00070X-O9 for mmusic-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 14:02:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08786 for ; Mon, 30 Jun 2003 14:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2yW-0006x4-TM; Mon, 30 Jun 2003 14:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2yG-0006wl-63 for mmusic@optimus.ietf.org; Mon, 30 Jun 2003 14:01:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08760 for ; Mon, 30 Jun 2003 14:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X2yD-0003B0-00 for mmusic@ietf.org; Mon, 30 Jun 2003 14:01:41 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19X2y2-0003AT-00 for mmusic@ietf.org; Mon, 30 Jun 2003 14:01:30 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Mon, 30 Jun 2003 11:00:21 -0700 Date: Mon, 30 Jun 2003 11:06:26 -0700 (PDT) From: Aaron Colwell To: Tom Marshall cc: Aravind Narasimhan , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI In-Reply-To: <20030630174155.GC25404@real.com> Message-ID: References: <3EFF7BA2.5070705@sun.com> <20030630174155.GC25404@real.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Makes sense to me. I guess I hadn't thought of that case. Aaron On Mon, 30 Jun 2003, Tom Marshall wrote: > > Suppose a client wishes to play audio from one file and video from another > with an aggregated session. There is no real aggregate control url to use. > The server should be watching for each of the stream urls to determine > whether non-aggregate control is in use. In a separate conversation, it was > agreed that the Session header is to take precedence over the url in the > request in case they don't match. Therefore, in the absence of an obvious > aggregate control url, a reasonable fallback is rtsp://host:port/. It will > work through proxies and it will not conflict with the stream urls. > > This is admittedly a corner case. I am not aware of any real world > scenarios where it would happen. Magnus filed the bug [1] so he may have a > real world scenario in mind. It is obviously preferable to use an aggregate > url but we should probably define behavior in case it is not present. > > [1] http://rtsp.org/bug640272 > > -- > Harrison's Postulate: > For every action, there is an equal and opposite criticism. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic