From mailnull@www1.ietf.org Mon Mar 3 04:13:47 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 EAA12517 for ; Mon, 3 Mar 2003 04:13:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h239Ngn26768 for mmusic-archive@odin.ietf.org; Mon, 3 Mar 2003 04:23:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h239Ngp26765 for ; Mon, 3 Mar 2003 04:23:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12510 for ; Mon, 3 Mar 2003 04:13:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h239NWp26751; Mon, 3 Mar 2003 04:23:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h239MIp26689 for ; Mon, 3 Mar 2003 04:22:18 -0500 Received: from condor.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12473 for ; Mon, 3 Mar 2003 04:11:51 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by condor.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h239DqA1026626; Mon, 3 Mar 2003 10:13:52 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD42J06Q; Mon, 3 Mar 2003 10:13:52 +0100 Message-ID: <3E631CD0.9000000@era.ericsson.se> Date: Mon, 03 Mar 2003 10:13:52 +0100 X-Sybari-Trust: 1d2d9597 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt References: <72263E8E8622D611975C0002B32C19D84A7858@MISTY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thomas, Comments below: Thomas Zeng wrote: >Magnus: > >I have a comment on 3.2 Symetric RTP. > >As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server >normally uses a single RTP port (let's call it X) to send RTP packets to >many (potentially hundreds) of clients. Now Symetric RTP asks these clients >to send an RTP packet with their individual client SSRC in the payload to >this port X on the server host. Since each client randomly generates client >SSRC, there is some chance (as high as 10^-4 according to RFC1889, section >8.1) that two clients may end up with same SSRC, in which case the server >may send RTP packets to wrong clients. I did study the SSRC collision >detection scheme in RFC1889 and found it irrelevant because it only applies >to multicast RTP sessions. I don't think destination IP can help here since >prior to the establishment of binding our server doesn't know clients >public IPs. Besides, the two collided clients may well be behind the same >NAT and hence probably share public IP. > > My first comment is that the easiest way of solving this problem, is for the server to send from different ports for each client. That way you reduce the probability of collisions and ensures maximum security in respect to hijacking. >I hereby suggest that the binding RTPs to add, in a fashion defined below, >client's RTSP sessionID in addition to client's SSRC in those binding RTP >packets. Notice RTSP sessionIDs are generated by the server and hence can be >made unique amongst all clients of that server. > >The session ID happens to provide other niceties: > >1. One client only has to make sure that its client SSRCs are unique amongst >the RTP tracks it has in the session (if it happens to have more than one >track) >2. Since RTSP session ID can be 64 bytes or longer, it offers added >protection against stream hijacking or brute force attacks (since now the >hijacker/attacker must guess not only SSRC, but also SessionID). > >Careful thinking revealed to me that the fundamental problem here is that >prior to the establishment of port mapping, there is no way for the server >to determine RTP session using the traditional source and destination (IP, >port-pair) as defined in RFC1889 section 3. Unfortunately, it means that >what I said about RTP port mapping is also true to RTCP port mapping. > >Assuming you readers are with me so far, I then propose that the binding RTP >packets include SessionID in the following fashion: > >1. Do NOT use PT=0, instead, use a dedicated PT for binding purposes (we >probably need to reserve one). >2. The only payload in this RTP is the session ID. >3. This payload type shall be used for the binding packets the client send >to sender's RTCP send port as well (in lieu of the normal RTCP packets in >Magnus draft, section 3.2.3, page 8). > > I can agree that a new payload for RTP would allow a server to save it from the need to perform real port multiplexing between its clients. However I don't see a need for solution only to this problem. If we would be design a new RTP payload format then we should make this for the general security problems related to RTSP. 1. Provide improved security for symmetric RTP by allowing for longer random tags. 2. Allow for a RTP/RTCP based challenge mechanism that can be used to ensure that a receiver accepts the data traffic, i.e. solve the destination security problem. Such a solution should consider the following problems: - Be usable for both RTP and RTCP. - Allow for dynamic tag length. - Be possible to authenticate in respect to both sender and receiver. - Have room for response codes. > >Interestingly, there is another way to deal with client SSRC collision: >rejecting the SETUP request containing a client SSRC already registered. >But that breaks backwards compatibility in that current clients don't know >to change SSRC and resend SETUP request. Besides, the nice security feature >of sessionID is gone. > > This seem to be a bad idea. It creates backwards compatibility issues where other solutions exist. >Hence I prefer the inclusion of SessionID. > > I prefer the solution that the servers take responsibility and actually use multiple ports. In the long run we could define a general challenge mechanism. This mechanism can then in the future be used to ensure better security in several ways. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 3 06:51: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 GAA18893 for ; Mon, 3 Mar 2003 06:51:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23C1Gi08967 for mmusic-archive@odin.ietf.org; Mon, 3 Mar 2003 07:01:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23C1Gp08964 for ; Mon, 3 Mar 2003 07:01:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18871 for ; Mon, 3 Mar 2003 06:50:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23C1Ap08945; Mon, 3 Mar 2003 07:01:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Bwtp08715 for ; Mon, 3 Mar 2003 06:58:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18699; Mon, 3 Mar 2003 06:48:28 -0500 (EST) Message-Id: <200303031148.GAA18699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 03 Mar 2003 06:48:27 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP Security Descriptions for Media Streams Author(s) : M. Baugher, D. Wing Filename : draft-ietf-mmusic-sdescriptions-00.txt Pages : 21 Date : 2003-2-28 This Internet Draft gives a cryptographic attribute to Session Description Protocol (SDP) media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This draft also defines the SRTP parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdescriptions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28125516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 3 08:38: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 IAA24883 for ; Mon, 3 Mar 2003 08:38:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23DmMr17899 for mmusic-archive@odin.ietf.org; Mon, 3 Mar 2003 08:48:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DmMp17896 for ; Mon, 3 Mar 2003 08:48:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24879 for ; Mon, 3 Mar 2003 08:37:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DmBp17879; Mon, 3 Mar 2003 08:48:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Dl7p17841 for ; Mon, 3 Mar 2003 08:47:07 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24860 for ; Mon, 3 Mar 2003 08:36:36 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h23DYM021641; Mon, 3 Mar 2003 08:34:23 -0500 Message-Id: <5.1.1.6.0.20030303083322.035e5720@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 03 Mar 2003 08:38:31 -0500 To: mmusic@ietf.org From: David Yon Cc: Joerg Ott , Colin Perkins , Jonathan Rosenberg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] draft-ietf-mmusic-sdp-comedia-05.txt available Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 submitted draft-ietf-mmusic-sdp-comedia-05.txt to the IETF in prep for the 56th meeting. A draft copy is available now from: http://www.rfdsoftware.com/ietf/draft-ietf-mmusic-sdp-comedia-05.txt I have removed all references to the source address and the firewall-related security considerations. What I did not have time to do is incorporate the security issues raised by comedia-fix, but I think those are worthy of at least a brief discussion at the 56th. Please look over the draft and let me know whether there are any remaining concerns. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 3 12:51: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 MAA04873 for ; Mon, 3 Mar 2003 12:51:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23I1YI09222 for mmusic-archive@odin.ietf.org; Mon, 3 Mar 2003 13:01:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23I1Yp09219 for ; Mon, 3 Mar 2003 13:01:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04830 for ; Mon, 3 Mar 2003 12:50:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23I1Tp09210; Mon, 3 Mar 2003 13:01:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23I0fp09135 for ; Mon, 3 Mar 2003 13:00:41 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04814 for ; Mon, 3 Mar 2003 12:50:06 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18pu6e-0007Fe-00; Mon, 03 Mar 2003 09:52:04 -0800 Date: Mon, 3 Mar 2003 09:52:04 -0800 From: Tom Marshall To: Magnus Westerlund Cc: Thomas Zeng , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt Message-ID: <20030303175204.GA27707@real.com> References: <72263E8E8622D611975C0002B32C19D84A7858@MISTY> <3E631CD0.9000000@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <3E631CD0.9000000@era.ericsson.se> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 03, 2003 at 10:13:52AM +0100, Magnus Westerlund wrote: > Hi Thomas, >=20 > Comments below: >=20 > Thomas Zeng wrote: >=20 > >Magnus: > > > >I have a comment on 3.2 Symetric RTP. > > > >As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server > >normally uses a single RTP port (let's call it X) to send RTP packets to > >many (potentially hundreds) of clients. Now Symetric RTP asks these clie= nts > >to send an RTP packet with their individual client SSRC in the payload to > >this port X on the server host. Since each client randomly generates cli= ent > >SSRC, there is some chance (as high as 10^-4 according to RFC1889, secti= on > >8.1) that two clients may end up with same SSRC, in which case the server > >may send RTP packets to wrong clients. I did study the SSRC collision > >detection scheme in RFC1889 and found it irrelevant because it only appl= ies > >to multicast RTP sessions. I don't think destination IP can help here si= nce > >prior to the establishment of binding our server doesn't know clients > >public IPs. Besides, the two collided clients may well be behind the same > >NAT and hence probably share public IP. > >=20 > > >=20 > My first comment is that the easiest way of solving this problem, is for= =20 > the server to send from different ports for each client. That way you=20 > reduce the probability of collisions and ensures maximum security in=20 > respect to hijacking. This is a big resource drain on the server. It effectively *triples* the number of sockets you need to pass into select() or poll(). That is, for N clients, the server must poll on 3*N sockets (one RTSP, RTP, and RTCP socket per client) instead of 1*N+2 (one RTSP socket per client plus a fixed RTP and RTP socket). I can see an example server doing this, but I have doubts that commercial code would be willing to take the hit. --=20 "When competing for a section of road or a parking space, remember that the vehicle in need of the most body work has the right-of-way." -- Massachusetts Driver Education Manual --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Y5ZEqznSmcYu2m8RAn8cAJ0fnGAl0HGbBCkFZEwL/FWN6ApACACZAdb0 cLSxhFki3A4LJgSeRp/yas0= =ZWwA -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 3 18:37:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18043 for ; Mon, 3 Mar 2003 18:37:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23NlK105519 for mmusic-archive@odin.ietf.org; Mon, 3 Mar 2003 18:47:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23NlKp05516 for ; Mon, 3 Mar 2003 18:47:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18016 for ; Mon, 3 Mar 2003 18:36:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23NlDp05507; Mon, 3 Mar 2003 18:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Nkop05486 for ; Mon, 3 Mar 2003 18:46:50 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17951 for ; Mon, 3 Mar 2003 18:36:08 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h23NbvB14688; Mon, 3 Mar 2003 15:37:57 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 15:37:56 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7874@MISTY> From: Thomas Zeng To: "'Tom Marshall'" , Magnus Westerlund Cc: Thomas Zeng , mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt Date: Mon, 3 Mar 2003 15:37:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, Tom: Another reason that ports are precious resource on the server is that, a well designed streaming server may be able to scale up to 10000 simultaneous clients (which Microsoft's Windows Media server claims to support... I know Microsoft today doesn't use RTSP but it may in the future). If each has 6 RTP tracks then there will not be enough ports to go around with Magnus proposal. Therefor I still think we must be prepared to resolve client SSRC conflict. Someone suggested that we can put in the "contributing SSRC" field the server's SSRC for that session. The combination of client SSRC and server SSRC in the binding RTP packets would be certainly possible to ensure uniqueness (since the server can choose its SSRC with no collision). What do people think? - thomas -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Monday, March 03, 2003 9:52 AM To: Magnus Westerlund Cc: Thomas Zeng; mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt On Mon, Mar 03, 2003 at 10:13:52AM +0100, Magnus Westerlund wrote: > Hi Thomas, > > Comments below: > > Thomas Zeng wrote: > > >Magnus: > > > >I have a comment on 3.2 Symetric RTP. > > > >As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server > >normally uses a single RTP port (let's call it X) to send RTP packets to > >many (potentially hundreds) of clients. Now Symetric RTP asks these clients > >to send an RTP packet with their individual client SSRC in the payload to > >this port X on the server host. Since each client randomly generates client > >SSRC, there is some chance (as high as 10^-4 according to RFC1889, section > >8.1) that two clients may end up with same SSRC, in which case the server > >may send RTP packets to wrong clients. I did study the SSRC collision > >detection scheme in RFC1889 and found it irrelevant because it only applies > >to multicast RTP sessions. I don't think destination IP can help here since > >prior to the establishment of binding our server doesn't know clients > >public IPs. Besides, the two collided clients may well be behind the same > >NAT and hence probably share public IP. > > > > > > My first comment is that the easiest way of solving this problem, is for > the server to send from different ports for each client. That way you > reduce the probability of collisions and ensures maximum security in > respect to hijacking. This is a big resource drain on the server. It effectively *triples* the number of sockets you need to pass into select() or poll(). That is, for N clients, the server must poll on 3*N sockets (one RTSP, RTP, and RTCP socket per client) instead of 1*N+2 (one RTSP socket per client plus a fixed RTP and RTP socket). I can see an example server doing this, but I have doubts that commercial code would be willing to take the hit. -- "When competing for a section of road or a parking space, remember that the vehicle in need of the most body work has the right-of-way." -- Massachusetts Driver Education Manual _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 4 04:33: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 EAA10365 for ; Tue, 4 Mar 2003 04:33:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h249hmF20250 for mmusic-archive@odin.ietf.org; Tue, 4 Mar 2003 04:43:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249hmp20247 for ; Tue, 4 Mar 2003 04:43:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10337 for ; Tue, 4 Mar 2003 04:32:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249hbp20221; Tue, 4 Mar 2003 04:43:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249gtp20134 for ; Tue, 4 Mar 2003 04:42:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10276 for ; Tue, 4 Mar 2003 04:31:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h249Y1nS019443; Tue, 4 Mar 2003 10:34:01 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD42SWVM; Tue, 4 Mar 2003 10:34:00 +0100 Message-ID: <3E647308.3070902@era.ericsson.se> Date: Tue, 04 Mar 2003 10:34:00 +0100 X-Sybari-Trust: 8bdf304b 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: "'Tom Marshall'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt References: <72263E8E8622D611975C0002B32C19D84A7874@MISTY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thomas and Tom, I understand your performance considerations. I know we have discussed this before on the teleconference. One reason raised for poor port performance was the lack of optimized implementations. For example linear search that of course give works performance as the number of ports increase. Should we fix this problem I think we should design something that are a general mechanism that actually help us in other cases. Therefore my suggestion is still to construct a RTP payload format and a RTCP packet type that can carries challenge and responses containing security tags. Thomas Zeng wrote: >Magnus, Tom: > >Another reason that ports are precious resource on the server is that, a >well designed >streaming server may be able to scale up to 10000 simultaneous clients >(which Microsoft's Windows Media server claims to support... I know >Microsoft today doesn't use RTSP but it may in the future). If each has 6 >RTP tracks then there will not be enough ports to go around with Magnus >proposal. > At least not with only a single IP address. > >Therefor I still think we must be prepared to resolve client SSRC conflict. >Someone suggested that we can put in the "contributing SSRC" field the >server's SSRC for that session. The combination of client SSRC and server >SSRC in the binding RTP packets would be certainly possible to ensure >uniqueness (since the server can choose its SSRC with no collision). > >What do people think? > I think this last proposal is a bad idea. It may very well have implications on the future extensions that we deploy. It also changes the meaning of the SSRC and CSRC field to not be the standardized ones. The general problem is that RTP was not designed to have multiple sessions on the same port. This is simple something the manufacturers of streaming severs has done to solve an operations system performance problem. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 4 08:36:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20330 for ; Tue, 4 Mar 2003 08:36:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24DlQT04900 for mmusic-archive@odin.ietf.org; Tue, 4 Mar 2003 08:47:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24DlQp04897 for ; Tue, 4 Mar 2003 08:47:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20286 for ; Tue, 4 Mar 2003 08:36:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24DlKp04877; Tue, 4 Mar 2003 08:47:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Dkgp04839 for ; Tue, 4 Mar 2003 08:46:42 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20227 for ; Tue, 4 Mar 2003 08:35:42 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl6.philips.com (Postfix) with ESMTP id 0B565A3FCC; Tue, 4 Mar 2003 14:37:44 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA08185; Tue, 4 Mar 2003 14:37:42 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA13222; Tue, 4 Mar 2003 14:37:38 +0100 (MET) Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt To: Magnus Westerlund Cc: mmusic@ietf.org, "'Tom Marshall'" , Thomas Zeng X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 4 Mar 2003 14:31:00 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 04/03/2003 14:38:41 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, Would not this look an awfull lot like STUN then ? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Thomas Zeng cc: "'Tom Marshall'" mmusic@ietf.org (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Magnus Westerlund Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt Classification: Sent by: mmusic-admin@ietf.org 04/03/2003 10:34 Hi Thomas and Tom, I understand your performance considerations. I know we have discussed this before on the teleconference. One reason raised for poor port performance was the lack of optimized implementations. For example linear search that of course give works performance as the number of ports increase. Should we fix this problem I think we should design something that are a general mechanism that actually help us in other cases. Therefore my suggestion is still to construct a RTP payload format and a RTCP packet type that can carries challenge and responses containing security tags. Thomas Zeng wrote: >Magnus, Tom: > >Another reason that ports are precious resource on the server is that, a >well designed >streaming server may be able to scale up to 10000 simultaneous clients >(which Microsoft's Windows Media server claims to support... I know >Microsoft today doesn't use RTSP but it may in the future). If each has 6 >RTP tracks then there will not be enough ports to go around with Magnus >proposal. > At least not with only a single IP address. > >Therefor I still think we must be prepared to resolve client SSRC conflict. >Someone suggested that we can put in the "contributing SSRC" field the >server's SSRC for that session. The combination of client SSRC and server >SSRC in the binding RTP packets would be certainly possible to ensure >uniqueness (since the server can choose its SSRC with no collision). > >What do people think? > I think this last proposal is a bad idea. It may very well have implications on the future extensions that we deploy. It also changes the meaning of the SSRC and CSRC field to not be the standardized ones. The general problem is that RTP was not designed to have multiple sessions on the same port. This is simple something the manufacturers of streaming severs has done to solve an operations system performance problem. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 4 09:05: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 JAA22259 for ; Tue, 4 Mar 2003 09:05:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24EG6R07139 for mmusic-archive@odin.ietf.org; Tue, 4 Mar 2003 09:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EG6p07136 for ; Tue, 4 Mar 2003 09:16:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22247 for ; Tue, 4 Mar 2003 09:05:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EG3p07126; Tue, 4 Mar 2003 09:16:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EFJp07085 for ; Tue, 4 Mar 2003 09:15:19 -0500 Received: from condor.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22208 for ; Tue, 4 Mar 2003 09:04:18 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by condor.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h24E62AG023047; Tue, 4 Mar 2003 15:06:16 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD42VR92; Tue, 4 Mar 2003 15:05:37 +0100 Message-ID: <3E64B29D.10202@era.ericsson.se> Date: Tue, 04 Mar 2003 15:05:17 +0100 X-Sybari-Trust: a98431fc 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.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, Phillipe, My proposal: Should we fix this problem I think we should design something that are a general mechanism that actually help us in other cases. Therefore my suggestion is still to construct a RTP payload format and a RTCP packet type that can carries challenge and responses containing security tags. philippe.gentric@philips.com wrote: >Would not this look an awfull lot like STUN then ? > > In some sense yes, but mostly no. The goal of this mechanism is to identify the intention of sending media and authorizing it. What it shares with STUN is the possibility to use it for NAT traversal. The comparison with STUN would give the following advantages: - Being integrated into RTP/RTCP it will not have the multiplexing problems of STUN. - It can be used for the general DESTINATION problem of RTSP. Disadvantage: - Not being general, only useful with RTP. To solve the multiplexing the solution needs to be part of the media protocol. Problem for any solution that handles symmetric NAT. What this solution will not provide that STUN has is: - Mechanism to learn the external mapping. - Mechanism to detect what type of NAT your behind. - Mechanism to determine the NAT mapping time-out. I hope you see the differences that it is not awful lot like STUN. It is in fact another way of traversing NATs which has other advantages. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 4 10:01: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 KAA25216 for ; Tue, 4 Mar 2003 10:01:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24FCHB11486 for mmusic-archive@odin.ietf.org; Tue, 4 Mar 2003 10:12:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FCHp11483 for ; Tue, 4 Mar 2003 10:12:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25199 for ; Tue, 4 Mar 2003 10:01:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FCCp11467; Tue, 4 Mar 2003 10:12:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FB1p11438 for ; Tue, 4 Mar 2003 10:11:01 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25127 for ; Tue, 4 Mar 2003 09:59:59 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h24F20B3026886 for ; Tue, 4 Mar 2003 16:02:01 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XHLCBH; Tue, 4 Mar 2003 16:02:00 +0100 Message-ID: <3E64BFE8.3010406@era.ericsson.se> Date: Tue, 04 Mar 2003 16:02:00 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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: Agenda telecon 5th March 18.00-19.30 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 being this late. Here is the proposed agenda for tomorrow's telecon. 1. Follow up: - draft-ietf-mmusic-rfc2326bis-03.txt - Interleave: Aravind to write text and post to MMUSIC to address all four bugs. - Everybody reads on offer/answer (RFC 3264) and meet in next IETF meeting to take next step. 2. What to discuss during the IETF and the MMUSIC session. - What to take up to the whole WG: + The last changes + Open issues that need input? - Off line session + Offer Answer for RTSP? + 3. New Issues: * Unclarities when doing resetup http://rtsp.org/bug513737 * Conference header underspecified http://rtsp.org/bug539040 * "Clarify Range Where t0 <= t1" & "How to use Range when Scale is negative" http://rtsp.org/bug533691 http://rtsp.org/bug513880 * "When can REDIRECT be received?", http://rtsp.org/bug556061 * "Client issues PAUSE while server ready" http://rtsp.org/bug556295 Next meeting: Proposal: 2nd April. If you would like to participate please send a mail and you will receive the contact information. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 4 10:08: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 KAA25920 for ; Tue, 4 Mar 2003 10:08:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24FJ7i11824 for mmusic-archive@odin.ietf.org; Tue, 4 Mar 2003 10:19:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FJ7p11821 for ; Tue, 4 Mar 2003 10:19:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25856 for ; Tue, 4 Mar 2003 10:08:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FJ3p11808; Tue, 4 Mar 2003 10:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FI3p11761 for ; Tue, 4 Mar 2003 10:18:03 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25729 for ; Tue, 4 Mar 2003 10:07:01 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by alaska.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h24F920i014697 for ; Tue, 4 Mar 2003 16:09:02 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XHLD9G; Tue, 4 Mar 2003 16:09:02 +0100 Message-ID: <3E64C18E.8040104@era.ericsson.se> Date: Tue, 04 Mar 2003 16:09:02 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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] New Core RTSP draft: draft-ietf-mmusic-rfc2326bis-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Rob and I manage to submit a new version of the RTSP updated draft. Most of the given comments has found its way into the version. However due to lack of time I am not sure I managed to edit all the comments given on this draft. So please let me ask forgiveness already now. Please send any comments on the draft to the list. I am also sorry that the draft has managed to get even thicker. It is now 138 pages in the text version. To fetch it before being announce, see: http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.txt http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.ps http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 4 14:00: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 OAA05560 for ; Tue, 4 Mar 2003 14:00:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24JAaS05169 for mmusic-archive@odin.ietf.org; Tue, 4 Mar 2003 14:10:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JAa505166 for ; Tue, 4 Mar 2003 14:10:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05507 for ; Tue, 4 Mar 2003 13:59:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JAQ505151; Tue, 4 Mar 2003 14:10:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24J81504967 for ; Tue, 4 Mar 2003 14:08:01 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05431 for ; Tue, 4 Mar 2003 13:56:54 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h24IwmB39706; Tue, 4 Mar 2003 10:58:48 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 10:58:48 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A787F@MISTY> From: Thomas Zeng To: "'Magnus Westerlund'" , Thomas Zeng Cc: "'Tom Marshall'" , mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt Date: Tue, 4 Mar 2003 10:58:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus: You wrote: >The general problem is that RTP was not designed to have multiple >sessions on the same port. This is simple something the manufacturers of >streaming severs has done to solve an operations system performance >problem. Refering to section 3 of RFC1889, RTP session was defined by one "source-destination" pair of (ip, rtp-port, rtcp-port) tuples. It is VERY legal to have one source (ip, rtp-port, rtcp-port) serve traffic to multiple destination (ip, rtp-port, rtcp-port)'s in unit-cast fashion. Therefore us streaming server manufactures have not broken the law. I'd like to point out it is not just OS performance we are talking about. It is also the *reality* that there are only 64K ports per IP in IPV4, in addition to the inclination of server Firewall administrators always wanting to limit port range that the firewall (perhaps without address/port translation) on the server side will let pass. If we look at RFC1889 and RFC2326, RTSP servers do NOT have to open a RTP send port per RTP session. So we are talking about introducing new rules. Any time a new restriction is imposed, it must be studied long and hard. In this case, there exist alternatives. Let me summarize below: -- Alternative A is to include a SessionID in the binding RTP packet. -- Alternative B is to have server suggest client SSRC in setup response, as part of Transport header. Server and only server can make sure no collision in suggested client SSRC. To do so, a new transport parameter, client_ssrc will need to be added as optional parameter to Transport header in SETUP response. For some reason, "client_ssrc" parameter has already been proposed in http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.txt, or is that just a typo? I double checked to make sure that client_ssrc is not part of RFC2326. - thomas -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Tuesday, March 04, 2003 1:34 AM To: Thomas Zeng Cc: 'Tom Marshall'; mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt Hi Thomas and Tom, I understand your performance considerations. I know we have discussed this before on the teleconference. One reason raised for poor port performance was the lack of optimized implementations. For example linear search that of course give works performance as the number of ports increase. Should we fix this problem I think we should design something that are a general mechanism that actually help us in other cases. Therefore my suggestion is still to construct a RTP payload format and a RTCP packet type that can carries challenge and responses containing security tags. Thomas Zeng wrote: >Magnus, Tom: > >Another reason that ports are precious resource on the server is that, a >well designed >streaming server may be able to scale up to 10000 simultaneous clients >(which Microsoft's Windows Media server claims to support... I know >Microsoft today doesn't use RTSP but it may in the future). If each has 6 >RTP tracks then there will not be enough ports to go around with Magnus >proposal. > At least not with only a single IP address. > >Therefor I still think we must be prepared to resolve client SSRC conflict. >Someone suggested that we can put in the "contributing SSRC" field the >server's SSRC for that session. The combination of client SSRC and server >SSRC in the binding RTP packets would be certainly possible to ensure >uniqueness (since the server can choose its SSRC with no collision). > >What do people think? > I think this last proposal is a bad idea. It may very well have implications on the future extensions that we deploy. It also changes the meaning of the SSRC and CSRC field to not be the standardized ones. The general problem is that RTP was not designed to have multiple sessions on the same port. This is simple something the manufacturers of streaming severs has done to solve an operations system performance problem. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 5 06:38:50 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 GAA27119 for ; Wed, 5 Mar 2003 06:38:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Bnlt18008 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 06:49:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bnl518003 for ; Wed, 5 Mar 2003 06:49:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27068 for ; Wed, 5 Mar 2003 06:38:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BnX517948; Wed, 5 Mar 2003 06:49:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bha517422 for ; Wed, 5 Mar 2003 06:43:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26526; Wed, 5 Mar 2003 06:32:08 -0500 (EST) Message-Id: <200303051132.GAA26526@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Mar 2003 06:32:08 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-07.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 : Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) Author(s) : J. Arkko et al. Filename : draft-ietf-mmusic-kmgmt-ext-07.txt Pages : 15 Date : 2003-3-4 This document defines general extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, its use is meaningful only when it is completed by the key management protocol in use. General guidelines are also given on how the framework should be used together with SIP and RTSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-07.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-3-4174427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174427.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 Mar 5 10:40: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 KAA06400 for ; Wed, 5 Mar 2003 10:40:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Fpnt05224 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 10:51:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Fpn505221 for ; Wed, 5 Mar 2003 10:51:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06352 for ; Wed, 5 Mar 2003 10:40:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FpQ505207; Wed, 5 Mar 2003 10:51:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Foa505165 for ; Wed, 5 Mar 2003 10:50:36 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06280 for ; Wed, 5 Mar 2003 10:39:02 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25Ff4B3003450; Wed, 5 Mar 2003 16:41:04 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5W9MTRN; Wed, 5 Mar 2003 16:41:04 +0100 Message-ID: <3E661A90.8050209@era.ericsson.se> Date: Wed, 05 Mar 2003 16:41:04 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt References: <72263E8E8622D611975C0002B32C19D84A787F@MISTY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thomas, Thomas Zeng wrote: >Magnus: > >You wrote: > > > >>The general problem is that RTP was not designed to have multiple >>sessions on the same port. This is simple something the manufacturers of >>streaming severs has done to solve an operations system performance >>problem. >> >> > >Refering to section 3 of RFC1889, RTP session was defined by one >"source-destination" pair of (ip, rtp-port, rtcp-port) tuples. >It is VERY legal to have one source (ip, rtp-port, rtcp-port) serve traffic >to multiple destination (ip, rtp-port, rtcp-port)'s in unit-cast fashion. >Therefore us streaming server manufactures have not broken the law. > > This is in fact a multiplexing problem. One needs to establish the session and what it consist of. For unicast it is possible to define a session by defining the two end points and the port numbers it uses. This gives sufficient information for demultiplexing. This has so far been used in servers to save ports. Each session is defined by the clients IP/Ports. For a multicast session the multicast address and port is used for multiplexing. If we would have a multi-unicast session one way of defining the session is to say all that I receive on a certain port belongs to this session, independly of source address. As shown above how you can utilize the port depends on the demultiplexing requirements you have. For normal unicast sessions where you know the remote address it works fine. However in the case of symmetric RTP we don't know the external address. Therefore one solution is to use different server ports. >I'd like to point out it is not just OS performance we are talking about. It >is also the *reality* that there are only 64K ports per IP in IPV4, in >addition to the inclination of server Firewall administrators always wanting >to limit port range that the firewall (perhaps without address/port >translation) on the server side will let pass. > Yes, there is a limitation to the number of ports per IP. However this is a fairly high limitation as it is sufficient for 15000 users each having two RTP sessions, i.e. 2 * 2 ports. I don't think using firewalls as an argument is a very valid one. If your having a streaming service you need to configure the FW to handle this server correctly. Doesn't the server in fact belong in the demilitarized zone in most cases. > >If we look at RFC1889 and RFC2326, RTSP servers do NOT have to open a RTP >send port per RTP session. So we are talking about >introducing new rules. > I haven't talking so much about introducing new rules as of actually on how you can implement things within the standard. > >Any time a new restriction is imposed, it must be studied long and hard. > As this is no restriction just a implementation question. >In >this case, there exist alternatives. Let me summarize below: > > >-- Alternative A is to include a SessionID in the binding RTP packet. > The information used to id the session is not important, just that something is used. This requires a new RTP payload format and for RTCP new packet type. I think this is a good idea, especially when you are at it to define a format that can be used to handle destination verification of media streams. This solution does allow for much greater security by having longer id tags. >-- Alternative B is to have server suggest client SSRC in setup response, as >part of Transport header. Server and only server can make sure no collision >in suggested client SSRC. To do so, a new transport parameter, client_ssrc >will need to be added as optional parameter to Transport header in SETUP >response. > Yes, this could be one way of assigning the ssrc. However one other consideration to think of in regards to symmetric RTP is that if we have 10000 clients on the same port it will be that many times easier to hijack a stream. If you multiplex using different port for each session you ensure that the whole number space of the SSRC is used. >For some reason, "client_ssrc" parameter has already been >proposed in >http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.txt, or >is that just a typo? I double checked to make sure that client_ssrc is not >part of RFC2326. > This was added by me in this version. My intention was to use it with symmetric RTP and be used by the client to tell which SSRC it will be using. This would of course rely on the server ensuring that no two users with the same SSRC will be sent to the same server side port. So this is Alternative C as described by the RTSP & NAT draft. The parameter should perhaps belong to the RTSP & NAT draft. There is a fourth alternative (D) as you have earlier described: Putting this sessions server SSRC as a CSRC. However I still think this is a bad idea as it redefines the field. This may interfere with future services. To summarize: Solution A, good can solve another problem and gives best security. Requires more standards work. Solution B, Requires minimal standards work. Its security might not be that good. Changes the assignment rules for SSRC. Solution C, Requires minimal standards work (same as B). Its security is slightly better than B. Uses more ports. Solution D. Same standards works as B & C. Does not look future proof. I would prefer A. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 5 11:11:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09528 for ; Wed, 5 Mar 2003 11:11:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25GMNU08888 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 11:22:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GMN508885 for ; Wed, 5 Mar 2003 11:22:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09501 for ; Wed, 5 Mar 2003 11:10:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GMB508859; Wed, 5 Mar 2003 11:22:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GLf508795 for ; Wed, 5 Mar 2003 11:21:41 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09444 for ; Wed, 5 Mar 2003 11:10:07 -0500 (EST) Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29415; Wed, 5 Mar 2003 08:12:10 -0800 (PST) Received: from sun.com (streamers [10.6.83.99]) by phys-ha2mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA23002; Wed, 5 Mar 2003 08:12:09 -0800 (PST) Message-ID: <3E66221A.8020700@sun.com> Date: Wed, 05 Mar 2003 08:13:14 -0800 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell CC: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field References: <3E55FF10.1000100@era.ericsson.se> 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 Aaron Colwell wrote: >Thank you for the clarification. I was somewhat expecting that answer, but >I just wanted to make sure. > >One other thing that I'd like to have clarified is that if absolute URLs >are returned that they match what was sent in the SETUP request for that >stream. I've run into a case where a server will return me an IP address >in the hostname part of the URL instead of the hostname that I specified. >It is things like this that make matching SETUP URLs with RTP-Info >information not very easy. I'd like to not have to use heuristic methods >for dealing with these types of situations. Perhaps the clarification for >RTP-Info URLs should be something like > >"Any relative URL SHALL use the request URL as base URL. The resulting > URL must match the URL used to SETUP that stream. > I'm not sure exactly what it means to say "the resulting URL must match the URL used to SETUP that stream." In the case below, for example, the SETUP URLs are different than the PLAY URL. OPTIONS rtsp://foo.com SETUP rtsp://foo.com/audio.3gp/trackID=1 SETUP response SETUP rtsp://foo.com/video.3gp/trackID=1 SETUP response PLAY rtsp://foo.com/movie PLAY response RTP-Info: url=audio.3gp/trackID=1;seq=0;rtptime=0, url=video.3gp/trackID=1;seq=234;rtptime=23487 The resulting full url is rtsp://foo.com/movie/audio.3gp/trackID=1 and rtsp://foo.com/movie/video.3gp/trackID=1, which are not the same as the SETUP urls. > If an absolute URL is > specified, it MUST match the URL used to SETUP that stream." > I think we need to clearer on the exact wording and probably provide a good example (similar to what's been give on this alias). > > Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 5 11:24: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 LAA10537 for ; Wed, 5 Mar 2003 11:24:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25GZJ610161 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 11:35:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GZJ510158 for ; Wed, 5 Mar 2003 11:35:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10514 for ; Wed, 5 Mar 2003 11:23:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GZ6510141; Wed, 5 Mar 2003 11:35:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GYd510039 for ; Wed, 5 Mar 2003 11:34:39 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10476 for ; Wed, 5 Mar 2003 11:23:05 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25GP7B4013911; Wed, 5 Mar 2003 17:25:07 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5W9M9X3; Wed, 5 Mar 2003 17:25:06 +0100 Message-ID: <3E6624DA.8040402@era.ericsson.se> Date: Wed, 05 Mar 2003 17:24:58 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aravind Narasimhan CC: Aaron Colwell , mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field References: <3E55FF10.1000100@era.ericsson.se> <3E66221A.8020700@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 Aravind, You are making a mistake here. You are not following the correct rules for how to resolve relative URLs. See RFC 2396 for these rules. Aravind Narasimhan wrote: > PLAY rtsp://foo.com/movie > PLAY response > RTP-Info: url=audio.3gp/trackID=1;seq=0;rtptime=0, > url=video.3gp/trackID=1;seq=234;rtptime=23487 > > The resulting full url is rtsp://foo.com/movie/audio.3gp/trackID=1 and > rtsp://foo.com/movie/video.3gp/trackID=1, which are not the same as > the SETUP urls. The error you made here is that you did not remove all that is after the last "/". The base URL is "rtsp://foo.com/movie" however when resolving this you take the part upto and including the last "/", i.e, "rtsp://foo.com/". To this you add the relative URL resulting in: rtsp://foo.com/audio.3gp/trackID=1 rtsp://foo.com/video.3gp/trackID=1 > >> If an absolute URL is >> specified, it MUST match the URL used to SETUP that stream." >> > I think we need to clearer on the exact wording and probably provide a > good example (similar to what's been give on this alias). Sure, improving the text is always good. Do you have any proposal what would be clearer? Best Regards. Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 5 11:52: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 LAA12235 for ; Wed, 5 Mar 2003 11:52:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25H3es13669 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 12:03:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H3d513666 for ; Wed, 5 Mar 2003 12:03:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12178 for ; Wed, 5 Mar 2003 11:52:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H3R513609; Wed, 5 Mar 2003 12:03:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Gkr512754 for ; Wed, 5 Mar 2003 11:46:53 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11264 for ; Wed, 5 Mar 2003 11:35:20 -0500 (EST) Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03887; Wed, 5 Mar 2003 09:37:23 -0700 (MST) Received: from sun.com (streamers [10.6.83.99]) by phys-ha2mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA00592; Wed, 5 Mar 2003 08:37:22 -0800 (PST) Message-ID: <3E662803.5010206@sun.com> Date: Wed, 05 Mar 2003 08:38:27 -0800 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field References: <3E55FF10.1000100@era.ericsson.se> <3E66221A.8020700@sun.com> <3E6624DA.8040402@era.ericsson.se> 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 > > >> >> The resulting full url is rtsp://foo.com/movie/audio.3gp/trackID=1 >> and rtsp://foo.com/movie/video.3gp/trackID=1, which are not the same >> as the SETUP urls. > > > The error you made here is that you did not remove all that is after > the last "/". The base URL is "rtsp://foo.com/movie" however when > resolving this you take the part upto and including the last "/", i.e, > "rtsp://foo.com/". To this you add the relative URL resulting in: > rtsp://foo.com/audio.3gp/trackID=1 > rtsp://foo.com/video.3gp/trackID=1 oh yeah. .. my bad. We ran into a similar problem before for the same reason. . so ignore my comment. >>> If an absolute URL is >>> specified, it MUST match the URL used to SETUP that stream." >> >> I think we need to clearer on the exact wording and probably provide >> a good example (similar to what's been give on this alias > > Sure, improving the text is always good. Do you have any proposal what > would be clearer? I'll look through the current wording as well as our current email thread on this and propose some new wording within the next week. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 5 15:21:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27080 for ; Wed, 5 Mar 2003 15:21:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25KW5X17249 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 15:32:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KW5O17246 for ; Wed, 5 Mar 2003 15:32:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27066 for ; Wed, 5 Mar 2003 15:20:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KVpO17193; Wed, 5 Mar 2003 15:31:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KUoO17125 for ; Wed, 5 Mar 2003 15:30:50 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27034 for ; Wed, 5 Mar 2003 15:19:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 05 Mar 2003 12:19:55 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Wed, 05 Mar 2003 12:19:55 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2/8.12.2) with ESMTP id h25KKUjn003847 for ; Wed, 5 Mar 2003 12:20:31 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18qfNZ-00080X-00 for ; Wed, 05 Mar 2003 12:20:41 -0800 Date: Wed, 05 Mar 2003 12:17:50 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-0.2 required=5.0 tests=KNOWN_MAILING_LIST,NO_REAL_NAME version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-UIDL: 3334b49ea8d03fd4a5d9ccd75b7e76cb To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #73 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 05 Mar 2003 09:53:53 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 Bugs item #533691, was opened at 2002-03-22 17:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify Range Where t0 <= t1 Initial Comment: If the server receives a PLAY range from t0-t1, where t0 < t1, should it reject the PLAY, or should the server play backwards as if the timescale is -1? If t0 = t1, should the server send any media data after responding 200 OK? We've seen different servers behave differently in this scenario. ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2003-03-05 17:53 Message: Logged In: YES user_id=20397 If scale positive, t1 must >= t0. Otherwise, t1 must <= t0 ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2002-03-22 17:41 Message: Logged In: YES user_id=20397 I just came across 513880, which is closely related. That is to say, if timescale is positive, should the play range to be required to have t1 > t0? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 5 17:03: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 RAA02139 for ; Wed, 5 Mar 2003 17:03:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25MEQF27626 for mmusic-archive@odin.ietf.org; Wed, 5 Mar 2003 17:14:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MEPO27619 for ; Wed, 5 Mar 2003 17:14:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02114 for ; Wed, 5 Mar 2003 17:03:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25ME7O27578; Wed, 5 Mar 2003 17:14:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MDsO27533 for ; Wed, 5 Mar 2003 17:13:54 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02102; Wed, 5 Mar 2003 17:02:38 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h25M4WE06163; Wed, 5 Mar 2003 14:04:32 -0800 Date: Wed, 5 Mar 2003 14:04:32 -0800 From: John Lazzaro Message-Id: <200303052204.h25M4WE06163@snap.CS.Berkeley.EDU> To: avt@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] SF Issue Summary: draft-lazzaro-avt-rtp-framing-contrans-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, This is the summary message for the Wednesday, 19th March AVT WG presentation: Framing RTP over Connection-Oriented Transport (Lazzaro) 15 draft-lazzaro-avt-rtp-framing-contrans-00.txt I'm CC'ing this to MMUSIC, given the topical overlap of the I-D. This summary is somewhat long, because I describe the decisions that will move the document forward, so that WG members who won't be in San Francisco can voice their views on the lists by responding to this post. My presentation in San Francisco will put the 3 open issues described below up on the screen, to see if at least within the room a consensus can be found. --- This I-D began with an extended discussion on the WG: http://www1.ietf.org/mail-archive/working-groups/avt/current/msg01847.html Three requirements arose from this discussion: [1] A memo was needed to document the "classical" framing of RTP over TCP, to facilitate interoperability with applications that use it (several are mentioned in the linked WG thread). [2] There was an MMUSIC I-D that defined SDP conventions for setting up a TCP media session (draft-ietf-mmusic-sdp-comedia-04.txt, soon to be draft-ietf-mmusic-sdp-comedia-05.txt), but comedia defines neither the SDP fmt token to specify an RTP/AVP stream, nor the TCP framing such a stream should use. [3] RTSP has support for interleaving RTP and RTCP media streams into the TCP stream used for RTSP control method traffic. However, although RTSP also has the syntactic power to specify non-interleaved TCP session in the SETUP method, there is (apparently) no semantics in common use for this syntax. Requirement [1] is simple to address: write a new I-D to document classical RTP TCP framing. Sections 2-3 of draft-lazzaro-avt-rtp-framing-contrans-00.txt attempt to do this. #####> Open Issue #1 Does draft-lazzaro-avt-rtp-framing-contrans-00.txt accurately capture classical TCP framing, as used in practice? In specific, are the details in Section 3 correct? ---- The second requirement is more controversial. Given that we try to avoid "there's more than one way to do it", it would be best if there was one RTP/AVP TCP framing method for use with draft-ietf-mmusic-sdp-comedia-05.txt. The discussion in the WG thread linked above did not reach consensus, but instead ended with two different options: A. Define classical TCP framing as the framing method for RTP/AVP to use with draft-ietf-mmusic-sdp-comedia-05.txt. B. Write an AVT I-D that describes RTSP interleaved-mode RTP/AVP framing, as run over a stand-alone TCP stream. Define this framing method as the framing method to use with draft-ietf-mmusic-sdp-comedia-05.txt. Section 4 of draft-lazzaro-avt-rtp-framing-contrans-00.txt implements "A". Two more open issues: #####> Open Issue #2 Is A or B above the right path to take? Or, should we define SDP fmt codes for both A and B? ---- and #####> Open Issue #3 If A is the right option to take, are the SDP details in Section 4 of the draft-lazzaro-avt-rtp-framing-contrans-00.txt acceptable to everyone? ---- The final requirement involves RTSP support for non-interleaved TCP. Section 5 of draft-lazzaro-avt-rtp-framing-contrans-00.txt defines candidate RTSP semantics to use the classical TCP framing in RTSP. However, recent discussions in the Rtspspec-bugs transcripts seem to indicate that the editors of the core RTSP draft would prefer to handle this issue as a part of the RTSP draft document. So, unless I hear otherwise, I would think that deleting Section 5, and all mentions of RTSP, from draft-lazzaro-avt-rtp-framing-contrans-00.txt, is appropriate. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 6 05:15: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 FAA00623 for ; Thu, 6 Mar 2003 05:15:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26AQf221305 for mmusic-archive@odin.ietf.org; Thu, 6 Mar 2003 05:26:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AQeO21302 for ; Thu, 6 Mar 2003 05:26:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00610 for ; Thu, 6 Mar 2003 05:15:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AQ4O21277; Thu, 6 Mar 2003 05:26:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AOSO21212 for ; Thu, 6 Mar 2003 05:24:28 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00504; Thu, 6 Mar 2003 05:12:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26AEuB3009603; Thu, 6 Mar 2003 11:14:56 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JGN5G; Thu, 6 Mar 2003 11:14:56 +0100 Message-ID: <3E671F9E.7080706@era.ericsson.se> Date: Thu, 06 Mar 2003 11:14:54 +0100 X-Sybari-Trust: 8d2942c6 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvia.Pfeiffer@csiro.au CC: avt@ietf.org, mmusic@ietf.org References: <3E66AF6D.7040106@csiro.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [AVT] new I-D on temporal URI addresses Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, Silvia. I see the possibility of this proposal. However I have a number of comments on this proposal. First is the possibility to specify this as a general mechanism. It seems that you want to have this to apply to all URI schemes. Is that really possible? How do you know that the use of @ will not collide with any usage? For example the rtsp scheme does not define how to interpret the fragment. So this is up to the server responding to a request. So this can potentially already be used by some implementations. Also does it make sense to be defined for all schemes. As this is currently related to media it seems that for the moment it applies to HTTP(S) and RTSP(U|S). So a general question, what is the actually possibilities to standardize such a solution? Second, is the usage of the fragment identifier. It seems that you tries to redefine the meaning of the fragment identifier. See below. From RFC 2396: "When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. fragment = *uric The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. The character restrictions described in Section 2 for URI also apply to the fragment in a URI-reference. Individual media types may define additional restrictions or structure within the fragment for specifying different types of "partial views" that can be identified within that media type." Two things strikes me as not being taken into account by your draft in relation to this quote. The first is from the first paragraph of the quote. The fragment identifier is interpreted by the user agent. While in chapter 4 of your draft you clearly specifies that the server shall interpret the fragment. This redefines the behavior of the fragment identifier. Secondly the interpretation of the fragment identifier is in relation to the data resulting in the request. So in fact it seems that you need to define the behavior on per media basis. I think the use of fragment to specify where in a media resource is appropriate in some case. For example an RTSP URL that has a fragment of the proposed type is useful. However as RTSP works the server shall not interpret the fragment as this is pointless. Only the client needs to do this and use that to determine the range to include in the PLAY request. So again the usage rules in chapter 4 seems to be wrong. It seems that the time specification should be complemented to allow specifying ranges. The result of a search or the part of your friends wedding video that you want to point out would in most cases only be a part of the video. Therefore both a start and stop time seems useful. Then it is also a very short step to having multiple ranges allow one to point out multiple parts of the same resource that are interesting. Also I think you have a few strange thing in the definition. First you specify an attribute "start" that I think are pointless. Either you totally skip the fragment or you can use "npt=0". Secondly it the defaulting to "npt". This clashed with the general parameters. If you use start then you have actually wrote "npt=start" which isn't defined. "now" works as long as this is based on the RTSP definitions of NPT, however from your BNF definitions this is evidently not the case. So my proposal is to skip having any default time scheme if you are going to have general attributes that does not belong to a time scheme. If you would like the server to take the range into account would not the use of query (?) be better? However I hope that somebody that are more will versed in URIs can give further suggestions. I can see the usefulness of this proposal, however there is need to resolve a number of issues: - A general standardization or target certain URI schemes? - Applicability on different media types and protocols needs to better understood. - Use of fragment or other URI syntax element, like parameter or query? - Need for having ranges? - The actual need for general parameters? Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 6 08:11: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 IAA11825 for ; Thu, 6 Mar 2003 08:11:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26DMZi02809 for mmusic-archive@odin.ietf.org; Thu, 6 Mar 2003 08:22:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DMZO02806 for ; Thu, 6 Mar 2003 08:22:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11764 for ; Thu, 6 Mar 2003 08:11:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DMEO02792; Thu, 6 Mar 2003 08:22:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DLqO02772 for ; Thu, 6 Mar 2003 08:21:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11673 for ; Thu, 6 Mar 2003 08:10:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26DCMww001813; Thu, 6 Mar 2003 14:12:22 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XH8JW4; Thu, 6 Mar 2003 14:12:20 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h26DCElW003292; Thu, 6 Mar 2003 15:12:14 +0200 (EET) Message-ID: <3E67492C.E282D4BB@lmf.ericsson.se> Date: Thu, 06 Mar 2003 15:12:12 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Louis Guindon CC: mmusic References: <2702075D4DE2B043BF5EB82E9CFAD45B4ED1AF@mail1.mediatrix.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [MMUSIC] Re: [Sipping] Media descriptor problem 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: 8bit Content-Transfer-Encoding: 8bit Louis, I have removed the SIPPING mailing list from the cc and added MMUSIC, since this is an MMUSIC related question. If you want to provide different parameters for a particular codec, you should define different dynamic payload types (e.g., 96 and 97). Gonzalo Louis Guindon wrote: > > Hi, > > We are receiving the following SDP with an INVITE... > m=audio 5004 RTP/AVP 8 8 > a=fmtp:8 ptime:20 > a=fmtp:8 ptime:30 > a=sendrecv > a=ptime:20 > > After looking in the RFC2327 ABNF for those fields, I cannot find any problem with the grammar. However, it's doesn't make sense to me that we can put the media format twice on the media announcements line. Moreover, it doesn't make more sense to put two attribut for the same media format with different parameters. > > Any idea where I can find about the validity/invadility of SDP packet? > > Regards, > > Louis Guindon > Software Design Engineer > Mediatrix Telecom, Inc. > lguindon@mediatrix.com > Tel : 819-829-8749 ext. 242 > Fax : 819-829-1973 > 4229, Garlock Street > Sherbrooke, Qc J1L 2C8 > > This message and its attachment(s) contain protected proprietary and > confidential information of Mediatrix. It is intended solely for the > named addressee(s). If you are not an addressee indicated in this message > (or responsible for delivery of the message to an addressee), you may not > copy or deliver this message or its attachment(s) to anyone. Rather, you > should permanently delete this message and its attachment(s) and kindly > notify the sender by email. No warranty is made that the email or > attachment(s) are free from computer virus or other defect. > > Ce message et son(ses) fichier(s) adjoint(s) peuvent contenir de > l'information légale privilégiée ou confidentielle de Mediatrix. Il est > destiné exclusivement au(x) destinataire(s) identifié(s). Si vous n'êtes > pas un destinataire indiqué dans ce message (ou responsable de la > livraison du message au destinataire), vous ne pouvez copier ou livrer ce > message ou son(ses) fichier(s) adjoint(s) à quiconque. Vous devriez > plutôt effacer de façon permanente ce message et son(ses) fichier(s) > adjoint(s) et aimablement en avertir l'expéditeur par courriel. Aucune > garantie n'est donnée que ce courriel ou son(ses) fichier(s) adjoint(s) ne > contiennent pas de virus informatique ou autre défectuosité. > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 6 08:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13343 for ; Thu, 6 Mar 2003 08:37:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Dm7w04725 for mmusic-archive@odin.ietf.org; Thu, 6 Mar 2003 08:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Dm7O04722 for ; Thu, 6 Mar 2003 08:48:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13280 for ; Thu, 6 Mar 2003 08:36:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Dm3O04675; Thu, 6 Mar 2003 08:48:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DhGO04474 for ; Thu, 6 Mar 2003 08:43:16 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13071 for ; Thu, 6 Mar 2003 08:31:42 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26DXlB3007311; Thu, 6 Mar 2003 14:33:47 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4J2S6G; Thu, 6 Mar 2003 14:33:46 +0100 Message-ID: <3E674E3A.4070106@era.ericsson.se> Date: Thu, 06 Mar 2003 14:33:46 +0100 X-Sybari-Trust: d6d1e81e 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Louis Guindon CC: mmusic Subject: Re: [MMUSIC] Re: [Sipping] Media descriptor problem in SDP References: <2702075D4DE2B043BF5EB82E9CFAD45B4ED1AF@mail1.mediatrix.com> <3E67492C.E282D4BB@lmf.ericsson.se> 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 Louis, There are actually some errors in this SDP you present. It is however not a clear syntax error. If you look in draft-ietf-rtp-mime-06.txt you will see that chapter 3 tells how to map the ptime parameter to the SDP. And it shall not be part of the a=fmtp line but go into its own line. Unfortunately you can't specify these parameters on individual payload type basis. They apply in general to all payload formats that allow them in that media block. Also there is an error using the same PT twice on the m= line. So if you of some reasons want to have two PTs for PCMA then your SDP should be written like this utilizing dynamic PTs as Gonzalo pointed out: m=audio 5004 RTP/AVP 8 96 a=rtpmap:96 PCMA/8000 a=sendrecv a=ptime:20 I hope this clarifies things. If the only thing you would like to accomplish is to have different frame lengths a single PT is enough. If you in the SDP likes to clarify that you will use 20 or 30 but never more than 30 ms then you could write this as: m=audio 5004 RTP/AVP 8 96 a=sendrecv a=ptime:20 a=maxptime:30 Regards Magnus PS. Please don't send confidentiality message like your initial message contained as the mailing list you sent to is an open list having a public archive. >Louis Guindon wrote: > > >>Hi, >> >>We are receiving the following SDP with an INVITE... >> m=audio 5004 RTP/AVP 8 8 >> a=fmtp:8 ptime:20 >> a=fmtp:8 ptime:30 >> a=sendrecv >> a=ptime:20 >> >>After looking in the RFC2327 ABNF for those fields, I cannot find any problem with the grammar. However, it's doesn't make sense to me that we can put the media format twice on the media announcements line. Moreover, it doesn't make more sense to put two attribut for the same media format with different parameters. >> >> -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 6 10:11: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 KAA19276 for ; Thu, 6 Mar 2003 10:11:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FMTZ12788 for mmusic-archive@odin.ietf.org; Thu, 6 Mar 2003 10:22:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FMTO12785 for ; Thu, 6 Mar 2003 10:22:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19250 for ; Thu, 6 Mar 2003 10:10:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FMFO12742; Thu, 6 Mar 2003 10:22:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262OPO12706 for ; Wed, 5 Mar 2003 21:24:25 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10210; Wed, 5 Mar 2003 21:13:05 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id NAA16021; Thu, 6 Mar 2003 13:15:07 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa003uG; Thu Mar 6 13:15:03 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 13:15:03 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKXXYV3Y; Thu, 6 Mar 2003 13:14:50 +1100 To: avt@ietf.org, mmusic@ietf.org Message-ID: <3E66AF6D.7040106@csiro.au> Date: Thu, 06 Mar 2003 13:16:13 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] new I-D on temporal URI addresses Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 all, we have submitted a proposal to specify temporal URI fragments on time-continuous Web resources (such as audio and video files/streams). I would like to ask for your brains on whether this is a problem that you've stumbled across, too, and whether you like the solution that we are proposing. http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00.txt THE PROBLEM: ------------ We can see a need for the direct specification of points of interest in a URI for a/v. There are several uses for it: 1) Representation of search results: When typing a search term into your favourite search engine, you would like it to search on a/v and bring up the link to an offset in a video where the search term matches. e.g. goal in last week's soccer matches 2) Favourite links: When sending a link to a video to a friend, you'd really like to be able to specify the main part of your interest in it. e.g. look at my new cool sunglasses in my friend's wedding video THE SOLUTION: ------------- What we want is to address fragment offsets into videos. Therefore, the "#fragment" part of a URI naturally lends itself for including this address specification. For specification of the time points, we were inspired by the timestamp specification in RTSP. Therefore, we are proposing the following pattern: #@npt=14.5 -> the "#" part signifies a fragment specification -> the "@" tells us to look "at" that time specification -> the "npt=" part is a time scheme just like in RTSP and we are also proposing npt, smpte, smpte-30-drop, smpte-25, and clock -> the time format itself depends on the time scheme, this one signifying a 14.5 seconds offset [for more details refer to the I-D] THE USE: -------- Here are examples for temporal URI fragment offsets: http://foo/bar.mov#@smpte=00:00:14:15 (start downloading at 14 seconds and 15 frames into bar.mov) rtsp://foo/bar.avi#@utc=20030308T143000.00Z (start streaming at 8th March 2003 at half past 2pm) http://foo/bar.mpg#@start (start downloading from the start) rtsp://foo/bar.rm#@now (start streaming now) --- We wanted to make it simple, intuitive and human readable and have therefore come up with this solution. Please let me know what you think. Cheers, Silvia. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 6 22:58: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 WAA26424 for ; Thu, 6 Mar 2003 22:58:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2749We27462 for mmusic-archive@odin.ietf.org; Thu, 6 Mar 2003 23:09:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2749WO27459 for ; Thu, 6 Mar 2003 23:09:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26408 for ; Thu, 6 Mar 2003 22:57:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2748pO27424; Thu, 6 Mar 2003 23:08:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2747gO27315 for ; Thu, 6 Mar 2003 23:07:42 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26376 for ; Thu, 6 Mar 2003 22:55:51 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.8/8.12.8) with ESMTP id h273vq6P031123; Thu, 6 Mar 2003 22:57:53 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200303070357.h273vq6P031123@purple.nge.isi.edu> To: mmusic@ietf.org cc: jo@tzi.uni-bremen.de Date: Thu, 06 Mar 2003 22:57:52 -0500 From: Colin Perkins Subject: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-bwparam-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: , This is to announce a working group last call on the Transport Independent Bandwidth Modifier for SDP . Please send any final comments on this work to the mmusic@ietf.org mailing list by 17th March. If no substantive comments are received by that time, we propose to submit this draft to the IESG for publication as a proposed standard RFC. Joerg and Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 02:45: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 CAA13879 for ; Fri, 7 Mar 2003 02:45:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h277v6k26203 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 02:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h277v5O26200 for ; Fri, 7 Mar 2003 02:57:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13876 for ; Fri, 7 Mar 2003 02:45:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h277ukO26176; Fri, 7 Mar 2003 02:56:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h277txO26126 for ; Fri, 7 Mar 2003 02:55:59 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13845 for ; Fri, 7 Mar 2003 02:44:03 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id 2EB2F90976 for ; Fri, 7 Mar 2003 08:46:08 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA08474 for ; Fri, 7 Mar 2003 08:46:07 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA29317 for ; Fri, 7 Mar 2003 08:46:06 +0100 (MET) To: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 7 Mar 2003 08:39:24 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 07/03/2003 08:47:09 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBE671DFB400C28f9e8a93df938690918c4EBBE671DFB400C2" Content-Disposition: inline Subject: [MMUSIC] New draft on Stream Switching: draft-gentric-mmusic-stream-switching-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --0__=4EBBE671DFB400C28f9e8a93df938690918c4EBBE671DFB400C2 Content-type: text/plain; charset=us-ascii Please find attached a new MMUSIC Internet Draft on stream switching Abstract: Stream switching is a technique used to change the data rate of a media being streamed, typically for the purpose of adaptation to the effectively available bandwidth of the network. A backward compatible and independent RTSP "SWITCH" command is proposed in order to enable RTSP-based stream switching. (See attached file: draft-gentric-mmusic-stream-switching-00.zip) Comments are most welcome. Regards, PS: I know normally one should not post drafts on the reflector but I sent it to internet-drafts@ietf.org on the 20th of february and it has not surfaced since then(!?) PS2: This document is also archived online at: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_25bis/Docs/S4-030195.zip Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com --0__=4EBBE671DFB400C28f9e8a93df938690918c4EBBE671DFB400C2 Content-type: application/zip; name="draft-gentric-mmusic-stream-switching-00.zip" Content-Disposition: attachment; filename="draft-gentric-mmusic-stream-switching-00.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIABBoVC7Tl064i0EAAE7fAAAsAAAAZHJhZnQtZ2VudHJpYy1tbXVzaWMtc3RyZWFt LXN3aXRjaGluZy0wMC50eHTtfWtzG0eS4HfH+T/0IuJiyD0CJMCHJOo0WpqSbO5aEo+k7JhzKCYK 6ALQo0Z3u7tBiPPrL5/1aAAUJdO7cRfHiZFJoDurKivfmZX1/Xffy/8S+LkoWlsXtk1eF7OssLbO illyY5pPyZuynthk+8/btx+uL86TX3/sAHpVm2nLn339z+U8y7OqssmPtmjrbLL3bYAYTJO8zu2k rcsimzTfBuhb14E/b+y4Xpr6LhkdHBx+GyD7ucpq2yRny9myaQVQuH3rP1c315fJdVtbs0iuV1k7 mcOO+peub85uPlwn798kNz9dXCdvX799L7Bu5lmTpOVkuQDUJ/C7Kdym9mlT4ZMUv8iKZLrM82RS FtOyXpgC6IRAwHDzxMA3VV3eZk1WFk1STpNr2AT4PRke4F9Xb85HB6OTgQwbDwGj1jZZlfUnpEOd DUFp53YztfLsPcnuXLy+ebO7l2QMzTR7PHH4UwHP6nJZNYMkeVe2FiCblqGUMEgt3yYLcweLacok zRqgxfGy3TQz0/glEAxex33LSwmZHsStybM0AVQmBgb9nC2WC1xwk33mWS3Kop03tAic09gmyyo1 rU33ktpWuZngb/B2OW7K3MLnyfhOlkLvB5PFPbxL2mxhYfEXLe+mqWC/qjoziIsyWTZ245JwqbWd 2trihi/gaXglx4HhpUlGiLQLGRhwWuALPcQYTwPIBsaZAT03vYEjOpvkgF5c72RZ10h6XZRNABKs 2Uwm8CYsTjdr3rbV6f7+arUaZLadDsp6to+/7A+ztG/GsGdmAhvRfm51sDK5zeyKKIkG7ZD39dyk 5Sp5BSw3acs6s0A5jbXbR2vohcG8XeQDZq8zGVZGFD5slA+JrZLWTuZF9vvSIqpTwh5ga0b4S2Bj TVLjVgBKjBCATTMDOEAIDYHEHW/vqmwC3HZHpIPvVsu6Kht+MzVVa4jtAD5BwSfsdIrMeGvhLXNr styMc5uMgbRWWQrMK3wGOMF9GyRn8N3k08rUKcOYlIsKoOJLxFNFaisL/8C2keDpXf96cXP+Uw8f XIi4QOIqcaFAAMxldWqJaGxBw+Ob/bHBR5oOwgZecuH/RCsk3/TzW2UAx8OP33/3377/LlZX/qGN 4jMA0hHq/L/hAEmpLtMlCbr/Rzaf3nNcarIFLoBkJczRAuejGJEp0eTumhb4H9mV15xM63LBEGRf YTbyG9CCI4NbxGe0/AFro9r+viT9J0uAofGxBlCAyqcVRQXyqExRMIDMXuZtVuU6LZJ4AD4rlwJk nLU0Agj/cH0AZWEXMLvKTrIpcD5qv5C6kZYdKwRcQPRCQOxnmA/qPCZrxAh92dj61tYsvid5RnIY 8bCsqrJuFR+MpYDsdW6qPEd7hwTiiJVrCjuSpLaFXcSVFya/azKnJ+ERmNxiT8AKiGNEVmpvy5YJ T55k5gTVscSn9tzjJywkmWUBD/B2s2SZyA88QXhIfvDBss7aO9yUBqZWE+01uorhYJjcML0C0SMT 0uZ5uQzzEHpOmglgD/YLQeMqQ+2bJjBoalGu7LFm/lSUKxEqqGt+oRfeF8kreqiX7Pzy/tXugAZo snbJLEFIgNFaFknTbLYEpTwcBLRAhA70WC4MEuqUd/I3/Pejbugg+enm5pIedbxILE1glCvx4Wxi 90HH5vAQT2AABC67yAOhWLtLqjIrWtmzZbMkiIaH/nD1My+DpYGoxKq2fdBVyEiEmykQA+pj/Jqp HamklwPL92CDl2gdwXpW8wyYcwIClwbHAfavbpRSE9SaiE6RP7XNzV1AkP4f//Ov3Z9ky8/ag11A 3ef1F8L1fQ+uA6JXrnlN+Pf/7K/9/NU/eE6suRHQvX9v/WIN0GPhKPkvQD8R4X0PrgNiTfoA9NOD /x/9ydbFIm8Cd394BXLgfPODj2wkjR7ZSIqG+Fde0TVq1pr/XicNRxuXyZWd2Ayp6JFpg0Xpxu/5 P1c35zDNq/Uv/N88I9gcXMNfNwHaurQNgEh+64tdQJt/ts2o3vY9/Usrm1qbokmz5UEChKpjy/cb Obq/dUb+7z/GLfTPG9HZp2IjOLsg1FDDwSi5QlsarY26zMV+SUIVFpoebJqg473BcCfvPDKrUXUS jM1mNVB3vy37luxGtbBJ85N9v1OKcw6Tm9kGge7qREPrj+1Rti7Inuia2zsEs2FmQgOxFnbZVUui Iuy0YrTB+tAgZgsNrYHIMwjmym6Js72jFXlDPURlGD9KS3i1KMFwTlP0+HnVuhMmn4F/3c7BQKfp O1yuzB25RGBgY7gF3CVTz0AAqdmesJsI62jKBVpDpgFCoBHF9CUw3n+dtGxHbRse4zEGfZF2Xs5K MKPVmgTEtx1zWtcCE5hbDFORHSW2YpPN4O3sn0wfBETcF7QyGzbY13YvdIMqW2M4LfACIlLlaI0B Gl6g+Y7OUKPUwZvZLGE6YLjdvLk6T37Dfz+iIKAIjPre7L/BLJIdDG389muWLmz9cS/57ZfyHwWY pBP8/QdTNCb/uJs083KZpxRyEm+VoKTo/lG0r2VzGRjrOaIBsEJebmH5aWIZwk+A83Qp2yRclGeL DI3xWW2KZW7Ik0Av1vESOWyAbvBBlo33gxmIQ9fzZGWTuQEitp8BlxlSBUzToojAiJX6j41VSYCb z6oAHKiZxbEG7M8fJufiXxZ2VraZeg5rAmTNyXc+q26O81RDSK355EKXYPSXGN0qlwWjChyyJhtn OeIhjg9gxBVFHwNJlz7+yb5Gg/7n4J7Z4eYoS4zrLJ3hh/juzFSwy+3KWiGUXlubNMNxTN6L2YdF DlAUapHfl6bJ+vhVVizRzY7khsgXJy92SUTFsDfhZ0WkxPvLq+Ld0mesxkvR42wNCpxAJOEOHoGB YRY5ip4mMFEe2VA6fHxDiTfOzX3DDpZjcPsLQAFxBO08x1sywbpIEvZvWSokU9PMifKQC9j0qcCx IwMAox9ZkS2ILJjBwele1mObhmGSs4Ro1NZ9+9ksMMqSCVcG+7lxO3ViKEROccZFAnhChZXMQOsU QeALHg02OSBrBwT2u24p6CEYyFrGyi2FeVyYaDIvmzXQpQQ0MJoMyhyly4762mM7MRj8ZnhtWSbz bDbfJXG2CqcBbreoGZ2oxBjcNuA4je5hABf4Hl1+DJy5yJw1NajLVREtljV5H3YFBgC1glqKI+tl YePYFXAK7Lb1463RDIVlmrbhELytDMkNUEdWwztTz2Y7xFf4FcbkQ4HTkMgHGEafZnZmmqN4BsMF WmtVIcIHC4syIWtgSqXfng7NhlZUxjxtCgsbGoizs4T0KD/Kk15j8R2nlU3SA6zXvUgZo1LY5e0N aF7IneYltgMbJkwKEglZ2TyXkJO32mLrkpdHVBk8Uk4myzqwpBA/8BX9DqoCDDQJxciMWAvYGuck 8jCDocfWR9SOk7dAerf8LcXgAF2pqVOxQDzS3hKvpxZNeYyzYvy5zMtZJgrQWVSkpVnnsu4BBPPW fG4RcYCnsgLSBWJMvdx1lhlHYTEu9p5hMbnOHYVcXCpuNYyMo1NcO7VVXt6JUEfQYOPUkvEB3vBs S+q9abda2MSHiMxVCVieUPYIWW9h/qEGtxhzbNKXFQYryxpJuyH6Abrg2SS9MexRH4gNjMNeYLqJ VqK4HrEUiJdyjPlZkbF7LH4knQWzbZdN//dlKYvFtZ/6/SF8AVMzprJ1K69E48Vw7swsWP78DnaI JPqEODm0jO8TrfCyWaJQCAZDzs50b0uKY9M0+T1NquFHvaKEhYpq5l3GHcZs4wxeI4YTyxgXZzeZ 3kpQlWklDxDPxQ8dCrNNtNN6qxKTSigbETsVUT4ZsbiRqpEIzG+HP15e9n/49RosWDaUN2hRHEbc jWyB0gvR5XSMRoufSyQXgGAquVRtk+FoKExEETkKBnoo1AHISFkSjSHBwmgN7tgCc7Cg9dKyljQE 8wcBTm2T8eOh6Zc1IR1xzB0wCaKCZxWlM95kddOKv9iLthBEMfg5aY/Jo/G8gBLLUvA3mZeVzr6z g+JkwrzUxxRLG83rJhB4z4ULY35Ddq/LZYv4Hy9BhgP7AYxpXq5A61B2m9RY6PJOlWtXILuJ8FSE nJLgIqwgIXQBsmaCyaGap0zNI1t+R49v+YFZk7HQEsteDbS9ZAKACHGH4B1U4CSxPgbGWxZzU1Vi tlW2BLI8dUzIfk3d7KGwROsLBZ2RyeDmcvgEUWVVTPNTJByJCcG2m6IbA/8F5YwvCmtTGg6p4188 6V1boIJUaG+Du41gudjAtrj6NcZkIXRXsVCRocnyBxVQLcd5NgHomqZLRSSJkaP6lgWijq4yhIwk nBfzKgcNiiTHCEPSAL0BDbNrI+8vwFBSTrz5Bfyl0qQTMm3o4V0fKyKf1GmEwMwkuULhojEibEr5 F6CYBe2dbhMiUVRyJy1ZKy41iVkhkZDauS3zW7Hw3RzYrtfpgw6dYIWGX6+EW9RElxwU0ocT204h MkkC8nRoZznc+ReTPus0s8I9Yj3g/Ou+UDVxaY6ks8c7Mb4j7IJMyRqlxGxBkwcZNV22SwYWLMdl AdU4pgRVSqUapKZQJaKilPgWThitdmdMEBS05wOHQBcdIQhkSUmBDUtCR/wMFT88GcoLhpapryPq Cqp1g8sS9ZJ4azBjTHE3pvsywp9zHES/ZgUir+CMdmCk4XfogIlD4YyhPYlQzQFXgLwZSAJcTot7 r2hk84aWjUqTFSqBCbUqK1STt314u/5Ib4ZKliWCm3iAmAsyhCf5smHn0+nyCiNpbPtRoQgO19GX BEDz0pxAp6yvCd/x3xP6+1oowdYwkyBZjVhD0aLPmdopec/wxD4AIKUDkqZogLcQu2MLz2dlHbIi LKOZY7oecT0rYRpcoaHjgIIEaUj7zcb4JrG2klhaZPzduDIYBA0mBUgjoWOamUlvscAu3Ywcx/kV V5+EqO/CBkgaJ6UaFIx5Cw4CYcFw48CiX1I4FG2Ik3qEfUE0rxa9JTBgsBwKbAR0GhSzgdT28WbW VciEvIaEgzXDwUly5X23JqgZ+GTvQreOjTrxLlGLBdZJEMh0liqa9xJryzWYu7BGKclv3gJt+7F3 sKU6hYBE4wOvIJOTn+XCf+gxiQ8OVJZRNWPhrE/m+3noDrvoTVjlQ4+w/SVLaVow1PAjR1/oRAjl 0dZgnMQ94a1qfaRF9p6ooUjanMCw1KUYBYHBL1y9zx4DAW/JesuOPA5ycn2cWXWcGGZGvV0xHNGR 34N/idQZHeKJkIv/yMba8eMbazhjXlvDBIIqAeNyLBWoQm5BIV2nyAilOyZSa5acZtp2w1zuURe8 RWp7iIU2YF7575QKGQy9HT5kc1NR2B5A7A7iZJKzG4Tj3bJpK+bwjEXXgyMl5rbMUt3KJVIhW+0c pnUcpaupxLvQ+CI5SFmDfzeiyaaInCbp1bbPYGHontJfg5m4Tv1ZQx5XpOpDfvfiidS7FLso5xKU rJCgKKjDpiQ/0rM/AcpaSlw0geuFVcPgs1RLMejYEfY8oP72J2srSksJu4WlavYzxjGclmcQLG/o XdCEyxxGLyLF8CYjkylZVqwIlNjELfO2C8vfZSXb6Yvu8DHKrSAYcOu89YVaPZveue12pnPsjF9M SaaokuwOaeoaF6WVZFi95GJGDTirkqYg7zUISuSAc0kOlgVTIr7PFO3LAwkMxTnYv2tZ+WPGrA39 kp31FACVSjAK5CGYAQfu2BLvmRnVIVNhVCZTnHBRmgglzG1EIGgFZtmC7deqd4q17kjhu5HavRCa SLFySuidZ+gC9hRQ5qWyVQC/TuZrnOR3DOaEnn7AoIXTuviBsp7L7jCpLTHHCyQsrJsKChwLd4s8 fdYJS8fE95GxmdEJv323EJ+kY53q1Lm+1Ij9DB9h3m+CFjBleLsB1L6TZmLkBar1OfLZnOo7AUsa 5AZkoMLw1gyz+cJV2jVBAhgtD+RLUmVkekehY4kICdk5sYDinAi3Uas2QZPkSfJLOTFjTFbeiT74 1YphiXFnidX12EuRWDpmvSafmt5eZFqDOgBfSkVUQ44RFWSifQmjL9GuJ9NXnHWCMojHY1IS+Wmo eFWLYpn0JlJRTC/HE8BdDCA7DtaJyZEDV2TbJscHn8b74DMOjw8S/I3rUg/kD87QMvmRqyNB/Z9G J4cUs8lx0tf/6/ziTfJkcJxMKwD19vL1j/2j5Pry334+TOir4THDgK8Jvjxxxo/gE4cH/C6RIaGJ F9CZMC8GZp3wrEcH8svRUz/7p9Hko3mfvb2SSgr4Lfn1h73k7Owcz2TwtuAfDahsWwa85DcH5Wdv moMCrXu8BRrHJdLg7JcQSCM1yztiHFQmq/VYCG7FnqsKlYQOzjULaYT2cXfPh810k93u+ICPLhkX IOFQco9/hyFQBvCkVXXS945mxxgtxUFEi0nefTgCNT+dspPK78Nqxqo7qWRDP8ZdovqQnMKiC/OJ DNzG7g4e2fg7+VOK2daZngVJHzaT+J7UP28sihBvpEgxkdMuyHO1Jww8dOFBaalvWc9MQU6UzUj9 GRGWVD6CmRMM+mJ02UF0nzDKB8l7zpCi8HPwVeTWVjKDAEqij2IZaKRIDjcg5CCAVoFUthrEHg3u SVx7Mc1BAkTlaDDEQougpsF/h+hFgaxIozgSQbOaFMCPRskUtJmRYg8S1KeKI8ZwZB1GCU1Xq4Cx h6BmiT92thDMEub5rtz4cqxAqajap+W3DNsZSNmPoCxKyp0in60dUSDoSBCkIcdIfM2kzsZs0/Yw QUyDyaqQ8RxczdP1BslbzD+gcJwE1SB6HoFMoV5hWPr1nq/LEhYh+n7BFWcFVSNZrCvnL3ZIbr7+ 5ep8FydH0QBVT/ICWOdUHiPPoxzSui74rNlloUK2ZY1xDzRM3FE9+PiOcMGWj5pY+V2fo2M5OBZZ 2ydzRUgoxOf7AkOOuGJDVTdEoZRo9H4FzAbrT9kfw2lcmru8NCkeZlBb3lIkkHfb4Km6tYo9rqzn rP7a435CbyjNhDE0yejwTixobQ3vOAKFve6xp9wPglai+tl03WFxXdZ3uzwSO0PBwRw0x8Crwb21 K1MXyu4ERNJyfmrnyGfqSmEFQwHexIrSRRwpwS1D5w4dWc2LSehooTEOX3Zkg7AnHYRJU4Do8shC vXSiEd+u6MyhbDpRPc7YpvuwV5wDAHXElL4YiFAZjDpiZROvip+MTLX3ZZ4NRIW9VTvRvUVEjJa2 zafuUdq+2pJJl9vPGs6NvLwLfh8MWcrmEYdzMpgdb0oEJ76mhWMk8i3BEMLPtKoUMwOf7C4Ixh1x 3HZlBq2lUgdV0PT2ztzU6YqrICkU2JTTFv/eFcbErC96CxRVpaJFZnp1BoUNKM2G/m+LNi4XkbRg qWO6xA9ZCQMBP6NLDHbArjCl101M9uZOUxxAIGNZYa4vkiXP82XhpiEENN2I2hutBMClxUSZ8LEp 8uuj1HUzKSXvpOfB9hyh43EwJy7qZY6yF73fRpPbGaidRzZcnjy+4aKH0d5+uL5J3r2/UYGgSpZx zo4S03TMBSwgWGuheqHiYr/77LPYz+iBIT9znYLP/ztioRgg2o90Yjx4paoxPmzAO+dQcHJGzuAS 3i5aPUDFS4lLU6eB/KRRG85lsBm26XyagOG66I4Hv4ErsVw+RAxPXe2cwKTz5E4P7rF1F34ayRVY /aQ2zTyJQ4KDoLKLrR2VwCaxdV3WfeAFwLeUMHC1VSDEeY9EbFTAlGiK1s4ronxFWHE7QA3ULkHx W40eoOYiU4WrbriOcGIqjRKsMsmTRXoRRHKefhGbND+WsojMHSIRtTDoD/S2VMaBbbCr4R8SCo0H oDpWZQsG+Uy7YTlSqiyqFCsFuIBGAWxchdMWDzAWrl9dkmiMjQaCEMEW6Y32m/eWHPlq8pu3Maq/ 61bbk0kYmgRYehKbBV0z3GnIw+Rt9hktaff05K4znKye61L0lIQcABbH1fspC4DWcOo0mAsjPpwQ IkhnG31BNl/XRJsQj2NtVlcHhstkK0nTa/x2zxblcjbvDQYDJ8Q3Gk7iUzTOuQ7rzYhMyH7lAn4f 36qZv5rtqAc1ruH5pYuSOjOH38cgPQb+gmJxYIeOWehDRZJti+vlzl/11Wdni1pr5DEo4fgHBQ0u a4aEl5er5HDE/n9W3ItV1q+SiEY4znlxkIixdGGbSrjiErUOolwALlA9oSsBYtxQFGaXoXBGs+FC PfK9ey4O23OKjKVzkwBa2pz26YiWK/SP9iHClhJDil0rvSPKEaDTiUT/PlNQqquPBkRPe2qEh3eV 3sgwdlEd9ps8K+3qlmBA2nm2WaFhvABu00kFNlbdJhbNUguGooMyRyzdCYxPtQLKU5CrvGRwVHBy aB1RL5foSxmUAez4kS8YMNvm1/IH0aB4dDIpPYjy0+jkSHaNqEGmK/F7nSyVtJgtU5AxCIaClc9A 4uCyLsBYnNRlf5yXaHkivV3GH9l2Mnhs2+zpn1T4/0ZNJZdOoZYlYqZqlF9IgENDDZ7Z0HDQFlOX i5mnIkKQNFXqkTTHikVBP9NesAeh3+FtLs0N8MEy5BFi9EnrUjdYBkOlC8yLGdXiVkGGAUUDhthb tBBSS0ZJaCe6bGKECROrNMy50fz7PP8+T50VD78JHNdkiwzMHF+6iLvBRlHjTiJgXiqsXGlF+7CF CVwSe71GkcJPZUWK5qkT9EyxUu8qyUV2ZSklwJMnMBvoXqTUIceUwgLzwCLh+B4WQbgsGWdrKbtD lSm45UI3GRfglDo0U0sj/ryYQaFpPg6LDnRCg6Ee6eaTCVj+6gASyG1fz0kEcx021bS0wEaNRzel zYSiFyYlPOrJNeM2UE+xTFVGS7uIuO7lAl2Pxi5ITyy07A8zekEXCKr53ZhP461D8Shs59wGJHrM I/aBEmDD5Hgf0TdCD5P3rPFclmu/Dk9QyTpri65Ld+oLOiPCtbCWTgaUodyUaA4MwQltXg7HQAgI 7RoVC+v8XSkaNmUK93kH/e/QxGDOBVBIpmVQACxJFZcSpMMOQRKPgzFaMERgKFdnTQ1cIv2gMs4n kyOzMpmzeuOzDsSkRkm0JUovqIwRMx6yXKz+0vPL7PsQ6XORKtkCQSkbWfy/3Vxd/Hhzdfbu41q2 FigJqxlwbly7w7UGPViOAWlTVnOKjmP5FAze8wdaThnIdcbnC12JjrOR9BwkhqxiDhuza8e0FhVf CAyJbWbMCsJFlMClqJNbfZzvd/CR39i4sIV+qofm2Hj35SlUYkIgdm6u3pwnVL0hdiEfT4WHjkCp 3TS7QXEW/HPW0EA0SJo1kyV36BqXt4oPkgYb10IANBIJblquCPBSSMoDRhrXD/cti1XivRF254Nq jl8ZFFw2an0iER9X/IXPRj4b0WwI8E3p8gts0hFLxrNAKPazJOokF4TN6WTX4yK7DD0QI0lnJ0Y0 csyR/soRP3OYK5nbi8vmewUKhrzHB/1F2ugJ3oZLvR/VHHr2+OaQI3DSY23X2nGWTMfiCY5heWnI TzIFNgEJurNPosqjvggSgVFJroaP42l31h0pYA8l5JjL1Hl2Whm6vtcUOcNz67BT6EBWWCIJbh2V ooRlnmwqMTbKermItRwzQI3xcC6o7UTO1kk+onamoJjkg/ByL4grpz3nYvQ4wNtLdlBa6tTYiZWM sfNpab/5IEaGSR+T3nkLTA4FaxiO3ii1fhyZrAA5voOV4vI7aQ4/XUnxoaGCMQe316GWwDIgSmrh FNZYmoMvuwNt/2VUcRF88ffuovCziy67YBy2YEL1MTHSn6pV2y8qdRz4iM0KD/+hNZkVievBpBqa KmQt1qcFU2ESlgwSVvSgHiLqcRE4OSfqnE1ACwlxAkJi1KDb5FpAtBIpdcFyH3836jP7A5wBB8xt XlH3A4yrUNU7KVe2iHOU5bO5QNe5kO1CIHy4K9wIyXQF50WlNACLOMB8uEs4lAMjCvmjITpKLiXj 1LE0AwtZclIuY6qPMkbFBC9SCZiQkApTsXqieDIvgTvj8g4q8EIDI/IJIoHP3d8ixnfVhQQG14dN 46Ry0zeCkAZvWw/0sjd7OEheBVpBbD0fkhNEnOeMxHa9OwOIhluLO57eB0coMT6zd+MS8CoZqIyj 9W0sECF7jJaVVWVPVXGcs4YtduVn5FcAs35hPUFgUMLeDhg+CvQH2ocy167MxAmnsNiVa6w41BQc qwR41PGuxTamTBMwqT3OT7B9XLIFyzId7dsQcwCCLSvYzLMKOwdmnzuhPD2l2aFZ4oFt2+PoMerU qH7wnqT5NbbNYtaV5QXjv2+1aJXJFJ11RHpzB7rzMzmOjY0IMcCuc4uCaowA33IcgpfPFSg7VNBJ Z61TC6Y9zuY5A8FRUcco6bjWiSLbRdWr2wXY+I168sKOfJQQG/EzVlEG79Kcwu4Ze8nhjz/KUO7E WLx/AQKQVDBKcWVzqnY8kRYp8dmXuDzpcVqSHjyy9YTS8frtxc8P5Cd6lCgP3Wkb0XQO1u4SJ/kb PvWRrAp6HmFJ1FIClpbNMPWmqHgRFAIfPSb03yWuGDLkVXlRtBX5M1xXRooLB+JQR9CzQcfKGmnz EFR6iuK0PM9YAPv+nk5eu4h8xh6gJjoEDDslKMRI/2lebVEWM8cMHKJgfSIzYxGddE4O0Yx07g57 rhVkYDWKfGO1aSe5lM16EeyKylxgWsoMm17HAgtEwE+irGgeo8GBVv00jOrK1I3tkzdob02ukRJp hCAyqBEfg0sTAkQGr2BeknZQpK7KFnd+jiojJ+hGLWsUSxTtoLoKcm7Tu8IsgKnAuAqgShME4V7H 0FmhRwYxtY2SYI8XSM/76DX15BA6xPiNoxPvfvv4pjuEM/D7OIkOsgl58a6LCAnI0oBcznI+44Rh aB3OaMCQIg0FGBY5n4ZU7inYRYzpFhCKU1aKcK2iukV2shWcXkGqo3PV/k8JQElQPgeMc+fqQ8wH coWtdKZ6iGkhb/zG//0YEnJXP4f8HpdjKU02EkQJvGnwbzM97OzTe767TRz6CBwdQw40RY2ce6jR hXiZIS1pe1bZP3KosrBKZL1AhJB3NAjEsmCYPx8GX4grE+Ssr11hmOAzMGy27rCEeBsBcPP67OrV +1/fubB7qLxhIhrE9V1l2jkFhPh02HpTmQ8YVHSJc1koNg3wqXfXeqBcEnHhTQvBcRbeEMd2nDl0 Z4FQGbR4FiVTwSj5NXaCvQTHhLtPuVF9cOab6gykYM64vgzhVOXksfojPTylg00Den2eongXPmI1 ZTEk2zkKtm3FLW8Ii5hUe+C2dTlSd4BYTjZRzmY6AqZ0ZqYc5yqK6SF5v8fSmCxS8RwUspcvWdRC yfDJFpNRlR9qjQ282Em9cBQUKSROnD2OufPYLdjhsw/eg5tL7fW0RDuE1uzSDfHJ27l1pN0kQYlc 2PfbZQCoFkrzV5ldSzjwUfT8zgtBroWQAmpDlYYu/RU2x9LUHZXIym7FXSBpADr9TXdawGO00h1h Z6kSwjbGu4mrdZpaPILlJ3oEIt6jM3B5L38++9v+5dmH69eB6+yaYfpvE+3pj4bymlxy4lmXw/gX lPNHZ6KdMk6tKOVGjfECA6dINXInpelC466JvJpAVPErh/djRUXOEc/eqGhSksdjeVVLNh+wrZ62 BNUTivMsOI+LIpxFE5g+ZC5k2G+e21RR5CTGUxlWlCZ8MJ1nwE5fSrqF8qYF4fneN91LWXRKL5bX aensVSeu8dRPBpLXH9YUBFMMK1CArCsqlteUOnUVdEwotLpYWU41DM6ZZumRvjtIfuCSXGxKzici pUY3iW4bkUZoOCKLbAyH+gn0SJZhSBXXcJvp4QFKnOa5KgGOLjZeCHpN4EssKPzNUUMR80eb+eHt h5vX+x/e4X+EIc6KoLs/TJcek8qr4GmfCnFd9QkdrI3wiY8iK6hupaGPaP/lfXh9hE1GtZVeWckv /pYBoRDQf/SGFsO4ZDTFV7nqktWOa/7Ual8fPaJK8dcwIaRcVfAxZEYrN0LNohw6gSFqGDjzTZbg ii/j0fGI68JGQ4sjT7srVYqcri+EFZleCSpGuGnjUw53UN6cHycgmsMCM3wyr8sCo3YuNhoeLBV3 ZYWQtVNEFguGKCEbiUI5JfotQtAZ5l8t+giMyr+vFn1MVv8Jko8G+ibBJ4TzINHHcyg6G5TWZqV9 LGl7XdCvZ9oS/Egt8qO2cMpBQVy6pWJMJrAovPMY1s6f0EudhRLH3TG85pKdJUeiLYcQibe9NIk7 FCuF+jtEMGnrjYXjzcLx+vXN3y/Prs7evr55fSXTiT6jbSVP/v3lzcX7d9deKlo8mMAGKTyU4RVW jVcgUoAYhEa73BWE46jtTEAGZz4MIq74hmYrSXLe/+v1aWe+ddvgxU7TstxvVxlWTe7TgcohLXh/ ODiQl/nn/Nr+fpocjYbxp2zm9bFpQjs/TT5/3vg18thpEtwFss+L7LtFRq9d8e1efRRlp1snOpJt gI3o//X81E0bKSZ5/x9bZ+/4Z+E7SSoHxSjyKX6LRMTRac1SMGNjtYy67aIrfaUXzojP6TpW1bSJ Dsic3Tp9HxwJEIYd6JT/LML//rvjQXLp7sMJzZzAMGbVbtSHy+TeJz7Sz/YDWR6+AbSJGtmt5XLU xkARziVkpH5/E0dTrs4bHH9k60l9GXYRcVAej6FLZy1QCg0FzEAFsqNIflDhk1Pe8ZFiNuZBTIwU nNM2wYFIrHkS9K70VWldUWkasnd8MPQqPeiP2NPeOlTXtHaJElOJdLwCK04DuCW2drrthAjbTpak s9M/WZPamu0tquBvcLv9KUmtVzbafLRp/Q4yNFwhvS/bGAoZyiF2uzRy+DNrOoZxUCrpemEH10kF BcXiYm5IF5I+nFJSgiCAANVmVzsrPn7iesx3OuNKu4PNt7cFxzfUXver3BJXWZTObF0TzGDNLzJO A/HeKYKDtvoSvMbAE86Pk61hoQt1El0YhIhC5XGV8J/Qp5tsNM1ZSxFBvH2OfRZlqt6VaCcnDbCR WQuLQ24u7kIBgs8wPTeufmEN8yJSQtQRdUqHs0YMqB7fQNDTtIBpY7JbBxM3wlszS+OqQbUrmcik TkdtNjlNrs6xaVygw38Dvu+elmkDiJ13rp2eZ/hCzFbxwbhIAwBM6L43J1/5AsLzn9/DWGzRcYkw BiDZ3se58sWOJA52QwbPN6N5ISIdaZrNmrOfyb5maUAvX70+f//27et3r16/IsXgI/rYHIuQvYjR RvLcdeMjILIpXnqShsTEo5kEBSZcj1xYbsQbLFnU2FDxAHr8w6V8htFo/2HCNWom15LiC5GDuN7w uQyJiBrnUQ1nbfuSGudvo4oXdhY5/ECYUSUuGnBdcizp0sLo3A+fN6IELzakwKhGLG3VmfNWk/jB 2orcl31MyqKgKWFDmV6Zpz0N4JJztROrORbTbuO6s90Nz+Rt0QPuwIx0uiNzyFUA8uFLeA/PXNwp n67HsgNKdpsgNeiZ1pEGuIaF8tpkWT4MD5PlzvN7wMNcByJWBk4oTijqtsXo6NxT6O0Wri/LpCsB 5tHx+iKnbTs+H/eaCHsXUDyGLYdg7tplJ2GSHUVY2GaThc+8dYZNELDgr8Tt1XWySvUEiiWocdxC t3RS1tymPfUSxPE9Hl+Rggy30o461Ut9t9g+LnhDp3Jxv3i+Tqa1ZHdmC98xl1VCuO5pyQbw9kQb aSjMU5hogW67t+10RE5o7qGl1yO0BuOjNKQH+c9NU3Z9bdTyCefaz6byKgZ73JHe4CBWX5SZUdXJ txVy8R1/kZe0Fb5Mj8Nb02UxkRBLsPUSGpQgx7+ENlC4MKl8F11C3HZHYRynvsKU0CBJNoPZros2 0Wowl8c2hR67cfUxHSYNl9rj9/qSyOglczJj2CL3C9vCuehsmsKr2fDlUwebd1AG6MCMRteIZD+E s1YSrfHv4LZcoa+5eD56AkoLJta4ZD1tg5PB6gX0esjxQPNhsZQyFZBGWExwG5ZodTD3ohsT6WOZ Ru80udkoqpSwu4f70a/HEo8VVx5TqceGg/sagWEMlH0BzVvkvHBXxyrnuzjaRreKhweXeWjM8sIq uT/3+gFTsRGbezDQOSza/zJGQuGgaPkGjBCYEC3bMMJeI0xzwwIDVKCNs9YbRgCen73bMLNuZGwj 5tx2IDiwJwx1kqQccRRBJgy4biJZw4TJezduECTpqVzivR0eIhAhA923ZTxsuEWfvkiymzGwksMh YYsa4UOuCFMNwSSrB0oVOdLNPXiLZIur1tYYOr0NZiL2Ha3vvPbYvWeRU9855xRF4cF9S8TVBaTQ JT+1MwpHqu64kMx7fBe21TMqNi9+RAG5410ZcRQ1IhFMkuHS+QmlS6P9WXD6yQLbjXJLHBRXUz01 pxlY1pKyPFpGaFbcJw+2igLetc3y4EHC4P5N2CQINtOZ2wRl5a08/OUd2rQ5BOLrdijeHALwDTvE VgNq6KNYQ1+dXa6rZae0vl4rIzzPLAgDPvla1Rss5rGNnj+hAfSDDQN/Av/K0EnfMz7pS1Au6Zj7 NxgN+jwzCmD7Bfz/i/YB0ZhjAAComi6e2iVn/8XX7BV2pZ0V5LyoqECX7WU9FblJWIJWAwVji16J 3cLOHx/8911pgGG1o6BeJ8hA0JusTZXRaXKKgs6wZxrVLupp06yRs9R6HrVZlFzIRjD8vSnqctO6 WcQiCdRLuZUSeH1WBqY4ve6uosDMZpG6Yjl+hpic3y6w3NB3wEWS12Xw167Jr9xKFl5yRle6UOoe 717U9K0gubO16LPL0Zkv6RnZXPZTBB3RbvpZ7T7Yerj+6f2Hn199hf2AqBCuJwDrRgMta9pnOXZ6 eL8ClfHpzLDa6F6Mm3upN1hvsiz4PA23MgqQk0naye1lVnCbYSLaw65+BK32jk5YChNjn+cb6o6f FZLtcEe7ZClvz/7W2Rs+6S8IDuk0mxXML6RV6W6GIvXlNv938J7u9bGL4QQBmx5/0guiNaFy4ay9 N7C1NlFELTNYpC8EGWok+sITQTmBCO5HUCKS+teO/PUPKZFNpzhHn6DjE5cGG5FgZLQMusjxkgZb ABUxnJUWqfwUMMsb0pO9MPtLHWWbORorQtYaRCYlESS5JcUtNPIYue0HZ6GDd+SPr0tIB0PiIYtT oKyqtS8OTocHp6NR/zlGXV4Mnz17cjAcHd4Mjw9PDg7+d/zezWX/opiWp8myzl9snerz6CX8aezv LwDocDQ6HD2v24qGevL0yXD0dDhce/qxrZM/oUPxtRTu6Tk0FwnjuLOkvoWIOuTfoTwhTaZK1wdC Zb6FPbrrnhV1kVO5vlttIpcTxWq0Sum/KCmwCCPyUXYN8N2B4CPcCjWvtFkgDSmgO+Yk6mo1jDcJ Rj6apsflfEzdlc23Fhu9mTrTOnQ07GpWBdr7Nny+ppSa4ZJptNfceSLnvyur8vxRITUkoTK++wS7 e49hOxK+V2GPOdy0LI55NxkBmFD5fZmB6kXkiwSMq6emUnJI1YZrEU2vNFAddaOayfawJgPZ8S5c 4H8ARotyBeQ0cxex0/VOfHhWqxE1XK6tKMD4+HXuWlOQCSbHCrpTdaaIWAEEhnXkvsEzkZIUK/OU kssFhkUugsb9HgKpV9kTO6Eb5hu+rTZMyLuRK5cQAwh4UyyAoKpJXglu8g6pG/oOFzlN/L2MOv0a q+yI/Hapt7e3BwgM3xJRYnuC4k5EO85NwnIOzpqGx+SYqgx39UUTN/fPsHqAnDeiUywtaRuXj8CC 9An1fjwTWo8QjQEzmlS8I5zJE3TQmJqz4R8nR5xu1htuS+cds0I2mqqTAeWcgmdeOnERtblhNgTv fMXsh6ljOYgerjvOxskdaqgdEBhCkVG4U4lrsMcnF6Prh5M8q/oij4oJ73eYt/B3uhJAWdB6ixsC Qf0lrrm/CwhZ8Bc5IEA5MRStdLweH3fdAzCVjCUj6COLbNXDu9LVc40w2nnsewQXzjlLbz2kSKyy qxfTIH6WdREISVwIdlVqWy/m5WqURVlkIHU5Cr6oltL8mVP6IoOOfZKAIiOip874fpICN3rOne6i +AlahkmP1QtdQz+3kogO7jmkuPTaa4FBKZSoTVKjtKdXWO4MJx/uxyuCxtJTWQopdoNzgR0Dj8CE dQ8PtBlDc5HJzIGMoHUMx6xwxs6aaRgpHbUPBd9qk0XY+lYz8TD6+D/ZaPuCySZPszn8IAv08LHN usfu30zT5uqIqNhEZU8svfmgRLTPWom2dvtVpM0x1ORcVRROacqHjtzjrIEDsZxR6HqHeprueTkL 7L8rwjZUAiSzRSwkrvP9Npm0xtjc20gO9BIEH7tXaUsyceLvclRu8yEcOf/pLifRMzEGEwAzIjwR pGpYctcaih2E3c6CEG8YNyXNot3No3VuyRWtBQzQVvFlHg7rsAT23RstwXVdjF13CfornI0reicg rmG+W90GYuHzuH0JmWzKu27M9FD6PqiqYJkL3zkrrC8L6TQIXG24k4CLuLtnSR0y/JmXSopwUzur DWLEnTctuRCIKtK5z3bWxvZKwurpKKod47j5kauZ4oKytZopYsavrlIKCpQIzLS2TBbkxfjqhdDP 0LSVdAH0rXs8gZ253gXO/GPbV86a8K3uGNRsk+FB8ha7/yLDsMYXfcrXIRfLxZh11KbDomjS+lAZ 9ec9liSFb/GjflDj8mxYe0J2X3TP0E+vbn5h1+j4f0gBMbcx1svKwBhbVP2GLr9h/4uephuYpFFw D7d6WfXUJAiasIWxVHAKXBfzBnuFKL74iI87veMLf5jA+Is1Fte+StiVNGyFQgh5SvjdS47lv0P6 rxy8lxChNA7law5M1GkqvDtyUdZkuamEUK8wWifvimQhrPY06vSij00yxEjcIBKjm3wAWRgJS7a0 B6LLW2eNUjDvFrZrEjmyjUojUhaGh9/ANFEojlw6hWVZ6/dFGI06Qjg+y9oOI+1I685dMaR1Chvt ZHKiGqZWAhE5NAGT31+PyCIb50FT8IOyrFs4cRhkn7ntLPU0iRKHRFuBq80rAz599f4aIWd8odvu c73gR1sWUAhCrHWKZIT5bdkxmvD8rsL9oeP2HbR0ne+4qTo4Ipmej3v8MNhj91RG+T2K5HengDBk aX6gtaZuRPLcTzx6aHJNKoi3lnm1vINu7K4GrD5c/ZzsaIlbtg5gV7Pf4bxgd9WZ2fS1BMEkmjMO SvzKmv9kSRaaI+H7m6JB99S4yf6vw7mnyG3Cd8I648zhkoBwXE58HokNUmpCZCyfjjZFEN/DrFWt /SHNhn3g2BMdjugEBmVK7JBFRq00kgnEOcZG4igFhkVCe4mXXjqPtFtpznXvPnEjYMba1kiQxqar ifps+eO1G3aLCCja6xDtAZRY+OpFIVqC4IsQ6YiXNE4hCVWI0gt7ZvBJ3lRTaYGWbOl8jzu2xRmk QNe8ZqNk04G80MT6Vl/0qOPhPsznO5LZHA+OuS8Z3u2jNwGc0SdBQXNY4+urdb2S3ZHGRaLm4xtF Sq1/1zNXNbcLvb9urNPE7QtTAsqgem+SQSjd/Yx0MgRm+4y2Fpv9wYlQaTGblcGhz28b/mSQvK+s 9HqlzTqRBoLR9YEXRJ7IzhsPiwWt3wzfJUV774I5UW9Bv7aXGhFq5z5ymPmOf0BrL3cfWzU+dn9d lpacjsn4ViFtnxaGFnCl5DkZovaXuyxJIyeMYrSezPQanlYpTGWpdx/EF9fbWFQB+JtT8N2Xidvs EbcujDf3mjuco1mLx+uD057BF5qucgGCnZe7Qetml5iZu7tsEG9R6+zgDLxcgmK4NztBkHsvNDLO N2Kng8EA9a48vwAC00g7ayWKxL9EALKUzsZJnoxMckQh9uylupXcmluyGui0H+76S8+RntyLyGtr S2kLgvlv1o146r+7L4LwXwOaWOH5PdorcACWku53F566O2uYicKZhKVx61fKUBkJTqiQJr74cEQ3 BKWQeEkgOfyt7Ioj0Uo+AtRKrygCEa9Y4+E1WPHty909gIGuKa9VuznbdB8jJagAESMs69huQP9K 1wyq267g7f2qLj93LhZrFBUng0PqQez7r7lySImV41AB3tjTSGYl1kSk1rBL1fjD1obgjaltdVCR bekaCIIRHOaGwcJ+MCJlEYDrrS38gSkwJAlV+AZPfNKxNBhHW/ijr82lGjTaFCRGyfcTY5+SBbkS rkqEwGj5cHDmT3w/bePVxzNsYZqSd5UME9qUwmpdZcHZE9eI5WXynpocJz00GZa9l8FNw1lT/KUl U2KZcH0Xm5ZpTably+DMHwoD1zNph7BLGR28bF0spqokiQUzgAmgDOQ+IKFjhNYlyPiWbc0eOhCu 6QQH0hBPk7VLz/ltPQUnRIYxTrl08C6ZL2umaoG2rF7eO/YWxkNf2pPlEd24woeR9YIW0iGYnshz m/ujxsICN/7gtbOY189j+vKkdX+AVxrZxtwlCPgvL8tPmGn7hBQumfQZmQ1AAC9xCk/wauFNt/g1 foJ+H+U0OQiacpL5QhstQ3AcaIixSw2oUIst61PrrvMLCmBkDsZRvnSNxB5Vy48euw/sE7CKYKPp bLv4CIuscTHxJAlw59ultXMYQQ7rjW3gz0bd084N82XrI9Zh/GfDWSwsyAPR7JyTmjoVkxHKUSsi DLcuLljhcKS3vnYl2UsQOvfxBFGYIG0tp101oMGzXqvN6B0fHFIVHhZlfChcdLOX7GhFyN0uOnG9 o+FJcsXQrIhLynzhvJJroMlmmsmboHRAQgP6OMuLE1t3HNXjE5d7oP0tHFoztJhaKwWi7vYX/AtN 2J3bTJjr1evr86uLH15rkbkeVUV7piQMLwvqXSdyhmw5Cps7Yy7FnHODJQFf3msnkOAPOtVIYV1X /qLWHmsCPIuLZGVlRzm+Sbagu52Gs8mywdHeEgyyQ6KALbUN6LA0ZX7vXPtRvCcvsFVlg1euN5Se zNRZc0xADi5yxAasuV8zvWJgbbwgoyQ1nBwyC+47npR6vYrv4K3yvy3LvBElihKtrJuHo14i5IT8 sPSo0WiLu1JUsiKy/jAMtG2IKXFMQSkcHo2TCY7+HNAIs3QoXqKlJnllCwxmv5861jprW+rUJNTM 9xu5LXbB3k0pHz83VADUTiwImKsq9PFmt0d7TO/jOyb3cK0Z3YsttjmBCKtIum8otfjsCMwEVA67 qSG9d3OydPc2/pqIUaug2rKlaEyNjUqr7oXE9LJ0RkAhDbY3YawMbnLLKA84NnhXBXE0nfgGupL1 yD5qKQGfHA5KQpYV0Y9+7W9ZYMVAyGeFgNpyyk1HsbgBQ09VlZM+71zQ24Z3oHU5Rkl/gRb7DAP+ V2/OR4ejk8R1uznxXTQJxmyZpXSVXFloH+TwmgFvwISUTXJUkRRdEtO4HDkF2a3PpLhAYI4dTeRh vXfQbCAAh1VyqVzShokAI6hBg7WajiRsgrLuI+NrLDnJlovyNk/AI1a1rmnrjlrXf7A1LW+fs/+9 nuSG5o6/tOTIR0AUKhfBUPZ0t1tehm9S9RkVhGaNu2F45WRmePnx5uuaWr2YjBqwz10Z1cr3zqH7 TSgHiIAHj298/QldaemfNxrXrYN+OnGjGO6MJCwJO1KHMrGbZA8YuQ66v1OgnGwmvAEo5eOsAQOC /SV9O4JUA8sCdsLJQfnCEVZuOetvPjR065dkwui2dVK9ZChlhU8nat2J69keFywQqfQaMwWjSU6h sBb8/run2Ng/qi8NDX65YADvB+bAHRLSJ+B8rCK8sVm+l/yHQc/0yqRmL/kbZmev4IPin5p4wfW8 yyZlDpT2yuZmDnQnYStOnk3rZdZiRk2aRXOqVR1lPpzR8onFZyDJLNH5JLzZ8Ldfs3Rh649CKGd4 9RPe61GSP9l/UwMOUti8c+8dnrOI3Ev+XQQag9hLrvDOlwLX8naQvDXLW7uXXLx+/Tp5J0bUW3PX //dlgc7EwVCvo21bDKmvVquBK9r5NABbkENvgA7we7LFILX7/vv9Kjvar5Zj7VTX7OfZGK3gfZ4L wjeDKp0GC/2l/EcBYnvCS30vvJzDuvr1soiKcUApEdg+xzLI9hKMytJhgQoP8fC3QfKzTX4ol3Sl +mVdTvg+du6Ac/EjBi3/cjCSJZ8tZ1iBOXzWHx0iKuDzy6xtm/GyBnPgEpToXX5rwDjZSz5cn63j yUwWg7Ke7TfZDLdY/4uQ9isDwrnZ1xV0cPADsI7JdbNfyUUGPwRLvwZTLb/rX3FFFEbozjtxE9l+ oONZCf7sfNHsJa/AWSbQe8lP+GtuPtVA9oUp9pLrQfIG7NyUfiMI16CNPyHBbEMU0IbgaPSkfzgU crkGhn6V2VkpGDkHkQsE4fH0IBQN96vRkGlrTFPuoAi8acVP0iFP204JaD2d7INVMHz69Nmg/UxX lSTB+9chgHveR6vCvc8vY5fsB758MjxZH9xdRPPF9w8Pnz7l9/nNmzdX5w8b+fDoKHqTrl7Z+Obq kN67udpvFlk+OtinToiDebvIgzXr/Qzx+4vKzgatzdE/AVsnB91jxgP4Y19vIWnoGd7JI/79CGEH oOPLcR5dKf8JzVMD7B3OqorwN22r/baZ/b0x+7/+ePT38/evXp/v31z/eH3099Fo/1U5afavjxgP B6ODo4Mng39mVRcL2JN0TZA8aIjjzhCHIGaOcIjEhWiCUx20sk3UkwmW+iliqdmn/0jtugVPFjQ7 hkT7i2Vr+wcHIW3zj9Cp3pOafMtIqVl9yooGbIhshnZEH52Tpl204YikK89IeTd/Sc7SFA/YaFHd 5TzLs6qyiRJQ8GmTvL08eqd3kh0Pk3oJ4tPUrhT02Wh4fJJcY+P7Qr2HNzX5DvS77S9Mlp8mlQwy mPEg/8YfNEj/inPFCP7z/Xea3zsFDRwfn/KEwOlsjcNsyGXfl8TWouVrPTZR5RircbEKuqd9IvcJ BHc0nbJ7S+bgIc+Dy+TE8NvDEBMmwT9xIZr8RkbMsfy+BoFy7h0IDkDwPv0qE3/3A00lrD7MilsQ LKn6+76c1bS+jjeLKuykaIOTbNJVXj2wjd6DXj5iNCmH4qx1FRXgU2E+CH01rcO6SyIv96H1Aptb /t6s9/RNq41P/uyaA3/2FEY/ty9igihf9JPR02cHT4+ORkDO/Ovo6cGT5OJdcnF5lAyfjAagnUaD Z3ENfvOCRaLeTxJ8lb04K7QGg2Pa/sHkA8XTKHzfkaaPLdH/hE6c+mNeiPF4us540YPti4MkRnj0 x+IF88+TJ6MRhv73z365TJ6ddMaq22phqtNnJyiSfum/vt4Hzjp48IT2aYyYpMYvzq5PRwikMx/m RpjPkZ/Pky3zeZKgoj7qg2CzsFn7R0cwr/3RwyfG5TabJrY2L4enEz+vp1vm9fSP4Gm0Pp3hA/H0 bMt8nj0KnjZO7EGk5VE2XEOHzBFF9R9A2uH63I4fhLPhwXDbhIYPwtp00fLDrEAwp//i+DkG9bBH ZJ8uQepn6YshfIglAS/Ozs7783H98AXSrDctMIgOcLeGBOuRQBVJc0FSdBJ3MP6aBYqaaHtVguCT 9u7MVsMJ4qiUCc+4SMqiWzZOYPAQYONUETdQlPAol/+5PqquRI8ibkEQWMr3OVooqR0MJxepr60P ojp83oa6ODCAJbXFQBh6Uy/FoDjhQOE3ij/RxSyfM/D+sT3JSK73Elyg6RU0sMbOMVI67kOhbCzE 9fY0khoEPgyoaOQgFlcyypEUqiciFBMMjlJq01CqPUolpY7h+WUe1mdR/JHDWb5uh8CUhYuDuVoz WcGGoBe3rtJqaUPV+QTGryCsVwmWLIRgH9jKL+qjlDy2rn3sVo+JnlzgItJGCVkzM1KOf0+3PYJx bxNCKZL1Tf+Fx93VDZjM/ZYa0VhG3Sh3n6rUe74swIBr2ue8U3/HL188Banbh3/8gcKHGot/bLj1 DhXyw6jmp5/h088OOsJaTDowV0eHR8cnT54+FIVskNyHwsNvXNMI13T4dbMMc/fbdO99cz36xrke 4VyPvzTX8NsH8PnXLY4tnvsWd/yNizvBxT35L10cK+77FnfyjYt7iot79l+6ODa77lvck29b3BDF wvCLjB5++zWLe6hQ+2MC4KFC7QiF2hdZ8HFV5WM3CPxKxP4xafVQxJ4gYr/I/l859T8mix469ac4 9S8y91dO/Y9JmgdOfYg6+sus+5VT/2Ny5KFTH+HUH6a4b+Y2aoia2gnVb7R0gDfqnkjmseR5Nx3Z pWijhBuTncK5VqagQ9Loqs0wX4hFAmHkUJ0EzolTb/2g0FdFOB0l+7rIbCxZpc9FUbUvDvqPvK1P HwTvPlyzye2RTQeuHTbhidFQjmrTB+O7oDInCvr6QMEfbyn3NVr5kS49e1z18Cd0aNOfr8fQN9LA 0NPAyVYSiDIHDyeBL/sOnajYH6QBjW99JXt9aRLBd+sY3/jH/wFQSwECFAAUAAAACAAQaFQu05dO uItBAABO3wAALAAAAAAAAAABACAAtoEAAAAAZHJhZnQtZ2VudHJpYy1tbXVzaWMtc3RyZWFtLXN3 aXRjaGluZy0wMC50eHRQSwUGAAAAAAEAAQBaAAAA1UEAAAAA --0__=4EBBE671DFB400C28f9e8a93df938690918c4EBBE671DFB400C2-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 04:36: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 EAA16269 for ; Fri, 7 Mar 2003 04:36:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h279m2k03324 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 04:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279m1O03321 for ; Fri, 7 Mar 2003 04:48:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16246 for ; Fri, 7 Mar 2003 04:36:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279lJO03286; Fri, 7 Mar 2003 04:47:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279iXO03148 for ; Fri, 7 Mar 2003 04:44:33 -0500 Received: from fgwmail6.fujitsu.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16082 for ; Fri, 7 Mar 2003 04:32:36 -0500 (EST) Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail6.fujitsu.co.jp (8.12.8/Fujitsu Gateway) id h279Ydfv017161 for ; Fri, 7 Mar 2003 18:34:39 +0900 (envelope-from nomura@swan.png.flab.fujitsu.co.jp) Received: from n4.gw.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.12.8/Fujitsu Domain Master) id h279YWMZ022755 for ; Fri, 7 Mar 2003 18:34:38 +0900 (envelope-from nomura@swan.png.flab.fujitsu.co.jp) Received: from flabmail.flab.fujitsu.co.jp ([10.0.50.61]) by n4.gw.fujitsu.co.jp (SAVSMTP 3.0.0.44) with SMTP id M2003030718343804137 for ; Fri, 07 Mar 2003 18:34:38 +0900 Received: from flabmail.flab.fujitsu.co.jp by flabmail.flab.fujitsu.co.jp (8.9.3/3.7W-020624-Fujitsu Labs. Domain Mail Master (NAVGW)) id SAA04273; Fri, 7 Mar 2003 18:34:38 +0900 (JST) Received: from swan.png.flab.fujitsu.co.jp ([10.25.165.10]) by flabmail.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2003030718343727563 for ; Fri, 07 Mar 2003 18:34:37 +0900 Received: from robin (localhost [127.0.0.1]) by swan.png.flab.fujitsu.co.jp (8.9.1/3.7W) with ESMTP id SAA03346 for ; Fri, 7 Mar 2003 18:34:37 +0900 (JST) Message-Id: <200303070934.SAA03346@swan.png.flab.fujitsu.co.jp> To: mmusic@ietf.org From: Yuji Nomura Reply-To: nom@flab.fujitsu.co.jp X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 07 Mar 2003 18:34:37 +0900 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] A Framework for Internet Media Guides Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, We have submitted a draft: "A Framework for Internet Media Guides" It is available at the official website. http://www.ietf.org/internet-drafts/draft-nomura-mmusic-img-framework-00.txt This draft is an update to "A Framework for Internet Program Guides". Abstract This memo provides a framework for Internet media guides (IMGs). An IMG is a set of meta-data describing the features of multimedia content in order to subscribe to, manage and exchange multimedia content. We present an architecture, a protocol model and IMG data model for several scenarios. Feedback is appreciated. ---------- Yuji Nomura E-mail: nom@flab.fujitsu.co.jp Network Architecture Lab., Fujitsu Laboratories Ltd. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 06:59: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 GAA22591 for ; Fri, 7 Mar 2003 06:59:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CBMx17046 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 07:11:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CBMO17043 for ; Fri, 7 Mar 2003 07:11:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22417 for ; Fri, 7 Mar 2003 06:59:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CAwO16997; Fri, 7 Mar 2003 07:10:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C4WO15677 for ; Fri, 7 Mar 2003 07:04:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21084; Fri, 7 Mar 2003 06:52:32 -0500 (EST) Message-Id: <200303071152.GAA21084@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:52:32 -0500 Subject: [MMUSIC] I-D ACTION:draft-levin-mmusic-xml-media-control-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 : XML Schema for Media Control Author(s) : O. Levin, S. Olson, R. Even Filename : draft-levin-mmusic-xml-media-control-01.txt Pages : 9 Date : 2003-3-6 This document defines an XML Schema for Media Control in a tightly controlled environment. The current version includes commands for managing of video streams only. Implementation of this schema for interactive video applications in SIP environments significantly improves user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-control-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-levin-mmusic-xml-media-control-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-levin-mmusic-xml-media-control-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-3-6125054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levin-mmusic-xml-media-control-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-levin-mmusic-xml-media-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125054.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 07:04: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 HAA23222 for ; Fri, 7 Mar 2003 07:04:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CFgi17503 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 07:15:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CFgO17500 for ; Fri, 7 Mar 2003 07:15:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23209 for ; Fri, 7 Mar 2003 07:03:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CFaO17484; Fri, 7 Mar 2003 07:15:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C61O15765 for ; Fri, 7 Mar 2003 07:06:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21422; Fri, 7 Mar 2003 06:54:01 -0500 (EST) Message-Id: <200303071154.GAA21422@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:54:01 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-12.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 : SDP: Session Description Protocol Author(s) : M. Handley, V. Jacobson, C. Perkins Filename : draft-ietf-mmusic-sdp-new-12.txt Pages : 46 Date : 2003-3-6 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-12.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-new-12.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-new-12.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-3-6125346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125346.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 11:28: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 LAA14615 for ; Fri, 7 Mar 2003 11:28:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27GeUv10631 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 11:40:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GeTO10628 for ; Fri, 7 Mar 2003 11:40:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14594 for ; Fri, 7 Mar 2003 11:28:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GeBO10582; Fri, 7 Mar 2003 11:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GdVO10408 for ; Fri, 7 Mar 2003 11:39:31 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14433 for ; Fri, 7 Mar 2003 11:27:25 -0500 (EST) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h27GTNxo003745; Fri, 7 Mar 2003 17:29:23 +0100 (MET) Message-ID: <3E68C8C0.3060204@tzi.uni-bremen.de> Date: Fri, 07 Mar 2003 17:28:48 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: csp@isi.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC at 56th IETF: Agenda and Draft Charter Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Please find a draft agenda for our meeting in SFO at: http://www.dmn.tzi.org/ietf/mmusic/56/agenda.html http://www.dmn.tzi.org/ietf/mmusic/56/agenda.txt Please note that not all drafts have been posted yet and therefore some of the links in the HTML page are invalid. This will be fixed as soon as the drafts become available. Please direct change requests directly to the chairs. Also: Please find a first draft for a revised charter at http://www.dmn.tzi.org/ietf/mmusic/draft-charter.html Please note that this is a first cut and has not yet been agreed upon with the ADs or the IESG. Also note that following discussions with our ADs in the past, conference control is *not* part of the revised charter. We will need to sort out where this work can find a home in the future. SIPPING may surely be a suitable candidate here, but this is entirely open to further debate. Colin and Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 15:54: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 PAA01948 for ; Fri, 7 Mar 2003 15:54:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L6LV07726 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 16:06:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6LO07723 for ; Fri, 7 Mar 2003 16:06:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01862 for ; Fri, 7 Mar 2003 15:54:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6HO07665; Fri, 7 Mar 2003 16:06:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Km2O05866 for ; Fri, 7 Mar 2003 15:48:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29469; Fri, 7 Mar 2003 15:35:51 -0500 (EST) Message-Id: <200303072035.PAA29469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:35:51 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-comedia-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 : Connection-Oriented Media Transport in SDP Author(s) : D. Yon Filename : draft-ietf-mmusic-sdp-comedia-05.txt Pages : 14 Date : 2003-3-7 This document describes how to express media transport over connection-oriented protocols using the Session Description Protocol (SDP). It defines two new protocol identifiers: TCP and TLS. It also defines the syntax and semantics for an SDP 'direction' attribute that describes the connection setup procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-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-sdp-comedia-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-sdp-comedia-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-3-7150844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-comedia-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7150844.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 15:54: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 PAA01961 for ; Fri, 7 Mar 2003 15:54:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L6N607743 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 16:06:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6NO07740 for ; Fri, 7 Mar 2003 16:06:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01867 for ; Fri, 7 Mar 2003 15:54:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6IO07697; Fri, 7 Mar 2003 16:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KmBO05871 for ; Fri, 7 Mar 2003 15:48:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29501; Fri, 7 Mar 2003 15:36:00 -0500 (EST) Message-Id: <200303072036.PAA29501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:35:59 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-03.txt,.ps,.pdf Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne et. al. Filename : draft-ietf-mmusic-rfc2326bis-03.txt,.ps,.pdf Pages : 5 Date : 2003-3-7 This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time proper- ties. RTSP provides an extensible framework to enable controlled, on- demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This pro- tocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7150857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7150857.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 7 15:54: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 PAA01963 for ; Fri, 7 Mar 2003 15:54:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L6NY07759 for mmusic-archive@odin.ietf.org; Fri, 7 Mar 2003 16:06:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6NO07756 for ; Fri, 7 Mar 2003 16:06:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01869 for ; Fri, 7 Mar 2003 15:54:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6IO07713; Fri, 7 Mar 2003 16:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KmJO05880 for ; Fri, 7 Mar 2003 15:48:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29527; Fri, 7 Mar 2003 15:36:08 -0500 (EST) Message-Id: <200303072036.PAA29527@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:36:08 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdpng-06.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description and Capability Negotiation Author(s) : D. Kutscher, J. Ott, C. Bormann Filename : draft-ietf-mmusic-sdpng-06.txt Pages : 47 Date : 2003-3-7 This document defines a language for describing multimedia sessions with respect to configuration parameters and capabilities of end systems. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdpng-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdpng-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7150923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdpng-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdpng-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7150923.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 10 10:12: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 KAA28592 for ; Mon, 10 Mar 2003 10:12:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AFP6X18547 for mmusic-archive@odin.ietf.org; Mon, 10 Mar 2003 10:25:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFP6O18544 for ; Mon, 10 Mar 2003 10:25:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28582 for ; Mon, 10 Mar 2003 10:11:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFOxO18528; Mon, 10 Mar 2003 10:24:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFN7O18415 for ; Mon, 10 Mar 2003 10:23:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28237; Mon, 10 Mar 2003 10:09:35 -0500 (EST) Message-Id: <200303101509.KAA28237@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 10 Mar 2003 10:09:35 -0500 Subject: [MMUSIC] I-D ACTION:draft-gentric-mmusic-stream-switching-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTSP Stream Switching Author(s) : P. Gentric Filename : draft-gentric-mmusic-stream-switching-00.txt Pages : 26 Date : 2003-3-10 Stream switching is a technique used to change the data rate of a media being streamed, typically for the purpose of adaptation to the effectively available bandwidth of the network. A backward compatible and independent RTSP 'SWITCH' command is proposed in order to enable RTSP-based stream switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gentric-mmusic-stream-switching-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-gentric-mmusic-stream-switching-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-10102150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gentric-mmusic-stream-switching-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-gentric-mmusic-stream-switching-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-10102150.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 11 12:13:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28344 for ; Tue, 11 Mar 2003 12:13:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BHRPA15078 for mmusic-archive@odin.ietf.org; Tue, 11 Mar 2003 12:27:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHRPO15075 for ; Tue, 11 Mar 2003 12:27:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28302 for ; Tue, 11 Mar 2003 12:13:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHRGO15065; Tue, 11 Mar 2003 12:27:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHO3O14936 for ; Tue, 11 Mar 2003 12:24:03 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28208 for ; Tue, 11 Mar 2003 12:09:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BHC2wv009316 for ; Tue, 11 Mar 2003 18:12:07 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4KKA8Q; Tue, 11 Mar 2003 18:12:01 +0100 Message-ID: <3E6E18E2.1040906@era.ericsson.se> Date: Tue, 11 Mar 2003 18:12:02 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG References: <200303072035.PAA29469@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-comedia-05.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have some comments on the COMEDIA draft. I still reading up on this so you will not get one of these 20+ comment letters that some other drafts has got. 1. The draft seems very directed at SIP usage only. It does not really describe how to handle comedia in the context of SAP or for that matter RTSP. In SAP or other uni-directional use cases it will be required that the SDP describes a passive side as the server can never connect as it does not know of the client. In regards to RTSP the port number MUST not be 0 comes into conflict. It seems relevant that a RTSP controlled server actually offers a media block which uses reliable connection oriented transport. SO this needs to be addressed I think. 2. The security consideration chapter seems to be missing the important hijacking warning. If I don't misunderstand section 4.6 a passive side actually starts sending to the address of the first received packet. This is very unsecure and easy to hijack. Should definitely be addressed in the security consideration. 3. IANA Considerations. This chapter needs to better clarify what exactly is registered in what registries. I also think that the definitions of the new attributes should be done better using ABNF of RFC 2234 and draft-ietf-mmusic-sdp-new. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 11 22:06: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 WAA24265 for ; Tue, 11 Mar 2003 22:06:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C3KN326483 for mmusic-archive@odin.ietf.org; Tue, 11 Mar 2003 22:20:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C3KNO26480 for ; Tue, 11 Mar 2003 22:20:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24251 for ; Tue, 11 Mar 2003 22:06:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C3KHO26470; Tue, 11 Mar 2003 22:20:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C3HdO26270 for ; Tue, 11 Mar 2003 22:17:39 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24136; Tue, 11 Mar 2003 22:03:22 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id OAA17410; Wed, 12 Mar 2003 14:05:22 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa004G0; Wed Mar 12 14:05:12 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 14:05:14 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id GS4QSXT9; Wed, 12 Mar 2003 14:05:02 +1100 To: magnus.westerlund@era.ericsson.se Cc: avt@ietf.org, mmusic@ietf.org, Conrad.Parker@csiro.au Message-ID: <3E6EA41C.3010504@csiro.au> Date: Wed, 12 Mar 2003 14:06:04 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 References: <3E66AF6D.7040106@csiro.au> <3E671F9E.7080706@era.ericsson.se> In-Reply-To: <3E671F9E.7080706@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [AVT] new I-D on temporal URI addresses Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Magnus, all, You wrote as a summary: > I can see the usefulness of this proposal, however there is need to > resolve a number of issues: > - A general standardization or target certain URI schemes? > - Applicability on different media types and protocols needs to better > understood. > - Use of fragment or other URI syntax element, like parameter or query? > - Need for having ranges? > - The actual need for general parameters? Great to hear you liked the idea. Many thanks for your elaborate answer and well thought through comments, which I am very happy to address. 1) General mechanism questions, applicability to different media types and protocols: > First is the possibility to specify this as a general mechanism. It > seems that you want to have this to apply to all URI schemes. Is that > really possible? The question that you are addressing goes beyond whether our mechanism applies to all URI schemes. In http://www.w3.org/DesignIssues/Fragment.html Tim Berners-Lee states as an axiom that "The fragment ID spec for a new MIME type should be part of the MIME type registration process". This implies that the meaning of a fragment specification depends on the MIME type of the addressed resource. Therefore, the interpretation of a fragment has to be specified for each MIME type, and then probably again for each MIME type on each different scheme. Our I-D can only propose a generic way to specify time-offsets for time-continuous data and we are proposing it for http and rtsp where they make sense. As an example take QuickTime files. Apple registered the MIME type video/quicktime but the documentation does not have a specification of how to interpret fragment parts when the files are used in URIs. Our I-D would not automatically enable timed fragment offsets to be used with QuickTime files - it needs an active move from Apple to change their MIME type specification. The same holds true for RealMedia and WindowsMedia and any other time-continuous MIME type. In fact, I believe that no MIME type registration except for text/html includes a fragment interpretation section. > How do you know that the use of @ will not collide with > any usage? The "@" sign is a reserved character in the URI Generic Syntax (RFC2396). It is allowed as part of a fragment, but its use is reserved for special cases. No special case of the use of "@" is know to us or published with IETF and therefore we asume there will be no collisions. > For example the rtsp scheme does not define how to interpret > the fragment. So this is up to the server responding to a request. So > this can potentially already be used by some implementations. As this has never been suggested before, there won't be any existing implementations that use it. Streaming servers should however find it easy, to support this mechanism as they only have to copy the specification after the "@" sign into the appropriate rtsp timestamp field. > So a general question, what is the actually possibilities to standardize > such a solution? It needs some minor adjustments in the URI standard. As that standard is currently being changed/adapted, this could be the right time to get it adjusted. Then our mechanism can be provided as a Generic Syntax proposal and MIME type specifications for time-continuous data can elect to support it. That's my take. 2) Questions on "fragment" definition, ranges: > Second, is the usage of the fragment identifier. It seems that you tries > to redefine the meaning of the fragment identifier. See below. > > From RFC 2396: > > "When a URI reference is used to perform a retrieval action on the > identified resource, the optional fragment identifier, separated from > the URI by a crosshatch ("#") character, consists of additional > reference information to be interpreted by the user agent after the > retrieval action has been successfully completed. As such, it is not > part of a URI, but is often used in conjunction with a URI. > > fragment = *uric > > The semantics of a fragment identifier is a property of the data > resulting from a retrieval action, regardless of the type of URI used > in the reference. Therefore, the format and interpretation of > fragment identifiers is dependent on the media type [RFC2046] of the > retrieval result. The character restrictions described in Section 2 > for URI also apply to the fragment in a URI-reference. Individual > media types may define additional restrictions or structure within > the fragment for specifying different types of "partial views" that > can be identified within that media type." > > Two things strikes me as not being taken into account by your draft in > relation to this quote. The first is from the first paragraph of the > quote. The fragment identifier is interpreted by the user agent. While > in chapter 4 of your draft you clearly specifies that the server shall > interpret the fragment. This redefines the behavior of the fragment > identifier. We are aware that with the current URI specification, fragments only get interpreted on the user agent side. One way to overcome this problem is to use the Query part of the URI ("?") instead, but this creates other problems, iin the least overloading the meaning of "querying". Inherently, a temporal offset is a specification of a "fragment" in its core meaning and therefore we would prefer to use the "fragment" part. It makes everything much simpler. If there is no burning need to interpret the fragment identifier at the user agent, a change of the standard may be adequate. As the URI standard is currently reworked, we may get a chance to just do that (see URIBOF at next IETF meeting). > Secondly the interpretation of the fragment identifier is in relation to > the data resulting in the request. So in fact it seems that you need to > define the behavior on per media basis. Agreed. > I think the use of fragment to specify where in a media resource is > appropriate in some case. For example an RTSP URL that has a fragment of > the proposed type is useful. However as RTSP works the server shall not > interpret the fragment as this is pointless. Only the client needs to do > this and use that to determine the range to include in the PLAY request. > So again the usage rules in chapter 4 seems to be wrong. Thanks. We'll take that into account when working over it. > It seems that the time specification should be complemented to allow > specifying ranges. The result of a search or the part of your friends > wedding video that you want to point out would in most cases only be a > part of the video. Therefore both a start and stop time seems useful. > Then it is also a very short step to having multiple ranges allow one to > point out multiple parts of the same resource that are interesting. As we've had several requests for that feature, we should probably work that as an option into the next version of the document. > Also I think you have a few strange thing in the definition. First you > specify an attribute "start" that I think are pointless. Either you > totally skip the fragment or you can use "npt=0". Possibly. But sometimes you have a file that does not start at 0 but rather with a time offset (because e.g. it is mirroring a timecode from an analog band from where it got digitized). In this case, "start" makes sense and does not default to "npt=0". > Secondly it the defaulting to "npt". > This clashed with the general parameters. If you > use start then you have actually wrote "npt=start" which isn't defined. That's a matter of parsing sequence and probably adjustment of the BNF that we wrote in the document. The use of "npt" as default came from our experience with using the mechanism and the short form added much usability. > "now" works as long as this is based on the RTSP definitions of NPT, > however from your BNF definitions this is evidently not the case. So my > proposal is to skip having any default time scheme if you are going to > have general attributes that does not belong to a time scheme. I guess, a change of the BNF definition is more appropriate. Also, "start" and "now" seem to be useful for streaming and thus should be covered in URIs, too. Best Regards, Silvia. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 12 06:15: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 GAA00015 for ; Wed, 12 Mar 2003 06:15:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CBTST03744 for mmusic-archive@odin.ietf.org; Wed, 12 Mar 2003 06:29:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBTRO03741 for ; Wed, 12 Mar 2003 06:29:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00006 for ; Wed, 12 Mar 2003 06:15:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBTKO03729; Wed, 12 Mar 2003 06:29:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBQvO03640 for ; Wed, 12 Mar 2003 06:26:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29975; Wed, 12 Mar 2003 06:12:30 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CBEWB3018035; Wed, 12 Mar 2003 12:14:32 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVN7FT9; Wed, 12 Mar 2003 12:14:31 +0100 Message-ID: <3E6F1697.4040607@era.ericsson.se> Date: Wed, 12 Mar 2003 12:14:31 +0100 X-Sybari-Trust: 6248bb2f 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvia.Pfeiffer@csiro.au CC: avt@ietf.org, mmusic@ietf.org, Conrad.Parker@csiro.au References: <3E66AF6D.7040106@csiro.au> <3E671F9E.7080706@era.ericsson.se> <3E6EA41C.3010504@csiro.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [AVT] new I-D on temporal URI addresses Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Silvia, First I have a question on how you are going to go forward in IETF. Are you planning to take this work into any WG or do a individual submission? Then more comments below: Silvia.Pfeiffer@csiro.au wrote: > 1) General mechanism questions, applicability to different media types > and protocols: > >> First is the possibility to specify this as a general mechanism. It >> seems that you want to have this to apply to all URI schemes. Is that >> really possible? > > > The question that you are addressing goes beyond whether our mechanism > applies to all URI schemes. In > http://www.w3.org/DesignIssues/Fragment.html Tim Berners-Lee states as > an axiom that "The fragment ID spec for a new MIME type should be part > of the MIME type registration process". This implies that the meaning > of a fragment specification depends on the MIME type of the addressed > resource. Therefore, the interpretation of a fragment has to be > specified for each MIME type, and then probably again for each MIME > type on each different scheme. Our I-D can only propose a generic way > to specify time-offsets for time-continuous data and we are proposing > it for http and rtsp where they make sense. > > As an example take QuickTime files. Apple registered the MIME type > video/quicktime but the documentation does not have a specification of > how to interpret fragment parts when the files are used in URIs. Our > I-D would not automatically enable timed fragment offsets to be used > with QuickTime files - it needs an active move from Apple to change > their MIME type specification. The same holds true for RealMedia and > WindowsMedia and any other time-continuous MIME type. In fact, I > believe that no MIME type registration except for text/html includes a > fragment interpretation section. Thanks, for the explanation, it greatly clarifies this. However to my understanding the usage of MIME types is actually depending on the URI scheme. One simple example is to compare HTTP and RTSP. In HTTP you: 1) download the object specified by the URI. 2) Look at the MIME type of the downloaded object and sends it to its parser together with the fragment. 3) The parser takes the fragment into account when displaying the content. However for RTSP URI with a fragment one possible interpretation is to setup the presentation indicated by the URI. This setup results in that a media description is retrieved. This description has of course a MIME type. Is it to this description the the fragment applies? Or is it to a the presentation in general which does not have a MIME type, or is it to the media streams which can contain one or more different encodings perhaps identified by MIME types. My point with this example is that the schemes seems to be taken into account. For RTSP it seems in fact that it is time to start defining some fragment identifier behavior. > > > How do you know that the use of @ will not collide with > >> any usage? > > > The "@" sign is a reserved character in the URI Generic Syntax > (RFC2396). It is allowed as part of a fragment, but its use is > reserved for special cases. No special case of the use of "@" is know > to us or published with IETF and therefore we assume there will be no > collisions. Ok. > >> For example the rtsp scheme does not define how to interpret the >> fragment. So this is up to the server responding to a request. So >> this can potentially already be used by some implementations. > > > As this has never been suggested before, there won't be any existing > implementations that use it. Streaming servers should however find it > easy, to support this mechanism as they only have to copy the > specification after the "@" sign into the appropriate rtsp timestamp > field. I don't think we need to consider servers in this case, rather the clients as fragments should have been treated in accordance with the URI specification saying that fragment is a user agent problem. > >> So a general question, what is the actually possibilities to >> standardize such a solution? > > > It needs some minor adjustments in the URI standard. As that standard > is currently being changed/adapted, this could be the right time to > get it adjusted. Then our mechanism can be provided as a Generic > Syntax proposal and MIME type specifications for time-continuous data > can elect to support it. That's my take. I am not fully aware of what is happening with this. However I have seen a draft for making URI generic syntax to standard. Is that what you have in mind? To my knowledge the changes performed on a specification when going from draft to full standard are only clarifications. Technical changes are very limited if allowed at all. I think that any such extension as you are proposing will be a proposed standard. > > > 2) Questions on "fragment" definition, ranges: > >> Second, is the usage of the fragment identifier. It seems that you >> tries to redefine the meaning of the fragment identifier. See below. >> >> From RFC 2396: >> >> "When a URI reference is used to perform a retrieval action on the >> identified resource, the optional fragment identifier, separated from >> the URI by a crosshatch ("#") character, consists of additional >> reference information to be interpreted by the user agent after the >> retrieval action has been successfully completed. As such, it is not >> part of a URI, but is often used in conjunction with a URI. >> >> fragment = *uric >> >> The semantics of a fragment identifier is a property of the data >> resulting from a retrieval action, regardless of the type of URI used >> in the reference. Therefore, the format and interpretation of >> fragment identifiers is dependent on the media type [RFC2046] of the >> retrieval result. The character restrictions described in Section 2 >> for URI also apply to the fragment in a URI-reference. Individual >> media types may define additional restrictions or structure within >> the fragment for specifying different types of "partial views" that >> can be identified within that media type." >> >> Two things strikes me as not being taken into account by your draft >> in relation to this quote. The first is from the first paragraph of >> the quote. The fragment identifier is interpreted by the user agent. >> While in chapter 4 of your draft you clearly specifies that the >> server shall interpret the fragment. This redefines the behavior of >> the fragment identifier. > > > We are aware that with the current URI specification, fragments only > get interpreted on the user agent side. One way to overcome this > problem is to use the Query part of the URI ("?") instead, but this > creates other problems, in the least overloading the meaning of > "querying". Inherently, a temporal offset is a specification of a > "fragment" in its core meaning and therefore we would prefer to use > the "fragment" part. It makes everything much simpler. If there is no > burning need to interpret the fragment identifier at the user agent, a > change of the standard may be adequate. As the URI standard is > currently reworked, we may get a chance to just do that (see URIBOF at > next IETF meeting). For me it seems very bad step to redefine this. I think one should look at both use cases. There will still be plenty of reasons to use fragment on the client side. And as there is a large number of HTTP clients out there using the current definition it seems a bad move to redefine it. However one should also look into how to address this when one wants the server to perform the action. I can clearly understand the use case of having a server reduce large media files to only contain what one is interested of. I looked through the URIBOF agenda: http://www.ietf.org/ietf/03mar/uribof.txt . I could however not see that this issue would be part of the BOF. Are you planning to take up your proposal there? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 12 11:11:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09670 for ; Wed, 12 Mar 2003 11:11:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CGPIA24028 for mmusic-archive@odin.ietf.org; Wed, 12 Mar 2003 11:25:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGPIO24025 for ; Wed, 12 Mar 2003 11:25:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09628 for ; Wed, 12 Mar 2003 11:10:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGFIO23543; Wed, 12 Mar 2003 11:15:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGCqO23414 for ; Wed, 12 Mar 2003 11:12:52 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09269 for ; Wed, 12 Mar 2003 10:58:21 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl6.philips.com (Postfix) with ESMTP id 51F8EA4EF1 for ; Wed, 12 Mar 2003 17:00:29 +0100 (MET) Received: from smtprelay-nl1.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 RAA11845 for ; Wed, 12 Mar 2003 17:00:28 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA11177 for ; Wed, 12 Mar 2003 17:00:26 +0100 (MET) To: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 12 Mar 2003 16:53:24 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 12/03/2003 17:01:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] summary of the Stream Switching presentation Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , All, regarding: 56th IETF: Draft MMUSIC Agenda ============================== Monday, 17 March 2003, 0900 - 1130, Continental 8/9 --------------------------------------------------- 1120 RTSP Stream Switching (Gentric, 10) draft-gentric-mmusic-stream-switching-00.txt ***************** this presentation will: * state that stream switching control is the missing building block in order to achieve "Streaming with Rate and Congestion Control" * skip as out of focus some associated issues(rate control, session description/negociation) * rapidly describe stream switching control key issues * outline the proposed solution * ask for feedback regarding the suitability of this topic as a working group item. ************************************************* In the meanwhile I will be glad to answer questions about the draft which is available at: http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-00.txt 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 Mar 12 16:24:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23567 for ; Wed, 12 Mar 2003 16:24:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLcHp17202 for mmusic-archive@odin.ietf.org; Wed, 12 Mar 2003 16:38:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLcHO17199 for ; Wed, 12 Mar 2003 16:38:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23547 for ; Wed, 12 Mar 2003 16:23:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLcDO17190; Wed, 12 Mar 2003 16:38:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLZvO16346 for ; Wed, 12 Mar 2003 16:35:57 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23497 for ; Wed, 12 Mar 2003 16:21:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 12 Mar 2003 13:21:38 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Wed, 12 Mar 2003 13:21:38 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2-glompatched/8.12.2) with ESMTP id h2CKMAlw031452 for ; Wed, 12 Mar 2003 12:22:16 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18tCju-0007St-00 for ; Wed, 12 Mar 2003 12:22:14 -0800 Date: Wed, 12 Mar 2003 12:21:12 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_10,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-UIDL: 0bbe140dc167864c37dc01e26dd30282 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #74 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 12 Mar 2003 06:45:23 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla Bugs item #640848, was opened at 2002-11-19 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Go Hori (ghori) Assigned to: Nobody/Anonymous (nobody) Summary: umbiguity in aggregate/non-aggregate pla Initial Comment: It is not clear to me who's choice it is to pick aggregate play vs. non-aggregate play. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-03-12 15:45 Message: Logged In: YES user_id=302620 It is the clients. With the updated specification the client chooses this by setting up multiple streams or not in a each session. This has no impact on a server that supports aggregated control. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 03:53: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 DAA24100 for ; Thu, 13 Mar 2003 03:53:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D97Q707973 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 04:07:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D97QO07962 for ; Thu, 13 Mar 2003 04:07:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24069 for ; Thu, 13 Mar 2003 03:52:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D97HO07786; Thu, 13 Mar 2003 04:07:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D94GO07319 for ; Thu, 13 Mar 2003 04:04:16 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24048 for ; Thu, 13 Mar 2003 03:49:23 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D8pWwv006664 for ; Thu, 13 Mar 2003 09:51:32 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDV31Q2Z; Thu, 13 Mar 2003 09:51:31 +0100 Message-ID: <3E704693.7010902@era.ericsson.se> Date: Thu, 13 Mar 2003 09:51:31 +0100 X-Sybari-Trust: 53a5825a 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP Slides for MMUSIC WG meeting & AD-hoc RTSP meeting Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here comes an initial version of the slides that I will use on monday. The slides are for both the RTSP Update and the RTSP & NAT draft, draft-ietf-mmusic-rfc2326bis-03.txt and draft-ietf-mmusic-rtsp-nat-00.txt. The slides can be retrieved at: http://standards.ericsson.net/westerlund/RTSPatIETF56.pdf Please look through them before the meeting because I will need to have a certain tempo in the presentation and will not go into much detail. So if you have any input into anything please raise them on the mailing list or interrupt me during the presentation. We have also planned to have two RTSP ad-hoc meetings during the meeting. The first is already scheduled to Sunday (16/3) at 21.00 in the bar. The location is the hotel bar. If there are multiple ones, a clarifying message will be sent to the list as soon as we have managed to scout the location. We will also in that case put up a note on the message board. We will at that meeting schedule the second one and present the actual time at the WG meeting. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 07:00:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27706 for ; Thu, 13 Mar 2003 07:00:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DCEV220568 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 07:14:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCEVO20565 for ; Thu, 13 Mar 2003 07:14:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27685 for ; Thu, 13 Mar 2003 06:59:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCESO20556; Thu, 13 Mar 2003 07:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCBxO20478 for ; Thu, 13 Mar 2003 07:11:59 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27673 for ; Thu, 13 Mar 2003 06:57:04 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2DBxDwv027198 for ; Thu, 13 Mar 2003 12:59:13 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPHJ0B9W; Thu, 13 Mar 2003 12:59:12 +0100 Message-ID: <3E707290.6010604@era.ericsson.se> Date: Thu, 13 Mar 2003 12:59:12 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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 Slides for MMUSIC WG meeting & AD-hoc RTSP meeting References: <3E704693.7010902@era.ericsson.se> 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, If people have had problems with the below file please download it again. > http://standards.ericsson.net/westerlund/RTSPatIETF56.pdf An ASCII FTP transfer corrupted it. This is now fixed Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 10:33: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 KAA05665 for ; Thu, 13 Mar 2003 10:33:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DFm7205441 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 10:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFm7O05438 for ; Thu, 13 Mar 2003 10:48:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05618 for ; Thu, 13 Mar 2003 10:33:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFm1O05420; Thu, 13 Mar 2003 10:48:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFjOO05277 for ; Thu, 13 Mar 2003 10:45:24 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05494 for ; Thu, 13 Mar 2003 10:30:22 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2DFWWB3023999 for ; Thu, 13 Mar 2003 16:32:32 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPH6F4P8; Thu, 13 Mar 2003 16:32:31 +0100 Message-ID: <3E70A490.1070509@era.ericsson.se> Date: Thu, 13 Mar 2003 16:32:32 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG References: <200303101509.KAA28237@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DFjOO05278 Subject: [MMUSIC] Comments on: draft-gentric-mmusic-stream-switching-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I have some comments on this proposal. My general comment is that the need for such a solution as outline in the proposal is not very present. The draft includes two different mechanisms. 1. A way of selecting streams to switch between, i.e. SWITCHSETUP and SWITCHCLOSE. 2. A way of signaling requests and notifications on happening or soon to happen switches, i.e. SWITCH and SWITCHSIGNAL. Functionality one. The basic problem here is actually one of capability exchange. A streaming server needs to now what capabilities a client has so the offered streams does not go outside what the client can handle. However this problem is much larger than simple selecting what streams to switch between. It also includes media codecs, signaling extensions that are supported, etc. If one has a general mechanism for capability exchange one can ensure before setting up the session that one's client can handle what the server will send. That way a server can perform switching without having to worry if the client can handle it. I think mechanisms to handle this general problem are starting to come into being. The first component is a more capable session description protocol which supports capability negotiation, i.e. SDP-NG. Then we will need to look at how we can use SDP-NG in the context of RTSP. I think it will be necessary to provide some extensions in functionality, perhaps as simple as providing a back channel for the SDP-NG response in SETUP. My conclusion is that making a narrow solution that only solves a little piece of the problem is no good. Lets fix this properly. Until then I think the current mechanisms work sufficiently well. What the draft misses to point out is that a client already today are very capable of handling adaptation of bit-rates for streams. As pointed out by the draft what it calls client transparent switches works very well. These changes that are within the defined payload format and codec configuration can in certain cases be very large and in other none. For the non-transparent cases, i.e. needs to use multiple RTP payload types to signal which configuration to use, is not a major problem from standards point. If one accepts to start a session that contains a SDP with multiple PTs one needs to handle this. I can understand that it puts some pressure on the client implementations to handle multiple codecs. However in most case I think this is simple a question of different configurations, for example AAC and MPEG4 Visual streams. I don't think as a general case that one may not perform announced and potential a codec change / reconfiguration without explicit approval from the client. The client accepted to handle this by setting up the session. Looking at functionality 2: The signaling of switching commands. Lets start with the service SWITCHSIGNAL provides. This is used to notify that a switch will take place. I don't see how signaling this in advance can help. First, in most case you can't determine that you are going to switch any significant time in advance. The reason of course being that switching is done to react to changes in the network. When changes happens you need to switch quickly, there is no time to wait two seconds after a RTSP command has gone out. So therefore its better to switch directly. A transparent switch does not effect client in any way. A non-transparent may effect the client if its built on dynamic loading of codecs, etc. In this case you will still receive some heads up notice. This due to the clients buffer. When the packets start arriving with a different RTP PT the client can detect this directly and start preparing. The time in advance will depend on the amount of buffering left at ! that time. Another aspect of SWITCHSIGNAL is that it may not arrive before the actual media packets that represent the switch. One argument that might be used for the usefulness of SWITCHSIGNAL is the synchronization information carried in it. However I don't see any need. As long as media playout are continuos the existing timeline will continue to exist and provide synchronization. Lets continue with SWITCH. This being a client to server command to change to another stream. In my work with the 3GPP PSS adaptation work I have come to the conclusion that server controlled adaptation is the best thing. Reasons are: 1. In a best effort network the sending side are responsible for what it sends out on the network. This is as pointed out the model used by all IETF congestion control mechanisms. Server controls allows for halting transmission if feedback stops. 2. Server has the knowledge where it is suitable to switch. It simply has the media and all its meta data available and can therefore best determine when and how to switch. 3. There are fewer servers in both implementations and actual numbers. This makes bug fixes updates of algorithms etc. much easier. 4. Server has knowledge when packets where sent. This allows it to take client feedback into that context. Doing it the other way seems to require more signaling. 5. It can be deployed in a backwards compatible way. As soon as a server support adaptation it can start performing it. The basic feedback will be RTCP which hopefully most support and sends. However a adaptation solution based on client side requires both client and server to be updated. Of course in some cases it would be simpler if the client took the decision but from my point of view it is in favor for the server controlled solution. Another point is that it already exist RTSP ways to influence the server on what to send. The Bandwidth header can be included in PLAY, or SET_PARAMETER requests to tell the server what available bit-rate it sees. The server can then adapt its transmission to what the client claims and then verify it by looking at RTCP feedback. Further the adaptation is not as simple as switching between different encodings. The server can actually perform other actions that change the sent bit-rate. One good example is stream thinning. I could for example reduce a video sequence with 5% by simply removing some frames. Done in an optimal way it would not degrade the quality very much. Perhaps simply a little lower frame rate. Finally I would like to make some explicit remarks about a few thing written in the draft. 1. Section 1.5 bullet 1: Assumed that bit-rate will be constant. I have not made that assumption in a long time. However given a certain bit-rate it is best to utilize it to the maximum, and that means producing constant bit-rate streams for that bit-rate. 2. Section 2.1.2 The MUST NOT in first bullet: In some sense I would have to agree with you that the client must agree on the codecs/configuratins to use. However that is done by any client setting up a session which SDP file specify this. My point with this rather long mail is that I don't think the proposal is appropriate and better ways of handling the problems exist or are under development. Not all pieces may be in place and work may be needed. However I think that it should be performed in areas that have more general application and helps fix larger problems. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 12:35: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 MAA09832 for ; Thu, 13 Mar 2003 12:35:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DHoK415268 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 12:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DHoKO15265 for ; Thu, 13 Mar 2003 12:50:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09826 for ; Thu, 13 Mar 2003 12:35:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DHoGO15254; Thu, 13 Mar 2003 12:50:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DHlWO15088 for ; Thu, 13 Mar 2003 12:47:32 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09753 for ; Thu, 13 Mar 2003 12:32:30 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2DHYdwv021620 for ; Thu, 13 Mar 2003 18:34:39 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDV3JLXY; Thu, 13 Mar 2003 18:34:38 +0100 Message-ID: <3E70C12E.3060308@era.ericsson.se> Date: Thu, 13 Mar 2003 18:34:38 +0100 X-Sybari-Trust: 05ca19ee 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP and NAT - More issues found with symmetric RTP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, When I wrote the slides for the presentation I identified one more problem in the RTSP and NAT draft. This concerns symmetric RTP. What I found is that symmetric RTP has the same problems with different IP addresses that a STUN based solution would have. We must also enforce that media shall only be sent to an IP address that match the RTSP signaling connection. The attack that forces us to take this stand also for symmetric RTP looks like this: This attack is how you can use the server to perform DDOS attacks. The attacker connects to the RTSP server and request that at session should determine source address based on symmetric RTP. Then the attacker knowing the shared secret sends RTP and RTCP binding packets to the server ports with spoofed IP addresses of the victim of the DOS attack. Nice and simple and with minimum effort from attacker. When we are on the topic of using RTSP to perform denial of service attacks: Couldn't RTCP be used to reduce the impact of these attacks. IF one requires to receive RTCP messages from the receiver one can limit which can perform this attack. If one needs to send RTCP about the media stream actually sent the attacker must be able to eavesdrop the media stream from server towards victim to be able to generate correct RTCP reports. The server would be responsible to cut the media stream if no RTCP receiver reports corresponding to recently sent packets are received. I know that this only provides partial security. Just fishing for possible solutions. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 14:04: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 OAA13047 for ; Thu, 13 Mar 2003 14:04:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJJMr22163 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 14:19:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJJMO22160 for ; Thu, 13 Mar 2003 14:19:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13037 for ; Thu, 13 Mar 2003 14:04:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJJEO22149; Thu, 13 Mar 2003 14:19:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJGCO22017 for ; Thu, 13 Mar 2003 14:16:12 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12925 for ; Thu, 13 Mar 2003 14:01:05 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id A8C2591FBC; Thu, 13 Mar 2003 20:03:14 +0100 (MET) Received: from smtprelay-nl1.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 UAA19456; Thu, 13 Mar 2003 20:03:14 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id UAA21095; Thu, 13 Mar 2003 20:03:12 +0100 (MET) Subject: Re: [MMUSIC] Comments on: draft-gentric-mmusic-stream-switching-00.txt To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Mar 2003 19:56:21 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/03/2003 20:04:13 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, thanks a lot for your feedback! a long reply to a long comment ... ************************************************** you write: >The draft includes two different mechanisms. >1. A way of selecting streams to switch between, i.e. SWITCHSETUP and SWITCHCLOSE. > [......] >Functionality one. The basic problem here is actually one of capability exchange. There is a misunderstanding here! Indeed there is a capability exchange issue associated with stream switching (And I agree that SDP-NG could help here ) ...but not only the draft does not pretend to cover this at all it is also intended to propose a solution independently from these issues! specifically neither SWITCHSETUP nor SWITCHCLOSE are for capability exchange! * SWITCHSETUP is actually exactly like SETUP, as mentionned in the draft, the point of introducing SWITCHSETUP is only a) to make it explicit for alternate streams b) to improve backward compatibility * SWITCHCLOSE is for ressource garbage collection only. (BTW it is a well know problem of RTSP that you can SETUP dynamically but that TEARDOWN kills the whole session) >Lets start with the service SWITCHSIGNAL provides. >This is used to notify that a switch will take place. >I don't see how signaling this in advance can help. First, in >most case you can't determine that you are going to switch any >significant time in advance. The reason of course >being that switching is done to react to changes in the network. I agree that for switching in *very* short notice SWITCHSIGNAL does not help... this is in my view the difference between *rate* control and *congestion* control: in an "emmergency" (congestion control) you want to switch down fast, but when the network is stable you want to slowly explore "up" (TFRC, etc) and you will have cases when the system is slowly drifting because the streaming rate is only slitghtly too large for the network, and then you can have many seconds to react ... (if you have a way to react!) also remember that the target is *seamless* switching, in an emmergency (congestion control) you want to preserve the network, seamless-ness is secondary, but outside of emmergencies there are cases where you want to a really smooth playback and SWITCHSIGNAL is intended for that: >One argument that might be used for the usefulness of > SWITCHSIGNAL is the synchronization information carried in it. YES! > However I don't see any need. As long as media playout are > continuos the existing timeline will continue to >exist and provide synchronization. Yes, true, but tricky and also with an fundamentaly important exception for audio with multiple frames per packet, which makes SWITCHSIGNAL very useful: In that case in order to synchronize the decoder needs to get *exact* RTP time stamp values because 2 streams encoded from the same content at different bit rates will produce different packetization, so that the decoder needs to discard a certain number of audio *frames* from the first packet of the new streams in order to get perfect lip-sync ... >Lets continue with SWITCH. This being a client to server command to > change to another stream. In my work with the >3GPP PSS adaptation work I have come to the conclusion > that server controlled adaptation is the best thing. First I completely agree that in some cases server control is best. as explained above SWITCHSIGNAL is actually provided solely as an (optional) helper for that case ! The point however is that in *some* cases client control is also nice. ******One key case is when RTCP feedback is blocked*********** (unfortunately I forgot to mention that one in the draft!!) You will have to recognize it is also *very* natural from the RTSP "philosophy" point of view! >1. In a best effort network the sending side are responsible for > what it sends out on the network. This is as >pointed out the model used by all IETF congestion control > mechanisms. Server controls allows for halting >transmission if feedback stops. I understand that, and for that reason a) SWITCH is OPTIONAL b) servers can deny SWITCH requests (especially up) c) in all cases servers *can* stop sending when the RTCP feedback (or absence of) indicates congestion the point is rather that in less dramatic cases you want to provide a smooth transition (a seamless switch). >2. Server has the knowledge where it is suitable to switch. >It simply has the media and all its meta data available >and can therefore best determine when and how to switch. true, the server is also a mission critical device which economics are to be able for a given hardware to support as many concurrent sessions as possible, for that reason there are people (like us) who prefer to have the client make the rate control computation and heuristics for target stream selection (a bit like web servers use cookie to save the context at the client side) >3. There are fewer servers in both implementations and actual numbers. > This makes bug fixes updates of algorithms etc. much easier. Hum, maintenance and upgrades looks to me like a much more complicated issue than that... anyway *everything* is optional in my proposal so ... you can upgrade client first, or server first as you like;-) >4. Server has knowledge when packets where sent. > This allows it to take client feedback into that context. > Doing it the other way seems to require more signaling. again, maintaining a lot of context in the server may not be a good idea for everybody... also I dont see the logic here since the first place where congestion is detected is always the client (with one exception: TRIGTRAN, but that is yet another animal!) plus the fact that the player buffer content is also an important parameter. >5. It can be deployed in a backwards compatible way. As soon as a > server support adaptation it can start performing it. well again, same here ! > The basic feedback will be RTCP which hopefully most support and sends. I am sorry hope is not enough for me: actually THAT is a key motivation for client side command i.e. "SWITCH" command. the possibility that RTCP feedback is blocked is a very real one. > However a adaptation solution based on >client side requires both client and server to be updated. well, yes but by experience I am not so optimistic about a client which has not been designed implemented and tested for it surviving a switch from a server!-) Anyway one key point is that my proposal is 100% backward compatible: * "old" servers that do not implement it will ignore SWITHSETUP and SWITCH ("501 not implemented") * "old" clients that do not implement it will not send SWITHSETUP and therefore the server will *know* that the client does not support Stream Switching and *this* is in contrast with the solution you propose where a server would switch without even knowing if a client supports it! **************************** you also write: >Until then I think the current mechanisms work sufficiently well. > What the draft misses to point out is that a client already today > are very capable of handling adaptation of bit-rates for streams. > As pointed out by the draft what it calls client transparent > switches works very well. I am very surprised you can say that "it works very well"! Can you point out interroperability test reports that would have escaped my attention?-) The draft does not say it works well it says it works "in theory" and I am of the kind who beleives there is a large gap between theory and practice ;-) But OK, the point of the draft is also to aim for the more general solution because the bit rate ranges reachable with the client-transparent modes are *just not good enough.* The aim is definitively to be able to switch from a few Mb/s to a few kb/s, and for that you will have drastic configuration changes (codecs, screen sizes, number of audio channels, you name it) >Another point is that it already exist RTSP ways to influence the server > on what to send. The Bandwidth header can be included in PLAY, > or SET_PARAMETER requests to tell the server what available bit-rate it sees. sorry but I like to call a cat a cat ;-) if it is a switch why not call it "SWITCH" ????????? also there are 2 dozens of different such tricks being proposed/used by now! the *point* would be that everybody uses the same one ! > The server can actually perform other actions that change the sent > bit-rate. One good example is stream thinning. I could for example > reduce a video sequence with 5% by simply removing some frames. > Done in an optimal way it would not degrade the quality very much. > Perhaps simply a little lower frame rate. yes, it works but it is transparent only by removing B frames, which covers a very narrow bandwidth range ... anyway this is something, as you point out, for which no standardization is needed anyway ... >1. Section 1.5 bullet 1: Assumed that bit-rate will be constant. > I have not made that assumption in a long time. >However given a certain bit-rate it is best to utilize >it to the maximum, and that means producing constant >bit-rate streams for that bit-rate. AH But *that* is the point: to leverage on existing codec technology which has been optimized for constant bit rate ! ... on networks with variable band width ! >2. Section 2.1.2 The MUST NOT in first bullet: In some sense I would > have to agree with you that the client must agree on the codecs/configuratins > to use. However that is done by any client setting up a session which > SDP file specify this. True, however as explained I want to give some more flexibility here, **just as SETUP can be performed at anytime** I want to be able to SWITCHSETUP at anytime By symmetry I also want to be able to SWITCHCLOSE at anytime because the amount of ressources involved can be pretty large. an example: a streaming service is nominal at 2 Mb/s, but one client is apparently with a bad network, the session has been rapidly switching down to 500 kb/s in the first seconds of streaming and is now stable for several minutes: I want to have the possibility that in the policy of the server the server "decides" that this guy will not be able to get 2 Mb/s anymore (except maybe by restarting another session) so my server garbage-collects the resources for streaming this guy at 2 Mb/s (which involve a lot of saved space in cache etc) plus it sends a SWITCHCLOSE to tell the client to do the same! - which saves ressource on the client - and if SWITCH is supported avoids it trying to switch up, which would be denied anyway. A probably more important example is a client running low on ressources in a server-initiated-switch scenario: the client sends a SWITCHCLOSE to the server to tell it "dont switch to this bit rate, not only would it waste BW but playback would be interrupted, because I had to garbage collect this codec." > I don't think the proposal is appropriate and better ways of > handling the problems exist or are under development. I wish you could be more specific? > Not all pieces may be in place and work may be needed. oh yes ! > However I think that it should be performed in areas > that have more general application and helps fix larger problems. is this about SDP NG? (then I agree) however again, my proposal is mostly orthogonal to session description/negociation... Maybe I should have called it "stream switching control ?" ****************************************** 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] Comments on: draft-gentric-mmusic-stream-switching-00.txt Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 13/03/2003 16:32 Hi, I have some comments on this proposal. My general comment is that the need for such a solution as outline in the proposal is not very present. The draft includes two different mechanisms. 1. A way of selecting streams to switch between, i.e. SWITCHSETUP and SWITCHCLOSE. 2. A way of signaling requests and notifications on happening or soon to happen switches, i.e. SWITCH and SWITCHSIGNAL. Functionality one. The basic problem here is actually one of capability exchange. A streaming server needs to now what capabilities a client has so the offered streams does not go outside what the client can handle. However this problem is much larger than simple selecting what streams to switch between. It also includes media codecs, signaling extensions that are supported, etc. If one has a general mechanism for capability exchange one can ensure before setting up the session that one's client can handle what the server will send. That way a server can perform switching without having to worry if the client can handle it. I think mechanisms to handle this general problem are starting to come into being. The first component is a more capable session description protocol which supports capability negotiation, i.e. SDP-NG. Then we will need to look at how we can use SDP-NG in the context of RTSP. I think it will be necessary to provide some extensions in functionality, perhaps as simple as providing a back channel for the SDP-NG response in SETUP. My conclusion is that making a narrow solution that only solves a little piece of the problem is no good. Lets fix this properly. Until then I think the current mechanisms work sufficiently well. What the draft misses to point out is that a client already today are very capable of handling adaptation of bit-rates for streams. As pointed out by the draft what it calls client transparent switches works very well. These changes that are within the defined payload format and codec configuration can in certain cases be very large and in other none. For the non-transparent cases, i.e. needs to use multiple RTP payload types to signal which configuration to use, is not a major problem from standards point. If one accepts to start a session that contains a SDP with multiple PTs one needs to handle this. I can understand that it puts some pressure on the client implementations to handle multiple codecs. However in most case I think this is simple a question of different configurations, for example AAC and MPEG4 Visual streams. I don't think as a general case that one may not perform announced and potential a codec change / reconfiguration without explicit approval from the client. The client accepted to handle this by setting up the session. Looking at functionality 2: The signaling of switching commands. Lets start with the service SWITCHSIGNAL provides. This is used to notify that a switch will take place. I don't see how signaling this in advance can help. First, in most case you can't determine that you are going to switch any significant time in advance. The reason of course being that switching is done to react to changes in the network. When changes happens you need to switch quickly, there is no time to wait two seconds after a RTSP command has gone out. So therefore its better to switch directly. A transparent switch does not effect client in any way. A non-transparent may effect the client if its built on dynamic loading of codecs, etc. In this case you will still receive some heads up notice. This due to the clients buffer. When the packets start arriving with a different RTP PT the client can detect this directly and start preparing. The time in advance will depend on the amount of buffering left at ! that time. Another aspect of SWITCHSIGNAL is that it may not arrive before the actual media packets that represent the switch. One argument that might be used for the usefulness of SWITCHSIGNAL is the synchronization information carried in it. However I don't see any need. As long as media playout are continuos the existing timeline will continue to exist and provide synchronization. Lets continue with SWITCH. This being a client to server command to change to another stream. In my work with the 3GPP PSS adaptation work I have come to the conclusion that server controlled adaptation is the best thing. Reasons are: 1. In a best effort network the sending side are responsible for what it sends out on the network. This is as pointed out the model used by all IETF congestion control mechanisms. Server controls allows for halting transmission if feedback stops. 2. Server has the knowledge where it is suitable to switch. It simply has the media and all its meta data available and can therefore best determine when and how to switch. 3. There are fewer servers in both implementations and actual numbers. This makes bug fixes updates of algorithms etc. much easier. 4. Server has knowledge when packets where sent. This allows it to take client feedback into that context. Doing it the other way seems to require more signaling. 5. It can be deployed in a backwards compatible way. As soon as a server support adaptation it can start performing it. The basic feedback will be RTCP which hopefully most support and sends. However a adaptation solution based on client side requires both client and server to be updated. Of course in some cases it would be simpler if the client took the decision but from my point of view it is in favor for the server controlled solution. Another point is that it already exist RTSP ways to influence the server on what to send. The Bandwidth header can be included in PLAY, or SET_PARAMETER requests to tell the server what available bit-rate it sees. The server can then adapt its transmission to what the client claims and then verify it by looking at RTCP feedback. Further the adaptation is not as simple as switching between different encodings. The server can actually perform other actions that change the sent bit-rate. One good example is stream thinning. I could for example reduce a video sequence with 5% by simply removing some frames. Done in an optimal way it would not degrade the quality very much. Perhaps simply a little lower frame rate. Finally I would like to make some explicit remarks about a few thing written in the draft. 1. Section 1.5 bullet 1: Assumed that bit-rate will be constant. I have not made that assumption in a long time. However given a certain bit-rate it is best to utilize it to the maximum, and that means producing constant bit-rate streams for that bit-rate. 2. Section 2.1.2 The MUST NOT in first bullet: In some sense I would have to agree with you that the client must agree on the codecs/configuratins to use. However that is done by any client setting up a session which SDP file specify this. My point with this rather long mail is that I don't think the proposal is appropriate and better ways of handling the problems exist or are under development. Not all pieces may be in place and work may be needed. However I think that it should be performed in areas that have more general application and helps fix larger problems. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 16:06: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 QAA19184 for ; Thu, 13 Mar 2003 16:06:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DLLJn32225 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 16:21:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLLJO32222 for ; Thu, 13 Mar 2003 16:21:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19136 for ; Thu, 13 Mar 2003 16:06:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLLEO32211; Thu, 13 Mar 2003 16:21:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLIDO32067 for ; Thu, 13 Mar 2003 16:18:13 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19029 for ; Thu, 13 Mar 2003 16:03:05 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2DL4at01087 for mmusic@ietf.org; Thu, 13 Mar 2003 13:04:36 -0800 Date: Thu, 13 Mar 2003 13:04:36 -0800 From: John Lazzaro Message-Id: <200303132104.h2DL4at01087@snap.CS.Berkeley.EDU> To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP Slides for MMUSIC WG meeting Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Magnus Westerlund writes: > > if you have any input into anything please raise them on the mailing > list or interrupt me during the presentation. Slide 17, bullet 2: The problem does not exist for the control signaling over TCP, but for the media streams. -- This would seem to imply that interleaved media over the TCP control signalling channel is also not a problem. This would seem to be the actual "competition" for these NAT techniques -- is the savings in server overhead + the quality improvement of UDP media flow over TCP media flow worth the added expense of implementing these RTSP NAT techniques? I hope the answer is "yes", of course ... but I think its a question the skeptical potential implementor may ask ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 13 19:08: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 TAA26264 for ; Thu, 13 Mar 2003 19:08:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E0N0f12671 for mmusic-archive@odin.ietf.org; Thu, 13 Mar 2003 19:23:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0MxO12668 for ; Thu, 13 Mar 2003 19:22:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26252 for ; Thu, 13 Mar 2003 19:07:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0MsO12658; Thu, 13 Mar 2003 19:22:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0JqO12411 for ; Thu, 13 Mar 2003 19:19:52 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26150; Thu, 13 Mar 2003 19:04:40 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id LAA02410; Fri, 14 Mar 2003 11:06:43 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa000.a; Fri Mar 14 11:06:37 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 11:06:37 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id GY5X4JMS; Fri, 14 Mar 2003 11:06:35 +1100 To: magnus.westerlund@era.ericsson.se Cc: avt@ietf.org, mmusic@ietf.org, Conrad.Parker@csiro.au Message-ID: <3E711D60.4060500@csiro.au> Date: Fri, 14 Mar 2003 11:08:00 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 References: <3E66AF6D.7040106@csiro.au> <3E671F9E.7080706@era.ericsson.se> <3E6EA41C.3010504@csiro.au> <3E6F1697.4040607@era.ericsson.se> In-Reply-To: <3E6F1697.4040607@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [AVT] new I-D on temporal URI addresses Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Magnus, > First I have a question on how you are going to go forward in IETF. Are > you planning to take this work into any WG or do a individual submission? I am most happy to take it into a WG but am uncertain which one that would be. > Thanks, for the explanation, it greatly clarifies this. However to my > understanding the usage of MIME types is actually depending on the URI > scheme. One simple example is to compare HTTP and RTSP. In HTTP you: 1) > download the object specified by the URI. 2) Look at the MIME type of > the downloaded object and sends it to its parser together with the > fragment. 3) The parser takes the fragment into account when displaying > the content. Not necessarily. That's just the way current browsers work because of the recommendations for the use of the fragment. I know for a fact that the Apache Web server can receive, parse and handle fragment offsets. > However for RTSP URI with a fragment one possible interpretation is to > setup the presentation indicated by the URI. This setup results in that > a media description is retrieved. This description has of course a MIME > type. Is it to this description the the fragment applies? Or is it to a > the presentation in general which does not have a MIME type, or is it to > the media streams which can contain one or more different encodings > perhaps identified by MIME types. That should be discussed, but my take is that it applies to each one of the media streams that are part of the general presentation. > My point with this example is that the schemes seems to be taken into > account. For RTSP it seems in fact that it is time to start defining > some fragment identifier behavior. I agree, we definately need to take the schemes into account when describing the expected behaviour of servers and clients when encountering these temporal offsets in URIs. > I don't think we need to consider servers in this case, rather the > clients as fragments should have been treated in accordance with the URI > specification saying that fragment is a user agent problem. It is important to consider servers, too. I does not make sense to burden the Internet or the user with a huge amount of video data when all that the user requires is a clip 20 minutes into the video. I am aware that the current use of fragments does not conform to this idea and therefore suggested to discuss the possibilities of changing that usage specification. >>> So a general question, what is the actually possibilities to >>> standardize such a solution? >> >> It needs some minor adjustments in the URI standard. As that standard >> is currently being changed/adapted, this could be the right time to >> get it adjusted. Then our mechanism can be provided as a Generic >> Syntax proposal and MIME type specifications for time-continuous data >> can elect to support it. That's my take. > > I am not fully aware of what is happening with this. However I have seen > a draft for making URI generic syntax to standard. Is that what you have > in mind? To my knowledge the changes performed on a specification when > going from draft to full standard are only clarifications. Technical > changes are very limited if allowed at all. As far as I understand it, there are more changes than just clarifications happening to RFC2396. But if you are right, we are probably forced to go with the query "?" solution rather than fragments, which makes it a lot less elegant. Why should we be using a different scheme for addressing offsets in audio/video than in html? Also, the use of query is already overloaded and therefore a sensible use of fragments for media would make sense. > I think that any such extension as you are proposing will be a proposed > standard. I'd be more than happy to have it become that and through an IETF WG. > For me it seems very bad step to redefine this. I think one should look > at both use cases. There will still be plenty of reasons to use fragment > on the client side. Could you please tell me some? I tend to disagree. I believe that as time-continuous media are usually high data rates, fragment addressing of such data only makes sense if we can avoid having to serve out the complete file before we can address the offset. By the way, even with HTML I have often been upset about having to wait (especially on a modem line) for the complete document to download when all I wanted was to read a specific paragraph in it. > And as there is a large number of HTTP clients out > there using the current definition it seems a bad move to redefine it. No. That would not affect them. It is still possible to say that if the user (agent) wishes to interpret the fragment offset locally, he's free to strip off the fragment offset from the URI (as happening today) and not sending that to the server. However, if a server receives a fragment offset request, he requires to send data only from that offset onwards. > However one should also look into how to address this when one wants the > server to perform the action. I can clearly understand the use case of > having a server reduce large media files to only contain what one is > interested of. > I looked through the URIBOF agenda: > http://www.ietf.org/ietf/03mar/uribof.txt . I could however not see that > this issue would be part of the BOF. Are you planning to take up your > proposal there? I only found out about the URIBOF agenda after having submitted the I-D. I have however sent the I-D to the relevant mailing lists and hope to get them to pick it up and discuss the issues. I cannot attend the meeting personally, unfortunately. Best Regards, Silvia. --- Silvia Pfeiffer Research Scientist CSIRO Australia _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 14 06:36: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 GAA22641 for ; Fri, 14 Mar 2003 06:36:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EBpaY03751 for mmusic-archive@odin.ietf.org; Fri, 14 Mar 2003 06:51:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EBpaO03748 for ; Fri, 14 Mar 2003 06:51:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22637 for ; Fri, 14 Mar 2003 06:36:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EBpWO03740; Fri, 14 Mar 2003 06:51:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EBmmO03665 for ; Fri, 14 Mar 2003 06:48:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22556 for ; Fri, 14 Mar 2003 06:33:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2EBZUB3013040; Fri, 14 Mar 2003 12:35:30 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GZAKWK5P; Fri, 14 Mar 2003 12:35:29 +0100 Message-ID: <3E71BE82.9090401@era.ericsson.se> Date: Fri, 14 Mar 2003 12:35:30 +0100 X-Sybari-Trust: c826c0a6 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Lazzaro CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP Slides for MMUSIC WG meeting References: <200303132104.h2DL4at01087@snap.CS.Berkeley.EDU> 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 John, John Lazzaro wrote: >>Magnus Westerlund writes: >> >>if you have any input into anything please raise them on the mailing >>list or interrupt me during the presentation. >> >> > >Slide 17, bullet 2: > >The problem does not exist for the control signaling over TCP, >but for the media streams. > >-- > >This would seem to imply that interleaved media over the TCP >control signalling channel is also not a problem. This would >seem to be the actual "competition" for these NAT techniques -- >is the savings in server overhead + the quality improvement >of UDP media flow over TCP media flow worth the added expense >of implementing these RTSP NAT techniques? I hope the answer >is "yes", of course ... but I think its a question the skeptical >potential implementor may ask ... > > Quoting from my draft regarding usage of TCP tunneling: 3.4.3. Deployment Considerations Advantage: - Works through all types of NATs. Disadvantage: - Functionality needs to be implemented on both server and client. - May not give real-time performance. So also this usage needs to be implemented. However I hope that a implementor are aware that there is very potential problems with the real-time performance when TCP is used. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sat Mar 15 10:20: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 KAA18754 for ; Sat, 15 Mar 2003 10:20:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FFZrN13677 for mmusic-archive@odin.ietf.org; Sat, 15 Mar 2003 10:35:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFZrO13674 for ; Sat, 15 Mar 2003 10:35:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18724 for ; Sat, 15 Mar 2003 10:19:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFZjO13636; Sat, 15 Mar 2003 10:35:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFWlO13559 for ; Sat, 15 Mar 2003 10:32:47 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18613 for ; Sat, 15 Mar 2003 10:16:48 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (dialup-65.58.198.104.Dial1.Tampa1.Level3.net [65.58.198.104]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h2FFL4817699 for ; Sat, 15 Mar 2003 10:21:05 -0500 Message-Id: <5.1.1.6.0.20030314220448.00b3e9d8@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 14 Mar 2003 22:28:20 -0500 To: mmusic@ietf.org From: David Yon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] A proposal for comedia-06 security section Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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've run a number of scenarios for the connection-hijack concern raised in comedia-fix, modeling the possible levels of connectivity between Alice, Bob, and Carol. I believe that in every scenario except for one, this can be downgraded from a hijacking concern to a DoS concern. I have PowerPoint prepared for Monday, but here is the discussion laid out in detail. The backdrop is that Bob is assumed to follow the rules in section 4.4 (b) and (c), which means that a connection originating from Carol does *not* prevent Bob from attempting a connection. This argues for 4.4 to be upgraded from RECOMMENDED to MUST. Something not clarified in comedia-05 is that it would be helpful for an endpoint to extend the listener lifetime such that it maintains its listener for a short period of time after it received an initial connection in order to detect the possibility a duplicate connection may occur. If a double connect occurs that correlates to the session under negotiation, the endpoint SHOULD consider itself under attack and terminate the session. In the case of bidirectional RTP/AVP, an endpoint that starts receiving two RTP streams from different addresses to the same port pair SHOULD consider itself under attack and terminate the session. On the other side of the timeline, Bob should be mindful of the order in which an incoming connection occurs relative to providing an SDP reply to Alice. If a connection arrives ahead of this event, Bob should be suspicious of the presence of Carol attempting to guess the address/port he is about to advertise in his reply. The connection can either be discarded and Bob can continue, or he can opt to terminate the session. Here are the connection scenarios: FULL CONNECTIVITY: Alice Carol Bob Offer -----------------> <------CONNECT ?? <------------------ CONNECT <------------------ Answer CONNECT----> ===================================== BOB/CAROL CANNOT CONNECT TO ALICE: Alice Carol Bob Offer -----------------> X--CONNECT X-- CONNECT <------------------ Answer CONNECT----> CONNECT ----------------> ?? ===================================== ALICE/CAROL CANNOT CONNECT TO BOB: Alice Carol Bob Offer -----------------> <------CONNECT ?? <------------------ CONNECT <------------------ Answer CONNECT--X ===================================== BOB CANNOT CONNECT TO ALICE: Alice Carol Bob Offer -----------------> <-------CONNECT X-- CONNECT <------------------ Answer CONNECT----> Hijack! ===================================== The ?? shows that Alice or Bob has detected a duplicate media connection and therefore has enough information to infer a possible attack. The failure case is a common client/server scenario where the client (Alice) is behind a NAT/firewall and Bob (the server) is on the public Internet. In many cases Bob knows that he is fully routable, and therefore SHOULD opt to advertise "connection:passive" which will cause Alice to discard Carol's connection once Alice receives Bob's SDP reply. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sat Mar 15 10:22: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 KAA18788 for ; Sat, 15 Mar 2003 10:22:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FFbwG14510 for mmusic-archive@odin.ietf.org; Sat, 15 Mar 2003 10:37:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFbwO14507 for ; Sat, 15 Mar 2003 10:37:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18768 for ; Sat, 15 Mar 2003 10:21:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFbtO14498; Sat, 15 Mar 2003 10:37:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFWvO13564 for ; Sat, 15 Mar 2003 10:32:57 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18628 for ; Sat, 15 Mar 2003 10:16:58 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (dialup-65.58.198.104.Dial1.Tampa1.Level3.net [65.58.198.104]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h2FFLB817707; Sat, 15 Mar 2003 10:21:12 -0500 Message-Id: <5.1.1.6.0.20030314223038.00ba7c38@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 14 Mar 2003 22:34:05 -0500 To: Magnus Westerlund , IETF MMUSIC WG From: David Yon Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-comedia-05.txt In-Reply-To: <3E6E18E2.1040906@era.ericsson.se> References: <200303072035.PAA29469@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Is this really a problem for SAP? Presumably the server would be publicly routable and therefore it would make sense to advertise passive. Do you have any suggestions re: the RTSP port-zero conflict? Security considerations will come back in comedia-06. See my other posting, and this will be discussed at the meeting. If someone wants to give me more guidance on the IANA and ABNF (starting with some group consensus that this is really an issue to be address), I'm all ears. At 12:12 PM 3/11/2003, Magnus Westerlund wrote: >Hi, > >I have some comments on the COMEDIA draft. I still reading up on this so >you will not get one of these 20+ comment letters that some other drafts >has got. >1. The draft seems very directed at SIP usage only. It does not really >describe how to handle comedia in the context of SAP or for that matter >RTSP. In SAP or other uni-directional use cases it will be required that >the SDP describes a passive side as the server can never connect as it >does not know of the client. In regards to RTSP the port number MUST not >be 0 comes into conflict. It seems relevant that a RTSP controlled server >actually offers a media block which uses reliable connection oriented >transport. SO this needs to be addressed I think. >2. The security consideration chapter seems to be missing the important >hijacking warning. If I don't misunderstand section 4.6 a passive side >actually starts sending to the address of the first received packet. This >is very unsecure and easy to hijack. Should definitely be addressed in >the security consideration. > >3. IANA Considerations. This chapter needs to better clarify what exactly >is registered in what registries. I also think that the definitions of the >new attributes should be done better using ABNF of RFC 2234 and >draft-ietf-mmusic-sdp-new. >Regards > >Magnus Westerlund >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Mar 16 12:39: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 MAA00310 for ; Sun, 16 Mar 2003 12:39:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GHtYE12547 for mmusic-archive@odin.ietf.org; Sun, 16 Mar 2003 12:55:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHtYO12544 for ; Sun, 16 Mar 2003 12:55:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00293 for ; Sun, 16 Mar 2003 12:39:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHtPO12530; Sun, 16 Mar 2003 12:55:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHogO12414 for ; Sun, 16 Mar 2003 12:50:42 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00164 for ; Sun, 16 Mar 2003 12:34:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2GHaMB3025972 for ; Sun, 16 Mar 2003 18:36:22 +0100 (MET) Received: from era.ericsson.se (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPH6Z86Y; Sun, 16 Mar 2003 18:36:21 +0100 Message-ID: <3E74AA15.5070204@era.ericsson.se> Date: Sun, 16 Mar 2003 17:45:09 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdescriptions-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a a number of comments on this draft. 1. The short copyright statement are missing on the title page. 2. I am missing a chapter that clearly explains what one must define and think of if defining extensions to the framework defined by this draft. One thing I don't think the draft has considered sufficiently in form of how the text is written is how to adapt it to other profiles. First one mentions using this for non RTP transports, secondly it seems obvious that we should in the near future define the combination of AVPF and SAVP. 3. Chapter 2.0: I find the usage of sub chapter 0 a bit strange. I am definitely used to having 2, 2.1 or 2.1.1 type of difference between chapter levels. 4. Chapter 2.0 The second paragraph: Introduction chapter are normally informative and therefore one avoids all normative language. But this contain a normative SHOULD. 5. Section 4.1 Crypto suites for SRTP. I think this section is badly written it could be much clearer. To my eyes it looks like any crypto suite must contain a certain number of parameters. These parameters should be defined and explained. Then each definition can contain a note on usage and a table with the values. Last the defining new crypto suit then is a piece of cake as it simple requires any defined crypto suit to define values for all parameters. Last it should also define that there is a repository with IANA for crypto suits and that they should be registered. 6. Section 4.2: What is the reasons that one must have SRTP even if one is only receiving media streams and only sends SRTCP? Please provide motivation. 7. Section 4.3.2 second paragraph: I think it is a bit unclear when one uses right as telling which bytes to truncate. I would think that using end or last bytes is better. Also the inclusion of little end here is a bit strange. Where is this defined? It is not a term that I normally encounter. If you are going to use it it should be defined in the terms section. 8. Section 4.3.2 third paragraph || is defined. please put this also in a the definitions section. 9. Section 4.4.1: This section does not take into account that a single sender/issuer may use multiple SSRCs. This case needs to be handled as it is for example one that can result from employing RTP retransmission with SSRC-multiplexing. 10. Section 4.4.2: Isn't each ROC connected to a SSRC. Shouldn't they be bound together and allowed to exist in multiple cases to handle comment 9. 11. Section 5.0: I know that you defines a new attributes for SRTP. However if one runs a totally defaulted session is it still impossible to use the k= attribute? I have understanding that a more competent way is needed. 12. Section 5.1: First sentence: "On each SDP media line (m=) where the is "RTP/SAVP", the offerer MAY follow that media line with at least one a=crypto line." Two things. First I think using better terms on how a line is included in the SDP should be used. Secondly the I think one should be as clear as possible about if one or more is allowed. From my view one or more is clearer than at least, of course context must be considered. However my proposal would be: "Each media description that on its m= lines has a transport parameter of "RTP/SAVP" MAY contain one or more a=crypto line." 13. Section 5.2 first paragraph: I think you have an offer answer error here. Media streams must be included in the answer independently if one is accepting or not, unless the whole session is refused. So the last otherwise seems to be wrong. A refusal of a stream would be performed by setting port to 0. 14. Section 5.3: I think it is badly pointed out that the offerer must be responsible for accepting or refusing the answered security level. 15. Section 5: What is the potentials for performing bid-downs attacks when using this solution. It seems dependent on the security of the SDP transport level. 16. Section 5.6: How does one know from which packet the new keys apply. The synchronization between SIP and RTP are only loose. Wouldn't there be need for including a a complete ROI || seq per SSRC one rekeys? 17. Section 6.2 Second paragraph: Shouldn't the SHOULD here be a SHALL? Any use of these attributes in a SDP that are unprotected END-to-END is a fatal security breach. 18. Section 7.0: I have a number of comments on the grammar: a. The grammar should define already today how the extension mechanism looks. What values that are allowed when defining new usage's. For example "application" should allow an "app-ext" that is then defined. This need for extensions are also true when it comes to cipher defintions. b. One of the defined cipher suits are missing in the grammar. c. The SSRC/ROC must be resolved in the ABNF 19. Section 11. You are missing the IPR statement, see ID-nits. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Mar 16 12:41: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 MAA00340 for ; Sun, 16 Mar 2003 12:41:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GHvf212609 for mmusic-archive@odin.ietf.org; Sun, 16 Mar 2003 12:57:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHveO12606 for ; Sun, 16 Mar 2003 12:57:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00333 for ; Sun, 16 Mar 2003 12:41:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHvVO12592; Sun, 16 Mar 2003 12:57:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHomO12418 for ; Sun, 16 Mar 2003 12:50:48 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00167 for ; Sun, 16 Mar 2003 12:34:16 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2GHaSwv023322 for ; Sun, 16 Mar 2003 18:36:28 +0100 (MET) Received: from era.ericsson.se (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDV36SQZ; Sun, 16 Mar 2003 18:36:25 +0100 Message-ID: <3E74AABD.3070900@era.ericsson.se> Date: Sun, 16 Mar 2003 17:47:57 +0100 X-Sybari-Trust: b17e8588 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP meeting tonight Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, The RTSP meeting taking place today sunday at 21.00 will be in lobby bar. Well meet Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Mar 16 12:43:47 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 MAA00478 for ; Sun, 16 Mar 2003 12:43:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GHxlm12665 for mmusic-archive@odin.ietf.org; Sun, 16 Mar 2003 12:59:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHxkO12662 for ; Sun, 16 Mar 2003 12:59:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00471 for ; Sun, 16 Mar 2003 12:43:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHxcO12653; Sun, 16 Mar 2003 12:59:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHopO12422 for ; Sun, 16 Mar 2003 12:50:51 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00170 for ; Sun, 16 Mar 2003 12:34:20 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2GHaWB3025980 for ; Sun, 16 Mar 2003 18:36:32 +0100 (MET) Received: from era.ericsson.se (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPHKRJRL; Sun, 16 Mar 2003 18:36:31 +0100 Message-ID: <3E74B227.5040208@era.ericsson.se> Date: Sun, 16 Mar 2003 18:19:35 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-srcfilter-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, A number of comments on this draft. 1. The title page headers looks bad. I would suggest that the author list is right justified. Also the expires date should be moved, see ID-nits for the recommendations. 2. The text in the whole draft should be indented in a good way. Normal running text is normally indented 3 characters. This makes the draft easier to read and find headings. 3. The conventions section is normally placed in its own section after the abstract. Location in regards to introduction varies and depends on content. 4. The short copyright statement is missing, see ID-nits 5. Section 2. This section should early declare if the attribute is allowed on session or media level or both. 6. Section 2.1, paragraph three: Does it really work to imply the number of address part of this source filter. Is it totally unforeseeable that a multi-layered media stream using multiple multicast addresses actually has different filters? If not, the case where one source filter contains the first address and another the third is ambiguous. It can either be that the first filter apply to the second address or it is not specified. Please clarify this rule. It can become problematic if one does not want to specify any address as forbidden and still becomes required to include the attribute. It might just be easier to include the number of addresses and explicit about it. 7. Is it never interesting to define the filters based on ports or port ranges? 8. Section 4 & 5. It is customary to have the reference list last to be easy to find. I would appreciate if it is moved to just before copy-right and IPR statements. 9. Section 6: One important security problem for this is how easy it is to do DOS by specifying filters that exclude the correct source. Therefore there is strong need for authentication and also a general warning that SDPs not coming from the session source may not be trusted. 10. The formulation of the IANA section might be better. See draft-ietf-avt-rtcp-feedback for a good IANA section. 11. Appendix A. The syntax used does not match the reference. ABNF according to 2234 uses "/" as alternative markers. Also SP is not defined in RFC 2327. Also the IPv6 address is not defined in RFC 2327. There exist other reference that can be used. See rfc 3266 or you could make this draft dependent on the SDP new draft which contains all the missing ABNF tags I think. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Mar 16 16:45: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 QAA09287 for ; Sun, 16 Mar 2003 16:45:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GM15527959 for mmusic-archive@odin.ietf.org; Sun, 16 Mar 2003 17:01:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GM15O27948 for ; Sun, 16 Mar 2003 17:01:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09250 for ; Sun, 16 Mar 2003 16:44:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GM0wO27832; Sun, 16 Mar 2003 17:00:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLtJO27239 for ; Sun, 16 Mar 2003 16:55:19 -0500 Received: from ns.live.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08932 for ; Sun, 16 Mar 2003 16:38:42 -0500 (EST) Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.8/8.12.5) with ESMTP id h2GLerH2053361 for ; Sun, 16 Mar 2003 13:40:53 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.8/8.12.3/Submit) id h2GLer5p053358; Sun, 16 Mar 2003 13:40:53 -0800 (PST) Message-Id: <4.3.1.1.20030316131612.00b8b5a0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 16 Mar 2003 13:40:42 -0800 To: mmusic@ietf.org From: Ross Finlayson Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-srcfilter-03.txt In-Reply-To: <3E74B227.5040208@era.ericsson.se> 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: , Magnus, Thanks for the feedback. Addressing the substantive (i.e., non-syntactic) comments: >6. Section 2.1, paragraph three: Does it really work to imply the number >of address part of this source filter. Is it totally unforeseeable that a >multi-layered media stream using multiple multicast addresses actually has >different filters? If not, the case where one source filter contains the >first address and another the third is ambiguous. It can either be that >the first filter apply to the second address or it is not specified. >Please clarify this rule. Good point. The issue here is how to specify source filters if the SDP 'connection address' specifies multiple multicast addresses, e.g. c=IN IP4 224.2.1.1/127/3 There are a number of possible ways to deal with this: 1/ Specify that the source filter line must use the first multicast address only, but that it applies to all of the possible multicast addresses in the range. (E.g., in the example above, it would not be possible to specify different source filters for 224.2.1.1 and 224.2.1.3. Also, it would be illegal for the source filter line to use any multicast address other than 224.2.1.1.) 2/ Specify that the source filter line contains individual multicast addresses only. To specify source filters for a range of multicast addresses, there must be an individual source filter line for each one - e.g., a=source-filter: incl IN IP4 224.2.1.1 192.168.9.10 a=source-filter: incl IN IP4 224.2.1.3 192.168.9.42 Note that in this example, there would *not* be any source filter for 224.2.1.3.2 3/ Change the source filter specification to include the "/" field. But then, for consistency, should we also require the "/" field, even though it's useless? Also, what would the following mean: a=source-filter: incl IN IP4 224.2.1.2/127/2 192.168.9.10 a=source-filter: incl IN IP4 224.2.1.1/127/3 192.168.9.42 and would the meaning change if the order of these two lines were reversed? Personally, I think that option 1 is too restrictive, and option 3 far too complicated, and too difficult to understand. For this reason, I'd prefer option 2: Require individual source filters for each multicast address in a range. Any comments? >7. Is it never interesting to define the filters based on ports or port >ranges? (Presumably you mean *source* ports here, right?) Noone has ever expressed an interest in specifying this, but if someone wanted this, I guess they could define a separate attribute for this - e.g., "a=source-port-filter:" or something... >9. Section 6: One important security problem for this is how easy it is to >do DOS by specifying filters that exclude the correct source. Therefore >there is strong need for authentication and also a general warning that >SDPs not coming from the session source may not be trusted. If one could generate a fake SDP description that specified a bogus source filter, then they could have just as easily specified bogus *destination address(es)*. I.e., a SDP description always needs to be 'trusted', and the presence of source filter lines doesn't make any this more (or less) important Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 17 00:14:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20208 for ; Mon, 17 Mar 2003 00:14:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5UWR22173 for mmusic-archive@odin.ietf.org; Mon, 17 Mar 2003 00:30:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5UWO22170 for ; Mon, 17 Mar 2003 00:30:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20171 for ; Mon, 17 Mar 2003 00:13:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5UPO22156; Mon, 17 Mar 2003 00:30:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5RBO22093 for ; Mon, 17 Mar 2003 00:27:11 -0500 Received: from wullbinkle.real.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20112 for ; Mon, 17 Mar 2003 00:10:25 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2-glompatched/8.12.2) with ESMTP id h2H5CYgr018361 for ; Sun, 16 Mar 2003 21:12:34 -0800 Received: from wl-139-214.wireless.ietf56.ietf.org (wl-139-214.wireless.ietf56.ietf.org [130.129.139.214]) by real.com (8.12.2-glompatched/8.12.2) with ESMTP id h2H5CY4w011997 for ; Sun, 16 Mar 2003 21:12:34 -0800 From: Rob Lanphier To: mmusic@ietf.org Content-Type: multipart/mixed; boundary="=-a7N3nAUL+e9Y8QJwgMjo" Message-Id: <1047877956.2544.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 21:14:31 -0800 Subject: [MMUSIC] Minutes from March 5 telecon Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --=-a7N3nAUL+e9Y8QJwgMjo Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all, Below are the minutes for the RTSP telecon from March 5. Sorry for the delay. Rob -- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com --=-a7N3nAUL+e9Y8QJwgMjo Content-Disposition: attachment; filename=minutes20030305.txt Content-Type: text/plain; name=minutes20030305.txt; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit = Attendees = * Magnus Westerlund * Sean Sheedy * Colin Perkins * Tom Marshall * Rob Lanphier * Aravind Narasimhan * Thomas Zeng * Anders Klemets * Andrea Basso = Minutes = == Summary from last telecon == * Magnus: (summarizes status of draft 03) * Magnus: please review for minor issues, etc * Magnus: we should take one meeting post-IETF to review draft03 * Magnus: did you have time to review interleaving spec? * Aravind: not yet * Magnus: we've got a number of things we need to mention at next IETF meeting * Magnus: one thing we should point out that the URL BNF now contains fragment identifier * Magnus: removal of ANNOUNCE/RECORD * Magnus: rtspu and rtsps removed * Magnus: ssrc changes * (discussion involving specifying non-contiguous ports for eg. STUN. Comma is already used in Transport: header as a separator, so / was proposed) * Thomas: is port-port correct? * Magnus: yes * Thomas: did we agree to include comma in port spec? * Thomas: what about colon * Magnus: used in MIME spedc * Magnus: we need to prepare IETF presentation next week. will take to list. * Magnus: need to discuss NAT strategy * Magnus: need to schedule offline meetings * (scheduled meeting for Sunday 9pm, March 16) == Bug #513737 == * http://rtsp.org/bug513737 * Sean: easier for error recovery if string is left alone * Magnus: parameters need to be changed in atomic way * Anders: is there a contradiction here? * Magnus: someone want to write this up? * Magnus: resolution, go with alternative #1 from bug report (1. Keep the old setting and states as if the second SETUP never happend.) * Magnus: next issue is one that is already closed * (skipping http://rtsp.org/bug539040) == Bug #539040 and Bug #539040 == * http://rtsp.org/bug539040 * http://rtsp.org/bug539040 * Magnus: how to use range when scale is backwards * Aravind: should always go from lower to higher * Aravind: e.g. to go backwards from 45 sec, say "-45s" (assuming BNF supports it) * Magnus: BNF supports * Thomas: I agree * Magnus: problem is range is specified as half open interval * Sean: I think we should play from first number to second number (opposite of what I'm hearing as predominant view) * Anders: agreed * Aravind: ok, makes sense * Thomas: makes sense to me too * Magnus: anyway, we need to resolve this * Magnus: agree that range is always from first value to second value * Aravind: if scale not there, and range is not there, then its an error * Magnus: yes * Andrea: is offer answer to be discussed? * Magnus: no, that's at next IETF meeting * Magnus: resolved: range is always from first value to second value * Aravind: if scale is not there, and range is bigger to smaller, then its an error * Magnus: any volunteers to write up? * Aravind: I can take this on * Magnus: need examples * Aravind: ok, I can do that == Bug #556061 == * http://rtsp.org/bug556061 * Magnus: lack of clarity in state machine * Magnus: Tom, is the new REDIRECT text clear enough? * Tom: I think you need to allow REDIRECT at any time. If a client can disconnect at any time, then the server needs to be able to redir at any time * Tom: the phrase i was looking for is connectionless control * Magnus: need to add REDIRECT into INIT state * Magnus: need to add server to client redirect possibility here * Magnus: should add some sentences in the REDIRECT section to clarify that this can be sent at any time. Any comments on that? * Thomas: makes sense * Magnus: resolution: add text to REDIRECT section, and add to state machine * Aravind: clarify whether full session reestablishment is necessary * Magnus: yes it is, seems to be covered in 11.9 * Andrea: need to reestablish? * Magnus: yes..one may have buffer depth to pull it off * Andrea: any provision for continuous service? * Magnus: no guarantees...example is redirect for end of live session. Another is power failure. * Andrea: there's an implicit cost, because full setup is needed * Magnus: yes == Bug #556295 == * http://rtsp.org/bug556295 * Client issues PAUSE while server ready * If a client issues a PAUSE and the server acknowledges and enters ready state, what is proper server response. If the player issues another PAUSE? There appear to be two possible correct behaviors: * server responds with OK because it does not change state and does no harm. * server responds with error 455 because PAUSE does not make sense in this state. * Sean: I think that issuing PAUSE is an error, but I don't see any big advantage to returning an error, either. Don't want to break implementations * Magnus: we can say that it is ok * Magnus: what about when there's a range header involved * Aravind: what about using it to reset pause point? * Magnus: pause is something you send after you are in the play state * Aravind: I don't see the problem with setting the pause point using pause * Aravind: we could break backwards compatibility if we issue error when getting pause in ready state * Thomas: are you saying that range doesn't matter? * Magnus: yes * Thomas: how does client know whether or not it has made a mistake in sending PAUSE in ready? * Magnus: pause response actuallly includes pause point * Tom: behavior with pause should mirror behavior with play * Tom: if pause while paused is allowed, play while playing is allowed * Thomas: we don't have queued play * Rob: why is symmetry important? * Thomas: it would make the spec make more sense * Rob: the reason for asymmetry with PAUSE is that it PAUSE in READY doesn't introduce same problems as PLAY while PLAYING * Aravind: just need clarity, not symmetry * Magnus: timed PAUSE request does introduce problems * Aravind: what happens when you have a timed pause request, and then a normal pause request, what happens? * Thomas: I think the earliest of the PAUSE requests is effective * Magnus: my interpretation of the spec is that all should be interpreted * Magnus: maybe we should eliminate timed PAUSE altogether * Aravind: we need to sort out dependence * Rob: range response is ambiguous in the case of timed PAUSE * Thomas: timed PAUSE doesn't seem useful * Tom: any use cases? * Aravind: maybe some live streams * Thomas: even that can be handled with PLAY with Range: * Magnus: one question: shoudl we remove time from the Range header, or should we say you can't use it * Andrea: do you have limit on range? * Magnus: looks like we should look into removing time * Magnus: next meeting, April 2? == RTSP NAT == * Thomas: Concerned about performance issues with having separate port for each RTP session * Colin: There are ways to alleviate the performance concerns. Linux has a hashtable that you can stick into the poll processing * Tom: Not always have choice about platform * Tom: Solaris has /dev/poll, NT has callbacks * Colin: Don't want to settle one something that is incompatible with RTP * Colin: All the proposal I'm hearing on the mailing list look to be non-backwards compatible * Thomas: Symmetric RTP is not backwards compatible. We are proposing that * Magnus: Issues it that we need to add some field in RTSP to enable NAT traversal * Colin: We can probably talk about this for another hour. . . . * Aravind: I'm not sure what else was talked about, but people can add their comments to the minutes. --=-a7N3nAUL+e9Y8QJwgMjo-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 17 11:59: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 LAA20377 for ; Mon, 17 Mar 2003 11:59:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HHGME16035 for mmusic-archive@odin.ietf.org; Mon, 17 Mar 2003 12:16:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHGMO16032 for ; Mon, 17 Mar 2003 12:16:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20354 for ; Mon, 17 Mar 2003 11:59:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHGDO16023; Mon, 17 Mar 2003 12:16:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHD5O15872 for ; Mon, 17 Mar 2003 12:13:05 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20227 for ; Mon, 17 Mar 2003 11:56:05 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2HGwHwv001891; Mon, 17 Mar 2003 17:58:17 +0100 (MET) Received: from era.ericsson.se (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVP14LX; Mon, 17 Mar 2003 17:58:16 +0100 Message-ID: <3E75F2B0.6000203@era.ericsson.se> Date: Mon, 17 Mar 2003 17:07:12 +0100 X-Sybari-Trust: 6c22ca29 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Ross Finlayson CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-srcfilter-03.txt References: <4.3.1.1.20030316131612.00b8b5a0@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, See below: Ross Finlayson wrote: > Magnus, > > Thanks for the feedback. Addressing the substantive (i.e., > non-syntactic) comments: > >> 6. Section 2.1, paragraph three: Does it really work to imply the >> number of address part of this source filter. Is it totally >> unforeseeable that a multi-layered media stream using multiple >> multicast addresses actually has different filters? If not, the case >> where one source filter contains the first address and another the >> third is ambiguous. It can either be that the first filter apply to >> the second address or it is not specified. Please clarify this rule. > > > Good point. The issue here is how to specify source filters if the > SDP 'connection address' specifies multiple multicast addresses, e.g. > c=IN IP4 224.2.1.1/127/3 > > There are a number of possible ways to deal with this: > > 1/ Specify that the source filter line must use the first multicast > address only, but that it applies to all of the possible multicast > addresses in the range. (E.g., in the example above, it would not be > possible to specify different source filters for 224.2.1.1 and > 224.2.1.3. Also, it would be illegal for the source filter line to > use any multicast address other than 224.2.1.1.) > > 2/ Specify that the source filter line contains individual multicast > addresses only. To specify source filters for a range of multicast > addresses, there must be an individual source filter line for each one > - e.g., > a=source-filter: incl IN IP4 224.2.1.1 192.168.9.10 > a=source-filter: incl IN IP4 224.2.1.3 192.168.9.42 > Note that in this example, there would *not* be any source filter for > 224.2.1.3.2 > > 3/ Change the source filter specification to include the > "/" field. But then, for consistency, should we > also require the "/" field, even though it's useless? Also, what > would the following mean: > a=source-filter: incl IN IP4 224.2.1.2/127/2 192.168.9.10 > a=source-filter: incl IN IP4 224.2.1.1/127/3 192.168.9.42 > and would the meaning change if the order of these two lines were > reversed? > > Personally, I think that option 1 is too restrictive, and option 3 far > too complicated, and too difficult to understand. For this reason, > I'd prefer option 2: Require individual source filters for each > multicast address in a range. Any comments? I am fine with two. It will be clear and simple at the small cost of possibly having to duplicate lines in cases the same filter applies to several address in a range. > > >> 7. Is it never interesting to define the filters based on ports or >> port ranges? > > > (Presumably you mean *source* ports here, right?) Noone has ever > expressed an interest in specifying this, but if someone wanted this, > I guess they could define a separate attribute for this - e.g., > "a=source-port-filter:" or something... > Actually, no. I was thinking of destination ports. It was around the same lines of the multiple addresses in one line. I think it is very common that a single multicast address is used to deliver both audio and video. In this case these streams may be produced on different entities and would still likes to be the only valid source. It is a corner case, however I think it should be addressed in someway. Either by acknowledging that it is not possible or fix so that it works. I have no real view on the usefulness of these, I just want to ensure that it as been thought through. > >> 9. Section 6: One important security problem for this is how easy it >> is to do DOS by specifying filters that exclude the correct source. >> Therefore there is strong need for authentication and also a general >> warning that SDPs not coming from the session source may not be trusted. > > > If one could generate a fake SDP description that specified a bogus > source filter, then they could have just as easily specified bogus > *destination address(es)*. I.e., a SDP description always needs to be > 'trusted', and the presence of source filter lines doesn't make any > this more (or less) important Okay, you might be right that it is no different than changing the destination address to one that any attacker control. The point being that SDPs should be authenticated. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 17 13:15: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 NAA23275 for ; Mon, 17 Mar 2003 13:15:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIWPG22006 for mmusic-archive@odin.ietf.org; Mon, 17 Mar 2003 13:32:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIWPO22003 for ; Mon, 17 Mar 2003 13:32:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23272 for ; Mon, 17 Mar 2003 13:15:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIWHO21993; Mon, 17 Mar 2003 13:32:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HITjO21888 for ; Mon, 17 Mar 2003 13:29:45 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23213 for ; Mon, 17 Mar 2003 13:12:44 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (wl-140-222.wireless.ietf56.ietf.org [130.129.140.222]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h2HIGk814741 for ; Mon, 17 Mar 2003 13:16:47 -0500 Message-Id: <5.1.1.6.0.20030317124242.0369a1c0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 17 Mar 2003 13:14:52 -0500 To: mmusic@ietf.org From: David Yon Subject: Re: [MMUSIC] A proposal for comedia-06 security section In-Reply-To: <5.1.1.6.0.20030314220448.00b3e9d8@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Jonathan brought up the issue of forked-INVITE WRT my examples and the ability of Alice or Bob to detect a hijack attempt. Thinking this through, I'm not yet convinced this is a issue for the security issue, but rather the forked-INVITE scenario is not explicitly addressed in comedia-05. Here's a normal forked-INVITE exchange without an attacker (Alice, Bob, and Dan, where Bob "wins" the forked-INVITE): Alice Proxy Bob Dan Offer -------> Offer ----> | +------------------> <--------------------CONNECT <-----------------------------------CONNECT <----Answer <---------Answer <------------------Answer Cancel-------------------> connections arrive as a result of a forked-INVITE, that will eventually unwind back to a single connection. The question is: when and how does Alice know which of the connections will be the actual connection used for the session? This is a real problem (oh boy, another reason to delay comedia!), so I think the question needs to have an answer. I would submit that if you can answer the above question, then the scenarios I presented at the meeting are still valid, albeit somewhat simplified. I.e., *eventually* Alice will know that it should have one connection but has more, and therefore can detect the attack. And to throw more wood on the fire, it starts to get non-trivial when you consider cases like Bob's connection setup being blocked but not Dan's. For example: Alice Proxy Bob Dan Offer -------> Offer ----> | +------------------> X--CONNECT <-----------------------------------CONNECT <----Answer <---------Answer <------------------Answer Cancel-------------------> \ >FULL CONNECTIVITY: > >Alice Carol Bob > >Offer -----------------> > <------CONNECT >?? <------------------ CONNECT > <------------------ Answer > CONNECT----> > > >The ?? shows that Alice or Bob has detected a duplicate media connection >and therefore has enough information to infer a possible attack. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 17 13:27: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 NAA23851 for ; Mon, 17 Mar 2003 13:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIiOb23587 for mmusic-archive@odin.ietf.org; Mon, 17 Mar 2003 13:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIiOO23584 for ; Mon, 17 Mar 2003 13:44:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23800 for ; Mon, 17 Mar 2003 13:27:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIiCO23497; Mon, 17 Mar 2003 13:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIfKO23279 for ; Mon, 17 Mar 2003 13:41:20 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23585 for ; Mon, 17 Mar 2003 13:24:19 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2HIQThs029130; Mon, 17 Mar 2003 10:26:30 -0800 (PST) Received: from DWINGW2K4 (sjc-vpn4-100.cisco.com [10.21.80.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AFC87297; Mon, 17 Mar 2003 10:25:10 -0800 (PST) From: "Dan Wing" To: "David Yon" , Subject: RE: [MMUSIC] A proposal for comedia-06 security section Date: Mon, 17 Mar 2003 10:26:28 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.1.6.0.20030317124242.0369a1c0@mail.rfdsoftware.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ... > If this was not a forked-INVITE, Alice would know that she needs > to attempt > a connection to Bob, as a connection hadn't arrived when the > Answer arrives > via the proxy. But here we have a connect succeed from Dan, then a short > time later it terminates. So how does Alice differentiate this > forked-INVITE scenario from a failed media setup scenario? Likewise, an attacker could actively prevent the media from being setup. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 17 13:32: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 NAA24195 for ; Mon, 17 Mar 2003 13:32:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HInGl23927 for mmusic-archive@odin.ietf.org; Mon, 17 Mar 2003 13:49:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HInGO23924 for ; Mon, 17 Mar 2003 13:49:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24157 for ; Mon, 17 Mar 2003 13:32:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIn7O23914; Mon, 17 Mar 2003 13:49:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIkuO23807 for ; Mon, 17 Mar 2003 13:46:56 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24003 for ; Mon, 17 Mar 2003 13:29:55 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (wl-140-222.wireless.ietf56.ietf.org [130.129.140.222]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h2HIW7815406; Mon, 17 Mar 2003 13:32:07 -0500 Message-Id: <5.1.1.6.0.20030317132737.0369a1c0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 17 Mar 2003 13:30:14 -0500 To: "Dan Wing" , From: David Yon Subject: RE: [MMUSIC] A proposal for comedia-06 security section In-Reply-To: References: <5.1.1.6.0.20030317124242.0369a1c0@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Well, this maps to my scenario 4 (and all of my scenarios result in DoS as the best case), I don't see how forked-INVITE fundamentally changes the equation... At 01:26 PM 3/17/2003, Dan Wing wrote: >... > > If this was not a forked-INVITE, Alice would know that she needs > > to attempt > > a connection to Bob, as a connection hadn't arrived when the > > Answer arrives > > via the proxy. But here we have a connect succeed from Dan, then a short > > time later it terminates. So how does Alice differentiate this > > forked-INVITE scenario from a failed media setup scenario? > >Likewise, an attacker could actively prevent the media from being setup. > >-d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 17 17:51: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 RAA05601 for ; Mon, 17 Mar 2003 17:51:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HN8Gq12193 for mmusic-archive@odin.ietf.org; Mon, 17 Mar 2003 18:08:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HN8GO12190 for ; Mon, 17 Mar 2003 18:08:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05594 for ; Mon, 17 Mar 2003 17:51:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HN8BO12174; Mon, 17 Mar 2003 18:08:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HN5YO11307 for ; Mon, 17 Mar 2003 18:05:34 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05502 for ; Mon, 17 Mar 2003 17:48:28 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (wl-134-184.wireless.ietf56.ietf.org [130.129.134.184]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h2HMqR826054; Mon, 17 Mar 2003 17:52:28 -0500 Message-Id: <5.1.1.6.0.20030317161719.03923300@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 17 Mar 2003 17:50:07 -0500 To: mmusic@ietf.org From: David Yon Subject: Re: [MMUSIC] A proposal for comedia-06 security section Cc: Jonathan Rosenberg In-Reply-To: <5.1.1.6.0.20030317124242.0369a1c0@mail.rfdsoftware.com> References: <5.1.1.6.0.20030314220448.00b3e9d8@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , After talking this over with some of the folks here, it's clear that perhaps that the three-way handshake is the Grand Simplifying Notion(tm). SIP has this property, and to date it is SIP that is the only protocol causing grief with the forking-INVITE. So, my assertion is that forking-INVITE ceases to be a problem if the condition described in section 4 of comedia is defined to be the ACK message from Alice rather than the 200 response from Bob. Taking my earlier forking INVITE example, here's what happens: Alice Proxy Bob Dan Offer -------> Offer ----> | +------------------> <----Answer <---------Answer <------------------Answer Cancel-------------------> CONNECT -------------------> ACK -------------------> By delaying the initiation of the connect-then-answer listed in section 4(b/c) to the transmission of the ACK, we've allowed the fork to collapse back to a pair of endpoints before any connections are initiated. So instead of dealing with the large permutations caused by the 1-to-n fan-out of Alice to possible destinations, we're back to just Alice and Bob (Bob being defined to always be the "winner" of the forked INVITE). With this in mind, there are now five unique scenarios of Alice, Bob, and Carol: 1) FULL CONNECTIVITY (OR BOB CANNOT CONNECT TO ALICE): Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT-------> CONNECT----------------------> ?? ACK -----------------------> <--------CONNECT ===================================== 2) ALICE CANNOT CONNECT TO BOB: Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT-------> CONNECT----X ACK -----------------------> <--------CONNECT Hijack! ===================================== 3) ALICE/CAROL CANNOT CONNECT TO BOB: Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT--X CONNECT----X ACK -----------------------> <--------CONNECT ?? <-----------------------CONNECT ===================================== 4) CAROL CANNOT CONNECT TO ALICE (OR CAROL/BOB CANNOT CONNECT TO ALICE): Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT-------> CONNECT----------------------> ?? ACK -----------------------> X--CONNECT ===================================== 5) CAROL CANNOT CONNECT TO BOB: Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT--X CONNECT----------------------> ACK -----------------------> <--------CONNECT ====================================== So there are two possible problems. The first is #2, where the connection can be hijacked. The second is #5, where the stakes are raised for Alice to choose correctly between the connection to Bob and the connection to Carol. #2 has the same mitigation strategy as before---if Alice is on the public Internet and Bob is not, then Alice should use direction:passive. #5 is trickier, any thoughts are welcomed. Jonathan, you mentioned that there were some permutations of Offer/Answer that may upset this particular apple cart. Now that this has been all laid out, what say you on this topic? At 01:14 PM 3/17/2003, David Yon wrote: >Temporarily flipping to a SIP-centric worldview, wouldn't one answer be to >map comedia section 4 (b/c) to the ACK message from Alice rather than the >OK reply from Bob? This doesn't answer the question for two-way >handshakes, but it seems to for three-way. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Mar 18 13:57: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 NAA23947 for ; Tue, 18 Mar 2003 13:57:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJEbc08596 for mmusic-archive@odin.ietf.org; Tue, 18 Mar 2003 14:14:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJEaO08593 for ; Tue, 18 Mar 2003 14:14:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23900 for ; Tue, 18 Mar 2003 13:57:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJEMO08524; Tue, 18 Mar 2003 14:14:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJ9gO08267 for ; Tue, 18 Mar 2003 14:09:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23735 for ; Tue, 18 Mar 2003 13:52:10 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IIsOHQ026259 for ; Tue, 18 Mar 2003 19:54:24 +0100 (MET) Received: from era.ericsson.se (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVP30TN; Tue, 18 Mar 2003 19:54:23 +0100 Message-ID: <3E776B5A.5070209@era.ericsson.se> Date: Tue, 18 Mar 2003 19:54:18 +0100 X-Sybari-Trust: 1fa5b7e7 d6a25af5 ec03b945 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP notes on ad-hoc meetings at IETF 56 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, Below is RTSP meeting notes from the sunday and monday. This is my interpretation of what was discussed. Please comment if something is missing or something is in error. Best Regards Magnus --------------------- Minutes of meetings for the two RTSP discussion meeting during IETF 56. First meeting Sunday 21.00-23.15 16th April 2003 Participants Sean Sheedy Rob Lanphier Tom Marshall Andrea Basso Anders Klements Henning Schulzrinne Colin Perkins Joerg Ott Thomas Zheng Started with looking at the proposed presentation slides for the MMUSIC WG meeting presentation. - Some short clarification on the usage of relative URL's for RTP-Info and having the Request URL as base for the this relative URL. - A note that although we need support for Non-persistent connections a client is RECOMMENDED to keep the connection until it has finished all its sessions and signaling. The slides may not look like that they argue for persistent connection, but only as above. We need the non-persistentency to handle sessions in a reliable way. Offer-Answer ------------ We discussed on how one could, and why one, would include a Offer Answer model into RTSP. Use cases that where discussed were: - Stream switching, one way of deciding which alternatives that can be used in switching would to use Offer-Answer to negotiate accepted alternatives. - Capability exchange to determine if the a client can handle a stream and enable the server to tailor a presentation to fit the client. A Important note in RTSP is that the capabilities are often restricted and can't be freely negotiated. For any on-demand multi-media presentation the capabilities are always dependent on the content creation step. Only what is available can be tailored. Content may also be restricted in what ways it can be adapted by the content creator. A possible way of having more latitude of capabilities are usage of transcoding functionality in servers. It is also important to remember that RTSP uses session description in a uni-directional way which is different from normal SIP usage where the offer and answer is bi-directional. Possible solutions. A. Server if offerer and offers all that is available in regards to a stream. This could be done in DESCRIBE responses. The client is the Answerer and MAY then reduce the set of offered alternatives into an answer. A response could be included in the SETUP request. However this has some implications about binding answer to session and the SETUP requests. You can either send the answer in the first SETUP request and all future SETUP into that session uses the applied Answer. This has the implications that a aggregated session is much easier and does not require multiple sending of an Answer. Another alternative is to split an answer into answers for individual media streams. The answer could also be done by a new method to establish State in the server that the SETUP can then bind to. We will need a mechanism that could actually allow one to do multiple rounds of offer answer if the answer is not acceptable. However in most cases it seems possible that offer-answer should resolve in a single exchange. B. Another scenario is that the client is the offerer. It sends the server its capabilities. Then the server would send an answer containing a matched presentation for the requested resource. A method would be DESCRIBE or similar. Then one must simply bind the offer answer agreement to a session. This is similar to what 3GPP PSS has available when one uses UAProf. C. A half way case. A client retrieves a session description. The client creates an offer on what it can accept of this. The server would then answer with if this is suitable. Considerations for selecting a possible solution is: - What type of states must reside on the which sides? - The amount of bandwidth that will be used by the offers and answers. Resolution: It seems interested and has some good use cases. However no one committed to create some ground breaking work in this area in form of use case and requirements draft. RTSP IANA registration requirements ----------------------------------- We discussed this a long time but could actually not come to any general conclusions. - The was proposal that we could have permanent registrations that must be stable specifications. While proprietary registrations could be bound in time and if not renewed they would be removed from registry. However the problems are: The reclaiming mechanism. And what happens when a registered value are in wide use but the owner are no longer active in the are. - It might be hard to swear to long from what they have defined in SIP & HTTP without having a good use case. - The registration rules can be really customized and allows us to write rules for what a registration requires. - Remember the x- problem that it might be better to allow for good names from the beginning. Vendor tree of registration would basically have the x- problem. - Most of the registries are in fact unlimited. All having free width text fields has no limit. - Feature tags seems one that will be used in proprietary ways. However the question is if there is need for interoperability and collision avoidance that the registry supplies. Some discussion around having First come first served and a one paragraph description of the feature tag as minimum rules. - Most agree that IETF standard tracks operation is suitable for Methods. Some voiced that restricting it to much would result in divergence. However this strictness may result in that all functionality is moved to SET_PARAMETER and headers. - For headers there where discussion on splitting this into, a Vendor tree with tags that allow vendor registration, and a IETF tree which requires IETF standards track. However there was also other considerations that Public specification might be enough. Or even a lower level as there exist proprietary headers. - The Transport header repositories for Protocol/profile/lower-transport to had as an triplet in a common registry. Public specification was agreed on. This can be defined by other standards body to allow them to adapt RTSP for there transport techniques. Second meeting Monday 13.00-15.00 17 April 2003 Second meeting participants: Magnus Westerlund Rob Lanphier Tom Marshall Phillipe Gentric Sean Sheedy Anders Klemets Thomas Zheng Andrea Basso * Stream-switching discussion We started by discussing around stream switching. Comments raised was: - We need to find good terminology. Stream switching are not really what we are talking about. - The goal is to have switching between considerable different streams. - We should consider the extreme cases to handle all normal cases. - An offer answer model could be used to select what alternative that are desired. - We have problem with caching proxies when we performs switches between different alternatives. There was some discussion on different possibilities to mark packets on what alternative they belong to. - RESOLUTION: Phillipe Gentric writes a requirement draft with use cases. * Ways to allow usage of Destination parameter The goal would be to find ways that give good enough security that a server can be allowed to send media traffic to a media receiver. - The easiest way of ensuring that a receiver accepts the media traffic is to ask it. Therefore the server could send a message to ask the receiver if it accepts to receive the traffic. The receiver responds. When the server receives a response it knows if it is allowed or not. - We could use the fallback rule that all client requesting media to the same address as there RTSP message connection comes from does not need to use this mechanism but MAY be used. => Gives backwards compatibility and makes it possible to deploy. - A server should or shall not send media until media acceptance challenge is responded. - A short term solution would be to require RTCP messages from other end-point to be able to send media. - RTCP RR are rather simple to spoof as the start RTP sequence number is known. - However it would still lower the force multiplier a RTSP server would give for performing a DOS attack. What I mean with force multiplier is the amount of work a attacker needs to do get a certain amount of affect at the target. - To get a guaranteed secure mechanism we would need to have way of source authenticating the media receiver target. - How do we handle multicast receiver addresses? - Should ask security expert for suggestions when we have described the problem well. - Write a problem description draft. - We should also look at having a general mechanism as this seem to be a problem all media transport can end up in. This is probably something that SIP has been ignoring and has not considered. RESOLUTION: Phillipe Gentric will write a basic problem description draft. * RTSP & NAT problems Some minor discussion. Important comments: TURN will not work unless we allow different IP address as the TCP RTSP will be directly from client while all media destinations will be the TURN servers IP. The STUN vs. Symmetric RTP discussion. - The port usage of symmetric RTP is a reality problem for large servers. May need to consider a solution that allows a trade off between port usage and security. - Even if we haven't seen any actual case of multiple IP address NATs, it seems probable that wireless operators will deploy large scale NATs that will be simple and will result in one client streams end up on different IP addresses. - We should include NAT implementor recommendations/requirements telling that a NAT should for any client only give a single IP on the public address. - We discussed the need for ALG implementations recommendations. Especially the need for avoiding messing up the other methods. The recommendation would that any request containing a destination address shall not be touched by the ALG. This also effects the client behavior. - Firewalls where discussed. It seems that there exist three basic types. 1. A simple home NAT & FW box that simple opens ports and maps them to the machine that punched open the whole in the wall. This makes this equivalent with a Cone NAT. 2. A UNIX/Linux software FW that actually are more restricted and looks at the source IP and decide if the private side has pounced a hole towards this address or not. Makes the FW equivalent to a symmetric NAT. 3. Corporate FW. This ones is really paranoid and will block all unknown and not allowed traffic. Often make statefull inspection. To get RTSP and media transport on UDP through this types requires a policy allowing RTSP and requires ALG functionality to allow for UDP media traffic. * Allowing for multiple SSRC in RTSP. - The problem is that any media stream having multiple SSRCs can't be initially synchronized with RTP-Info. Fortunately RTCP SR provides a fall back for this. RTSP has SSRC issues in two places: 1. Transport header, 2. RTP-Info where RTP sequence number and RTP timestamp are related to a SSRC but not explicit present. - The transport header may not need that the server informs the client on what SSRC it will use. - The right thing would to redefine the RTP-Info header to allow for multiple SSRCs and their sequence number and timestamp. - Will not be backwards compatible. This has implications on how it can be handled. Either simply redefine in the updated and forcing one to keep track of updated or not implementations. The other would be to ignore this problem. - As fallback for old implementations is to use RTCP for this synchronization. * Removal of Timed request - Consensus to disallow if for now. The syntax may be left in for backwards completeness. * How to distinguish the updated specification. - Due to multiple SSRC discussion we revisited mechanisms to distinguish a updated server. One possible solution would to upgrade the version to 1.1. We should consider this more in the future when we comes closer to a finished specification. - Should look into more detail how this should work and if we adapt HTTP model? * Warning header - Could be good to provide more information about what happens in certain cases and for debugging. - Needs to look into HTTP and SIP for more consideration how to use it. - Any addition should be considered if this will delay the new updated draft. - Needs more consideration. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 19 13:57:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00748 for ; Wed, 19 Mar 2003 13:57:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJEcw23296 for mmusic-archive@odin.ietf.org; Wed, 19 Mar 2003 14:14:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJEcO23293 for ; Wed, 19 Mar 2003 14:14:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00730 for ; Wed, 19 Mar 2003 13:56:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJEXO23273; Wed, 19 Mar 2003 14:14:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJAFO22993 for ; Wed, 19 Mar 2003 14:10:15 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00532 for ; Wed, 19 Mar 2003 13:52:15 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18vihp-00082O-00 for ; Wed, 19 Mar 2003 10:54:29 -0800 Date: Wed, 19 Mar 2003 10:54:29 -0800 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030319185429.GA30759@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [MMUSIC] What is symmetric RTP? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have been doing a bit of digging, trying to find an exact definition of "Symmetric RTP" -- that is, what exactly is it, and how it should be used.= =20 Ironically, the biggest reference to Symmetric RTP (according to google) seems to be the recent discussions on this mailing list. The draft draft-ietf-mmusic-sdp-comedia-04.txt was mentioned at one point.= =20 It has now expired. I found a cached copy and read it. It does seem to provide some brief explanation of how to do Symmetric RTP, but it does not look detailed enough. Section 8.5 is titled "Example: "Bidirectional" RTP and RTCP" and it says only "... immediately sends RTP from ..." and "... immediately sends RTCP from ..." with no explanation of the expected packet contents. I would like to see Symmetric RTP defined more precisely, both for our own use and for comedia. What do others think? Would someone like to clarify usage, provide examples, start a draft, etc? --=20 Harrison's Postulate: For every action, there is an equal and opposite criticism. --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+eLzlqznSmcYu2m8RAsX0AJ9SJLPmYWxKgUT65CFcxtHI7Ps0GQCeOr/y KWMvvpqASkZ5BnaNJ+UnZzY= =xTuz -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 19 23:47: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 XAA24994 for ; Wed, 19 Mar 2003 23:47:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K55Je08623 for mmusic-archive@odin.ietf.org; Thu, 20 Mar 2003 00:05:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K55IO08620 for ; Thu, 20 Mar 2003 00:05:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24989 for ; Wed, 19 Mar 2003 23:47:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K55EO08612; Thu, 20 Mar 2003 00:05:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K52KO08503 for ; Thu, 20 Mar 2003 00:02:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24807 for ; Wed, 19 Mar 2003 23:44:07 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2K4kMbh008696; Thu, 20 Mar 2003 05:46:22 +0100 (MET) Received: from era.ericsson.se (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HH5P7VF9; Thu, 20 Mar 2003 05:46:21 +0100 Message-ID: <3E79479E.1090807@era.ericsson.se> Date: Thu, 20 Mar 2003 05:46:22 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] What is symmetric RTP? References: <20030319185429.GA30759@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom, I agree that the term symmetric RTP is really not defined in any document. I have one view of this that is a result of following discussions around NATs in AVT, SIPPING, and MMUSIC. In my view people often mean two things when they are talking about symmetric RTP. 1. The sending and receiving of RTP from the same port. This was the case in the ancient days, :-), of multicast usage and RAT . However then the SIP and some other people come around and distorted this view with not using the same port for receiving and sending. 2. The usage of a received message to determine the destination address. This is I think the main idea when performing NAT traversal. Of course 1 must be used to make it work, however this is simple. It is the second usage that has some problems. One possible place to better define symmetric RTP could be the RTSP NAT draft. Best Regards Magnus Tom Marshall wrote: >I have been doing a bit of digging, trying to find an exact definition >of >"Symmetric RTP" -- that is, what exactly is it, and how it should be >used. >Ironically, the biggest reference to Symmetric RTP (according to google) >seems to be the recent discussions on this mailing list. > >The draft draft-ietf-mmusic-sdp-comedia-04.txt was mentioned at one >point. >It has now expired. I found a cached copy and read it. It does seem to >provide some brief explanation of how to do Symmetric RTP, but it does >not >look detailed enough. Section 8.5 is titled "Example: "Bidirectional" >RTP >and RTCP" and it says only "... immediately sends RTP from ..." and "... >immediately sends RTCP from ..." with no explanation of the expected >packet >contents. > >I would like to see Symmetric RTP defined more precisely, both for our >own >use and for comedia. What do others think? Would someone like to >clarify >usage, provide examples, start a draft, etc? > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 21 08:15:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12686 for ; Fri, 21 Mar 2003 08:15:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LDXec04555 for mmusic-archive@odin.ietf.org; Fri, 21 Mar 2003 08:33:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LDXeO04552 for ; Fri, 21 Mar 2003 08:33:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12683 for ; Fri, 21 Mar 2003 08:14:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LDXZO04544; Fri, 21 Mar 2003 08:33:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LDUtO04451 for ; Fri, 21 Mar 2003 08:30:55 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12644 for ; Fri, 21 Mar 2003 08:12:03 -0500 (EST) From: olivier.randriamanana.extern46@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id 6C4CA8F55F for ; Fri, 21 Mar 2003 14:14:19 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA12637 for ; Fri, 21 Mar 2003 14:14:18 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA08892 for ; Fri, 21 Mar 2003 14:14:17 +0100 (MET) To: Date: Fri, 21 Mar 2003 14:14:38 +0100 Message-ID: X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 21/03/2003 14:15:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Content-Location in a 200 resp. leading to other server Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, I have a question about the legality/normality of the following use case: A user agent sends a DESCRIBE for the following resource rtsp://192.168.200.12/resource.mp4: DESCRIBE rtsp://192.168.200.12/resource.mp4 CSeq: 1 User-agent: MyUa Accept: application/sdp The server replies: RTSP/1.0 200 OK CSeq: 1 Server: MyServer Content-Location: rtsp://192.168.202.12/go_there_please.mp4 Content-Type: application/sdp Content-Length: XXXX v=0... a=control:* m=audio... a=control:stuff/lady_in_red m=video... a=control:stuff/shae_marks In this example, the server replies successfully but "redirects" the user agent to another host for the subsequent requests. The RTSP spec (RFC 2326) is very broad concerning Content-Location. However, I've ran into UAs that seem to expect Content-Location to mandatorily point to the SAME host address (regardless of the URI path that can vary). Hence my question: as far as the network authority is concerned, can Content-Location point to a different host than the replying host?? Thanks, Olivier _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 21 08:18: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 IAA12736 for ; Fri, 21 Mar 2003 08:18:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LDaOQ04696 for mmusic-archive@odin.ietf.org; Fri, 21 Mar 2003 08:36:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LDaNO04693 for ; Fri, 21 Mar 2003 08:36:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12724 for ; Fri, 21 Mar 2003 08:17:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LDaDO04647; Fri, 21 Mar 2003 08:36:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LDVPO04493 for ; Fri, 21 Mar 2003 08:31:25 -0500 Received: from sonim-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12648 for ; Fri, 21 Mar 2003 08:12:30 -0500 (EST) Received: (from root@localhost) by sonim-india.com (8.11.6/8.11.6) id h2LCe6u21767 for ; Fri, 21 Mar 2003 18:10:06 +0530 Received: from boxer (boxer.sonim-india.com [192.168.2.88]) by sonim-india.com (8.11.6/8.11.6) with SMTP id h2LCe5l21683 for ; Fri, 21 Mar 2003 18:10:05 +0530 From: "Vishal Verma" To: Date: Fri, 21 Mar 2003 18:49:04 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-AntiVirus: Scanned for Viruses at sonim communications (india) pvt. ltd. Content-Transfer-Encoding: 7bit Subject: [MMUSIC] query regarding 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 Hello, I am looking into SDP protocol presently and I have some questions regarding SDP. My questions are : 1. SDP is used by SIP to inform about endpoint media capability in INVITE message .My question is ...if endpoint A initiated call to endpoint B and on receiving A's SDP ,B finds out A's SDP does not matches with A so B can not go ahead with call .In this situation what is the response code to indicate this failure ? If there is no response code for this so what exactly is method to communicate error to A. 2. Why SDP does not madates use of certain codecs(G.711) as done by ITU-T protocols(H.323)(I mean to ask what is the idea behind not suggesting mandatory codecs) .There will always be high probability of codec mismatch regards, vishal _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 21 09:59: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 JAA14724 for ; Fri, 21 Mar 2003 09:59:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LFHOx11374 for mmusic-archive@odin.ietf.org; Fri, 21 Mar 2003 10:17:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFHOO11371 for ; Fri, 21 Mar 2003 10:17:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14714 for ; Fri, 21 Mar 2003 09:58:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFHKO11359; Fri, 21 Mar 2003 10:17:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFESO11232 for ; Fri, 21 Mar 2003 10:14:28 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14631 for ; Fri, 21 Mar 2003 09:55:35 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2LEvrBd002825; Fri, 21 Mar 2003 09:57:54 -0500 (EST) Message-ID: <3E7B2874.6000200@dynamicsoft.com> Date: Fri, 21 Mar 2003 09:57:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishal Verma CC: mmusic@ietf.org Subject: Re: [MMUSIC] query regarding SDP 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 inline. Vishal Verma wrote: > Hello, > I am looking into SDP protocol presently and I have some > questions regarding SDP. My questions are : > > 1. SDP is used by SIP to inform about endpoint media capability > in INVITE message .My question is ...if endpoint A initiated > call to endpoint B and on receiving A's SDP ,B finds out A's SDP does > not matches with A so B can not go ahead with call .In this > situation what is the response code to indicate this failure ? 488 > If there is no response code for this so what exactly is > method to communicate error to A. > > 2. Why SDP does not madates use of certain codecs(G.711) as done > by ITU-T protocols(H.323)(I mean to ask what is the idea behind > not suggesting mandatory codecs) .There will always be high > probability of codec mismatch Selecting a baseline codec is an IPR nightmare. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 21 15:38: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 PAA26879 for ; Fri, 21 Mar 2003 15:38:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LKutJ04547 for mmusic-archive@odin.ietf.org; Fri, 21 Mar 2003 15:56:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKutO04544 for ; Fri, 21 Mar 2003 15:56:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26854 for ; Fri, 21 Mar 2003 15:37:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKuoO04518; Fri, 21 Mar 2003 15:56:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKniO04245 for ; Fri, 21 Mar 2003 15:49:44 -0500 Received: from goobox (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26615 for ; Fri, 21 Mar 2003 15:30:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 21 Mar 2003 12:31:07 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Fri, 21 Mar 2003 12:31:07 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206]) by real.com (8.12.2-glompatched/8.12.2) with ESMTP id h2LKUWlV025904 for ; Fri, 21 Mar 2003 12:30:32 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18wT9z-0007jt-00 for ; Fri, 21 Mar 2003 12:30:39 -0800 Date: Fri, 21 Mar 2003 12:29:57 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-0.2 required=5.0 tests=KNOWN_MAILING_LIST,NO_REAL_NAME version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) X-UIDL: 01860f7c8ecb6f0314c377611f305b93 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #75 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-707252 ] Update the RTSP URI schemes (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 20 Mar 2003 16:45:13 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-707252 ] Update the RTSP URI schemes Bugs item #707252, was opened at 2003-03-21 01:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=707252&group_id=23194 Category: General Group: None Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Update the RTSP URI schemes Initial Comment: The current RTSP schemes has been updated to allow for literall IPv6. However the URI scheme should also be updated to cover IRI (Internationalized Resource Identifiers). I (Magnus W) will try to get more information on this from the people having created the IRI. Hopefully this is little or no work. For people to read up on URI scheme considerations and other things should look at: RFC 2717 and 2718. I hade so far not had time to dig up any references to the IRI work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=707252&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 24 21:15: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 VAA13950 for ; Mon, 24 Mar 2003 21:15:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P2ZSs22087 for mmusic-archive@odin.ietf.org; Mon, 24 Mar 2003 21:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2ZSO22084 for ; Mon, 24 Mar 2003 21:35:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13936 for ; Mon, 24 Mar 2003 21:14:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2ZNO22076; Mon, 24 Mar 2003 21:35:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2RrO21644 for ; Mon, 24 Mar 2003 21:27:53 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13833 for ; Mon, 24 Mar 2003 21:07:18 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2P29DH20536 for mmusic@ietf.org; Mon, 24 Mar 2003 18:09:13 -0800 Date: Mon, 24 Mar 2003 18:09:13 -0800 From: John Lazzaro Message-Id: <200303250209.h2P29DH20536@snap.CS.Berkeley.EDU> To: mmusic@ietf.org Subject: [MMUSIC] question on draft-ietf-mmusic-sdp-new-12 ... Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Quick 'wording' question on draft-ietf-mmusic-sdp-new-12, now that maxptime exists as an SDP attribute, is there an implied "typical" in the ptime attribute definition, i.e. This gives the typical length in milliseconds ... If maxptime and ptime are intended to be used together in a session description, this "typical" would seem to be implied. However, if maxptime and ptime are intended to be mutually exclusive (one or the other but not both are permitted in a session description), the "typical" is probably not implied. Thanks in advance ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 26 06:59: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 GAA22317 for ; Wed, 26 Mar 2003 06:59:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QCKgZ22684 for mmusic-archive@odin.ietf.org; Wed, 26 Mar 2003 07:20:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCKgO22681 for ; Wed, 26 Mar 2003 07:20:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22308 for ; Wed, 26 Mar 2003 06:59:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCKQO22669; Wed, 26 Mar 2003 07:20:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCJoO22615 for ; Wed, 26 Mar 2003 07:19:50 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22300 for ; Wed, 26 Mar 2003 06:58:32 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QC0qHQ022576; Wed, 26 Mar 2003 13:00:52 +0100 (MET) Received: from era.ericsson.se (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 HMMS4G04; Wed, 26 Mar 2003 13:00:53 +0100 Message-ID: <3E819674.8020207@era.ericsson.se> Date: Wed, 26 Mar 2003 13:00:52 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: olivier.randriamanana.extern46@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Content-Location in a 200 resp. leading to other server 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 Olivier, To me this example seems legal. In fact from the language of RFC 2326 the intention is to support use cases when even the different media streams are located on different servers. Also looking at the definition of Content Location I don't see anything that indicates the restriction you describe. So in my opinion a UA should definitely handle the case with different host address in Content-Location. Best Regards Magnus olivier.randriamanana.extern46@philips.com wrote: >Hi, > >I have a question about the legality/normality of the following use case: > >A user agent sends a DESCRIBE for the following resource >rtsp://192.168.200.12/resource.mp4: >DESCRIBE rtsp://192.168.200.12/resource.mp4 >CSeq: 1 >User-agent: MyUa >Accept: application/sdp > >The server replies: >RTSP/1.0 200 OK >CSeq: 1 >Server: MyServer >Content-Location: rtsp://192.168.202.12/go_there_please.mp4 >Content-Type: application/sdp >Content-Length: XXXX > >v=0... >a=control:* >m=audio... >a=control:stuff/lady_in_red >m=video... >a=control:stuff/shae_marks > >In this example, the server replies successfully but "redirects" the user >agent to another host for the subsequent requests. The RTSP spec (RFC 2326) >is very broad concerning Content-Location. However, I've ran into UAs that >seem to expect Content-Location to mandatorily point to the SAME host >address (regardless of the URI path that can vary). >Hence my question: as far as the network authority is concerned, can >Content-Location point to a different host than the replying host?? > >Thanks, > >Olivier > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 26 07:14: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 HAA22504 for ; Wed, 26 Mar 2003 07:14:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QCZ8123229 for mmusic-archive@odin.ietf.org; Wed, 26 Mar 2003 07:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCZ8O23226 for ; Wed, 26 Mar 2003 07:35:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22501 for ; Wed, 26 Mar 2003 07:13:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCZ4O23217; Wed, 26 Mar 2003 07:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCYJO23181 for ; Wed, 26 Mar 2003 07:34:19 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22473 for ; Wed, 26 Mar 2003 07:13:01 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QCFIbh017994; Wed, 26 Mar 2003 13:15:19 +0100 (MET) Received: from era.ericsson.se (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 HMMS4L27; Wed, 26 Mar 2003 13:15:19 +0100 Message-ID: <3E8199D6.6060204@era.ericsson.se> Date: Wed, 26 Mar 2003 13:15:18 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Lazzaro CC: mmusic@ietf.org Subject: Re: [MMUSIC] question on draft-ietf-mmusic-sdp-new-12 ... References: <200303250209.h2P29DH20536@snap.CS.Berkeley.EDU> 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 John, The usage of ptime and maxptime is not mutually exclusive neither are they required or even recommended to be used together. The usage is dependent on application and can be seen as two attributes for controlling how the packetization/encoding work. For ptime the "typical" you imply does exist in my opinion. It seems reinforced by the following sentence from the ptime definition: "It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio." when looking at the version 12 draft I think the definition of maxptime needs to be addressed. The following sentence: "The time SHOULD be a multiple of the frame size." This text comes directly from AMR definition that has a frame structure but in the SDP specification this should be reformulated to cover the more general and take sample based codecs into consideration. My proposal for text is: "The time SHOULD be a multiple of any frame size." Best Regards Magnus John Lazzaro wrote: >Hi everyone, > > Quick 'wording' question on draft-ietf-mmusic-sdp-new-12, >now that maxptime exists as an SDP attribute, is there an >implied "typical" in the ptime attribute definition, i.e. > > This gives the typical length in milliseconds ... > > If maxptime and ptime are intended to be used together >in a session description, this "typical" would seem to be >implied. However, if maxptime and ptime are intended to be >mutually exclusive (one or the other but not both are permitted >in a session description), the "typical" is probably not >implied. > > Thanks in advance ... > >------------------------------------------------------------------------- >John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley >lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro >------------------------------------------------------------------------- >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 26 10:59:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01786 for ; Wed, 26 Mar 2003 10:59:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGKYf08859 for mmusic-archive@odin.ietf.org; Wed, 26 Mar 2003 11:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGKYO08856 for ; Wed, 26 Mar 2003 11:20:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01762 for ; Wed, 26 Mar 2003 10:59:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGKCO08783; Wed, 26 Mar 2003 11:20:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGGiO08599 for ; Wed, 26 Mar 2003 11:16:44 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01651 for ; Wed, 26 Mar 2003 10:55:21 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QFvfHQ005419 for ; Wed, 26 Mar 2003 16:57:41 +0100 (MET) Received: from era.ericsson.se (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 HMMSWT9R; Wed, 26 Mar 2003 16:57:41 +0100 Message-ID: <3E81CDF5.5020500@era.ericsson.se> Date: Wed, 26 Mar 2003 16:57:41 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] What is symmetric RTP? References: <20030319185429.GA30759@real.com> <3E79479E.1090807@era.ericsson.se> 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 like to clarify some things in my previous mail. Magnus Westerlund wrote: > Hi Tom, > > I agree that the term symmetric RTP is really not defined in any > document. I have one view of this that is a result of following > discussions around NATs in AVT, SIPPING, and MMUSIC. In my view people > often mean two things when they are talking about symmetric RTP. > > 1. The sending and receiving of RTP from the same port. This was the > case in the ancient days, :-), of multicast usage and RAT . However > then the SIP and some other people come around and distorted this view > with not using the same port for receiving and sending. Bad choice of language here. I don't want to blame the SIP people for the change. RTP has the flexibility to be used with different ports at different end points and sending from another port then receiving. It i s after all a matter of being able to signal. > > 2. The usage of a received message to determine the destination > address. This is I think the main idea when performing NAT traversal. > Of course 1 must be used to make it work, however this is simple. It > is the second usage that has some problems. > > One possible place to better define symmetric RTP could be the RTSP > NAT draft. After some thought and discussion, I don't think the RTSP NAT draft is the right place anymore. If we would do a specification of what symmetric RTP is, it should be a stand alone document that can be referenced both by SIP and RTSP and any other signaling that has use of the functionality. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Mar 26 11:18: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 LAA02420 for ; Wed, 26 Mar 2003 11:18:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGdE110510 for mmusic-archive@odin.ietf.org; Wed, 26 Mar 2003 11:39:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGdEO10503 for ; Wed, 26 Mar 2003 11:39:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02408 for ; Wed, 26 Mar 2003 11:17:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGd8O10484; Wed, 26 Mar 2003 11:39:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGcdO10434 for ; Wed, 26 Mar 2003 11:38:39 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02397 for ; Wed, 26 Mar 2003 11:17:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2QGJdBd005541; Wed, 26 Mar 2003 11:19:39 -0500 (EST) Message-ID: <3E81D316.3080708@dynamicsoft.com> Date: Wed, 26 Mar 2003 11:19:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: mmusic@ietf.org Subject: Re: [MMUSIC] What is symmetric RTP? References: <20030319185429.GA30759@real.com> <3E79479E.1090807@era.ericsson.se> <3E81CDF5.5020500@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Magnus Westerlund wrote: > Hi, > > I would like to clarify some things in my previous mail. > > Magnus Westerlund wrote: > >> Hi Tom, >> >> I agree that the term symmetric RTP is really not defined in any >> document. I have one view of this that is a result of following >> discussions around NATs in AVT, SIPPING, and MMUSIC. In my view people >> often mean two things when they are talking about symmetric RTP. >> >> 1. The sending and receiving of RTP from the same port. This was the >> case in the ancient days, :-), of multicast usage and RAT . However >> then the SIP and some other people come around and distorted this view >> with not using the same port for receiving and sending. > > > Bad choice of language here. I don't want to blame the SIP people for > the change. RTP has the flexibility to be used with different ports at > different end points and sending from another port then receiving. It i > s after all a matter of being able to signal. Well, really the issue is that usage of RTP with unicast has been a source of constant confusion even to this day. > >> >> 2. The usage of a received message to determine the destination >> address. This is I think the main idea when performing NAT traversal. >> Of course 1 must be used to make it work, however this is simple. It >> is the second usage that has some problems. > > >> >> One possible place to better define symmetric RTP could be the RTSP >> NAT draft. > > > > After some thought and discussion, I don't think the RTSP NAT draft is > the right place anymore. If we would do a specification of what > symmetric RTP is, it should be a stand alone document that can be > referenced both by SIP and RTSP and any other signaling that has use of > the functionality. THe reason that this went into comedia is that, once you do this, UDP effectively looks "connection oriented". THe same issues exist as they do for TCP - who is active, who is passive? How is it negotiated? Thats what comedia does. That said, I still believe that it is desirable to align RTSP NAT solutions with SIP. Symmetric RTP is nice, but it is not as general as the ICE-based approach I have proposed. There are many topologies where symmetric RTP will not work. Any topology where the server itself is behind a NAT. A good example is two enterprises. Lets say there is a manufacturer that makes widgets. They have customers in lots of enterprises. They want to run an RTSP server inside their enterprise, so users can connect and see videos providing customer support. If the customer enterprises are natted, and so is the widget manufacturer, symmetric RTP will not help. ICE would figure out the best approach. The only case in which ICE requires more than one exchange to work in this case is when both NATs are full-cone. In such a case, you can eliminate the second ICE exchange if you use a TURN relay. -Jonathan R. -- 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 mailnull@www1.ietf.org Wed Mar 26 12:10: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 MAA04285 for ; Wed, 26 Mar 2003 12:10:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QHVS914854 for mmusic-archive@odin.ietf.org; Wed, 26 Mar 2003 12:31:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHVSO14851 for ; Wed, 26 Mar 2003 12:31:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04270 for ; Wed, 26 Mar 2003 12:10:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHVLO14839; Wed, 26 Mar 2003 12:31:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHUNO14731 for ; Wed, 26 Mar 2003 12:30:23 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04232 for ; Wed, 26 Mar 2003 12:08:59 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2QHAoE24496 for mmusic@ietf.org; Wed, 26 Mar 2003 09:10:50 -0800 Date: Wed, 26 Mar 2003 09:10:50 -0800 From: John Lazzaro Message-Id: <200303261710.h2QHAoE24496@snap.CS.Berkeley.EDU> To: mmusic@ietf.org Subject: [MMUSIC] Re: mmusic digest, Vol 1 #376 - 4 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Magnus Westerlund writes > > The usage is > dependent on application and can be seen as two attributes for > controlling how the packetization/encoding work. For ptime the "typical" > you imply does exist in my opinion. Thanks -- I'm rewriting the media timing section of the MWPP normative I-D, and wanted to make sure I was interpeting the semantics correctly. > when looking at the version 12 draft [...] Yes, a tangentially related issue is that the value of ptime and maxptime is neither constrained to be an integral value of milliseconds, nor expressly permitted to have a fractional component. I would normally take that to mean that a fractional part is permitted (" ... be liberal in what you accept"), except that the definition of the framerate attribute explicitly allows . in its text, as if it was an exceptional condition to an unstated norm ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 27 02:32: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 CAA18603 for ; Thu, 27 Mar 2003 02:32:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R7rEC25288 for mmusic-archive@odin.ietf.org; Thu, 27 Mar 2003 02:53:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7rDO25285 for ; Thu, 27 Mar 2003 02:53:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18595 for ; Thu, 27 Mar 2003 02:31:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7r2O25275; Thu, 27 Mar 2003 02:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7oRO25088 for ; Thu, 27 Mar 2003 02:50:27 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18539 for ; Thu, 27 Mar 2003 02:28:45 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2R7V4Y9006066; Thu, 27 Mar 2003 08:31:04 +0100 (MET) Received: from era.ericsson.se (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 HKFYCN45; Thu, 27 Mar 2003 08:31:03 +0100 Message-ID: <3E82A8B7.8050308@era.ericsson.se> Date: Thu, 27 Mar 2003 08:31:03 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: mmusic@ietf.org Subject: Re: [MMUSIC] What is symmetric RTP? References: <20030319185429.GA30759@real.com> <3E79479E.1090807@era.ericsson.se> <3E81CDF5.5020500@era.ericsson.se> <3E81D316.3080708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, See below: Jonathan Rosenberg wrote: >> After some thought and discussion, I don't think the RTSP NAT draft >> is the right place anymore. If we would do a specification of what >> symmetric RTP is, it should be a stand alone document that can be >> referenced both by SIP and RTSP and any other signaling that has use >> of the functionality. > > > THe reason that this went into comedia is that, once you do this, UDP > effectively looks "connection oriented". THe same issues exist as they > do for TCP - who is active, who is passive? How is it negotiated? > Thats what comedia does. > > That said, I still believe that it is desirable to align RTSP NAT > solutions with SIP. Symmetric RTP is nice, but it is not as general as > the ICE-based approach I have proposed. There are many topologies > where symmetric RTP will not work. Any topology where the server > itself is behind a NAT. A good example is two enterprises. Lets say > there is a manufacturer that makes widgets. They have customers in > lots of enterprises. They want to run an RTSP server inside their > enterprise, so users can connect and see videos providing customer > support. If the customer enterprises are natted, and so is the widget > manufacturer, symmetric RTP will not help. ICE would figure out the > best approach. The only case in which ICE requires more than one > exchange to work in this case is when both NATs are full-cone. In such > a case, you can eliminate the second ICE exchange if you use a TURN > relay. > > -Jonathan R. > I can understand your desire to align RTSP and SIP. However when it comes to usage of ICE it definitely gets problematic. First RTSP does not have the SETUP exchange in place to accommodate something like ICE need for one or more exchange with parameters both for the STUN server and the given addresses. I don't say it is impossible however more work will be needed to look at how it could be included. Then one will see how many modifications it would requires. In the end it might be simpler to take on the SIP session initiation and only keep RTSP's media control. However this is a radical proposal that would significantly change the protocol. One question I would like to know is how big the envisioned problem will be with servers that reside in NATed networks. I can understand that SIP must consider all cases as it set up communication between users which are more likely to have NATed addresses. However looking at RTSP which has a clear client to server structure, much like HTTP. If you move a server to a NATed address you will also have problem setting up the TCP connection. You simple will require a proxy between the address domains to be able to communicate. Are there many that deploy HTTP servers in private address spaces and actually intend them to be used by other address domains? So far my view has been that as this is server, the server owner can ensure that the server has an IP address that makes it reachable by the intended clients. So in your widget manufacturer example above, why does not he deploy the server in the public IP space. I would assume that he has HTTP server that are also reachable. If you don't share my opinion on this please speak up and give some motivation why this is a useful example. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 27 02:53:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19078 for ; Thu, 27 Mar 2003 02:53:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R8F3C26864 for mmusic-archive@odin.ietf.org; Thu, 27 Mar 2003 03:15:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R8F2O26861 for ; Thu, 27 Mar 2003 03:15:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19063 for ; Thu, 27 Mar 2003 02:53:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R8EvO26844; Thu, 27 Mar 2003 03:14:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R8CKO26766 for ; Thu, 27 Mar 2003 03:12:20 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19028 for ; Thu, 27 Mar 2003 02:50:37 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2R7quY9011828; Thu, 27 Mar 2003 08:52:56 +0100 (MET) Received: from era.ericsson.se (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 HK1VNLA5; Thu, 27 Mar 2003 08:52:57 +0100 Message-ID: <3E82ADD8.8010005@era.ericsson.se> Date: Thu, 27 Mar 2003 08:52:56 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Lazzaro CC: mmusic@ietf.org Subject: Re: [MMUSIC] Usage of maxptime and ptime References: <200303261710.h2QHAoE24496@snap.CS.Berkeley.EDU> 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 John, John Lazzaro wrote: >>when looking at the version 12 draft [...] >> >> > >Yes, a tangentially related issue is that the value of ptime >and maxptime is neither constrained to be an integral value of >milliseconds, nor expressly permitted to have a fractional >component. I would normally take that to mean that a fractional >part is permitted (" ... be liberal in what you accept"), except >that the definition of the framerate attribute explicitly allows >. in its text, as if it was an exceptional >condition to an unstated norm ... > > No, I have never seen ptime or maxptime being used with a fractional part. I would strongly discourage the use with fractional part as it will probably not interoperate. However the attributes seem to be lacking any formal notation or language to clarify that it is only integer. My intention for maxptime was never to have it fractional as I saw no need for AMR. I know that there exist some codecs that could result in fractional milli second values. Also I don't see a big problem. As maxptime provides a upper boundary when having a codec with frame length of 7.7 milli seconds it seems obvious that if you want to limit this to three frames one simple uses 24 ms in maxptime. If one at the same time want to recommend the usage of one frames ptime is given the value of 8. Colin: why does not the attributes defined in the SDP new draft have ABNF definitions? Had ptime and maxptime had it the question would been clearly solved. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 27 11:36: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 LAA06567 for ; Thu, 27 Mar 2003 11:36:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RGwHd31184 for mmusic-archive@odin.ietf.org; Thu, 27 Mar 2003 11:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGwHO31181 for ; Thu, 27 Mar 2003 11:58:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06468 for ; Thu, 27 Mar 2003 11:36:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGw5O31165; Thu, 27 Mar 2003 11:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGm5O30445 for ; Thu, 27 Mar 2003 11:48:05 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05905 for ; Thu, 27 Mar 2003 11:26:13 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2RGSVO16769; Thu, 27 Mar 2003 11:28:32 -0500 Message-Id: <200303271628.h2RGSVO16769@chiron.nge.isi.edu> To: Magnus Westerlund cc: John Lazzaro , mmusic@ietf.org Subject: Re: [MMUSIC] Usage of maxptime and ptime In-Reply-To: Your message of "Thu, 27 Mar 2003 08:52:56 +0100." <3E82ADD8.8010005@era.ericsson.se> Date: Thu, 27 Mar 2003 11:28:31 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> Magnus Westerlund writes: >Hi John, > >John Lazzaro wrote: > >>>when looking at the version 12 draft [...] >>> >>> >> >>Yes, a tangentially related issue is that the value of ptime >>and maxptime is neither constrained to be an integral value of >>milliseconds, nor expressly permitted to have a fractional >>component. I would normally take that to mean that a fractional >>part is permitted (" ... be liberal in what you accept"), except >>that the definition of the framerate attribute explicitly allows >>. in its text, as if it was an exceptional >>condition to an unstated norm ... >> >> > >No, I have never seen ptime or maxptime being used with a fractional >part. I would strongly discourage the use with fractional part as it >will probably not interoperate. However the attributes seem to be >lacking any formal notation or language to clarify that it is only >integer. My intention for maxptime was never to have it fractional as I >saw no need for AMR. I know that there exist some codecs that could >result in fractional milli second values. Also I don't see a big >problem. As maxptime provides a upper boundary when having a codec with >frame length of 7.7 milli seconds it seems obvious that if you want to >limit this to three frames one simple uses 24 ms in maxptime. If one at >the same time want to recommend the usage of one frames ptime is given >the value of 8. > >Colin: why does not the attributes defined in the SDP new draft have >ABNF definitions? Had ptime and maxptime had it the question would been >clearly solved. History. I have no objection to including ABNF, if you want to suggest the appropriate form. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 27 13:30:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11323 for ; Thu, 27 Mar 2003 13:30:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RIqLe09247 for mmusic-archive@odin.ietf.org; Thu, 27 Mar 2003 13:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RIqLO09244 for ; Thu, 27 Mar 2003 13:52:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11305 for ; Thu, 27 Mar 2003 13:30:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RIqFO09218; Thu, 27 Mar 2003 13:52:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RIptO09186 for ; Thu, 27 Mar 2003 13:51:55 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11271 for ; Thu, 27 Mar 2003 13:30:00 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2RIVm227019 for mmusic@ietf.org; Thu, 27 Mar 2003 10:31:48 -0800 Date: Thu, 27 Mar 2003 10:31:48 -0800 From: John Lazzaro Message-Id: <200303271831.h2RIVm227019@snap.CS.Berkeley.EDU> To: mmusic@ietf.org Subject: Re: [MMUSIC] Usage of maxptime and ptime Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Colin Perkins writes: > > History. I have no objection to including ABNF, if you want > to suggest the appropriate form. Here's one alternative, adapted from the MWPP ABNF ... ; ; sub-rules of 'a=' ; attribute-fields = *("a=" attribute CRLF) ; ABNF for attributes defined in this memo attribute = "cat" ":" cat-fields attribute /= "keywds" ":" keyword-fields attribute /= "tool" ":" tool-fields attribute /= "ptime" ":" four-octet-int attribute /= "maxptime" ":" four-octet-int ; ; todo: complete list of defined attributes ; ; last entry (below) guides authors of new attributes attribute /= (att-field ":" att-value) / att-field ; ; ABNF for specific attribute fields ; four-octet-int = %d0-429496729 ; unsigned 32-bits integer ; add cat-fields, keyword-fields ... below att-field = token att-value = byte-string ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Mar 27 13:56: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 NAA12750 for ; Thu, 27 Mar 2003 13:56:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RJIDG11419 for mmusic-archive@odin.ietf.org; Thu, 27 Mar 2003 14:18:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJIDO11416 for ; Thu, 27 Mar 2003 14:18:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12725 for ; Thu, 27 Mar 2003 13:56:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJI3O11318; Thu, 27 Mar 2003 14:18:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJC6O11056 for ; Thu, 27 Mar 2003 14:12:06 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12108 for ; Thu, 27 Mar 2003 13:50:11 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2RIpt427052; Thu, 27 Mar 2003 10:51:55 -0800 Date: Thu, 27 Mar 2003 10:51:55 -0800 From: John Lazzaro Message-Id: <200303271851.h2RIpt427052@snap.CS.Berkeley.EDU> To: lazzaro@CS.Berkeley.EDU, magnus.westerlund@era.ericsson.se Subject: Re: [MMUSIC] Usage of maxptime and ptime Cc: mmusic@ietf.org Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Magnus Westerlund writes: > > Also I don't see a big > problem. As maxptime provides a upper boundary when having a codec with > frame length of 7.7 milli seconds it seems obvious that if you want to > limit this to three frames one simple uses 24 ms in maxptime. MWPP is an audio payload that is neither frame nor sample based; the interactive norm may be ptime:0 -- i.e. all commands in a payload execute at the same moment in time, and thus the interval of time coded in a packet is 0 ms. But you can also use MWPP to do content-streaming type work, in which case you'd probably specify ptime values in keeping with what MPEG audio codecs use ... So, ptime and maxptime are the hints that will be used for senders and receivers to know which broad application class the session falls into ... as well as to provide hints for sender timing accuracy and receiver buffer sizing. This will all be informative text tucked into an Appendix in the MWPP normative memo ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 28 05:02: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 FAA22628 for ; Fri, 28 Mar 2003 05:02:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SAOPj23526 for mmusic-archive@odin.ietf.org; Fri, 28 Mar 2003 05:24:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SAOPO23523 for ; Fri, 28 Mar 2003 05:24:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22602 for ; Fri, 28 Mar 2003 05:02:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SAOFO23512; Fri, 28 Mar 2003 05:24:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SANmO23465 for ; Fri, 28 Mar 2003 05:23:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22578 for ; Fri, 28 Mar 2003 05:01:34 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2SA3obh004432; Fri, 28 Mar 2003 11:03:50 +0100 (MET) Received: from era.ericsson.se (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 HMMTHXXN; Fri, 28 Mar 2003 11:03:49 +0100 Message-ID: <3E841E05.9000106@era.ericsson.se> Date: Fri, 28 Mar 2003 11:03:49 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Lazzaro CC: mmusic@ietf.org Subject: Re: [MMUSIC] Usage of maxptime and ptime References: <200303271831.h2RIVm227019@snap.CS.Berkeley.EDU> 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 John Lazzaro wrote: >>Colin Perkins writes: >> >>History. I have no objection to including ABNF, if you want >>to suggest the appropriate form. >> >> > >Here's one alternative, adapted from the MWPP ABNF ... > > >attribute /= "ptime" ":" 1*DIGIT > >attribute /= "maxptime" ":" 1*DIGIT > > > I would change the value from a unsigned integer to the much more common DIGIT definition. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 28 09:46: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 JAA00007 for ; Fri, 28 Mar 2003 09:46:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SF8RG10270 for mmusic-archive@odin.ietf.org; Fri, 28 Mar 2003 10:08:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SF8RO10267 for ; Fri, 28 Mar 2003 10:08:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29974 for ; Fri, 28 Mar 2003 09:46:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SF8DO10257; Fri, 28 Mar 2003 10:08:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SF7FO09819 for ; Fri, 28 Mar 2003 10:07:15 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29963 for ; Fri, 28 Mar 2003 09:44:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2SElGBd006500; Fri, 28 Mar 2003 09:47:17 -0500 (EST) Message-ID: <3E846071.1090602@dynamicsoft.com> Date: Fri, 28 Mar 2003 09:47:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: mmusic@ietf.org Subject: Re: [MMUSIC] What is symmetric RTP? References: <20030319185429.GA30759@real.com> <3E79479E.1090807@era.ericsson.se> <3E81CDF5.5020500@era.ericsson.se> <3E81D316.3080708@dynamicsoft.com> <3E82A8B7.8050308@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Magnus Westerlund wrote: >> That said, I still believe that it is desirable to align RTSP NAT >> solutions with SIP. Symmetric RTP is nice, but it is not as general as >> the ICE-based approach I have proposed. There are many topologies >> where symmetric RTP will not work. Any topology where the server >> itself is behind a NAT. A good example is two enterprises. Lets say >> there is a manufacturer that makes widgets. They have customers in >> lots of enterprises. They want to run an RTSP server inside their >> enterprise, so users can connect and see videos providing customer >> support. If the customer enterprises are natted, and so is the widget >> manufacturer, symmetric RTP will not help. ICE would figure out the >> best approach. The only case in which ICE requires more than one >> exchange to work in this case is when both NATs are full-cone. In such >> a case, you can eliminate the second ICE exchange if you use a TURN >> relay. > I can understand your desire to align RTSP and SIP. However when it > comes to usage of ICE it definitely gets problematic. First RTSP does > not have the SETUP exchange in place to accommodate something like ICE > need for one or more exchange with parameters both for the STUN server > and the given addresses. I don't say it is impossible however more work > will be needed to look at how it could be included. Then one will see > how many modifications it would requires. In the end it might be simpler > to take on the SIP session initiation and only keep RTSP's media > control. However this is a radical proposal that would significantly > change the protocol. Well, I suspect it would not change the protocol so much as only use a subset - the parts for control. Regarding having RTSP itself support an offer/answer exchange with SETUP, generally only one exchange would be needed. So, its just an issue of putting more than one address in the SETUP. > > One question I would like to know is how big the envisioned problem will > be with servers that reside in NATed networks. I can understand that SIP > must consider all cases as it set up communication between users which > are more likely to have NATed addresses. However looking at RTSP which > has a clear client to server structure, much like HTTP. If you move a > server to a NATed address you will also have problem setting up the TCP > connection. You simple will require a proxy between the address domains > to be able to communicate. Are there many that deploy HTTP servers in > private address spaces and actually intend them to be used by other > address domains? So far my view has been that as this is server, the > server owner can ensure that the server has an IP address that makes it > reachable by the intended clients. So in your widget manufacturer > example above, why does not he deploy the server in the public IP space. > I would assume that he has HTTP server that are also reachable. If you > don't share my opinion on this please speak up and give some motivation > why this is a useful example. I think that you are making a fair point; if the widget manufacturer meant for this server to be reachable, they need to give it a public address. I think the cases where this might not be true is where "server" becomes more loosely defined. You have in mind a big server meant for consumer streaming media applications. However, I can imagine using RTSP to do things like retrieve voicemails, and even control streams shared directly between two users (for example, one user calling another with sip and letting the called party hear an mp3 that the caller has on their PC). All of these are, IMHO, good uses for RTSP, and none of them will work with the symmetric-RTP only approach you are advocating. So - are these places you want RTSP to work? -Jonathan R. -- 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 mailnull@www1.ietf.org Fri Mar 28 13:04: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 NAA10242 for ; Fri, 28 Mar 2003 13:04:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SIQKl26831 for mmusic-archive@odin.ietf.org; Fri, 28 Mar 2003 13:26:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIQKO26828 for ; Fri, 28 Mar 2003 13:26:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10217 for ; Fri, 28 Mar 2003 13:03:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIQGO26819; Fri, 28 Mar 2003 13:26:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIPAO26678 for ; Fri, 28 Mar 2003 13:25:10 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10180 for ; Fri, 28 Mar 2003 13:02:48 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2SI4SG29312; Fri, 28 Mar 2003 10:04:28 -0800 Date: Fri, 28 Mar 2003 10:04:28 -0800 From: John Lazzaro Message-Id: <200303281804.h2SI4SG29312@snap.CS.Berkeley.EDU> To: lazzaro@CS.Berkeley.EDU, magnus.westerlund@era.ericsson.se Subject: Re: [MMUSIC] Usage of maxptime and ptime Cc: mmusic@ietf.org Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Magnus Westerlund writes > > I would change the value from a unsigned integer to the much more > common DIGIT definition. Yes, that definition was stolen from MWPP parameters that needed 32-bit explicit constraints ... not needed here though. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Mar 28 16:08: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 QAA18872 for ; Fri, 28 Mar 2003 16:08:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SLUMP08116 for mmusic-archive@odin.ietf.org; Fri, 28 Mar 2003 16:30:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SLUMO08113 for ; Fri, 28 Mar 2003 16:30:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18842 for ; Fri, 28 Mar 2003 16:07:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SLUHO08072; Fri, 28 Mar 2003 16:30:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SLTjO08013 for ; Fri, 28 Mar 2003 16:29:45 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18794 for ; Fri, 28 Mar 2003 16:07:13 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.8/8.12.8) with ESMTP id h2SL9Yof066214; Fri, 28 Mar 2003 13:09:34 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Mar 2003 13:09:34 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7948@MISTY> From: Thomas Zeng To: Magnus Westerlund Cc: mmusic@ietf.org Subject: A reason to put RTSP server behind NAT (was RE: [MMUSIC] What is symmetric RTP?) Date: Fri, 28 Mar 2003 13:09:31 -0800 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: , Magnus: I would like to chime in to add an use case for putting RTSP server behind a firewall. Imagine a startup company wanting to install a live camera in a daycare to offer "nannycam" services. The live camer feeds audio and video to a RTSP server (running on the same CPU) for paid clients to view their kids by connectting a RTSP video player. It's well-known that some big companies offer streaming video in their company daycares to their employees. Now someone just wants the same service in other kids' daycare (so as to bridge the digital gap, among other things :-) The daycare has a combo cable modem / NAT box to run a private network of a few computers, one of which hosts the live camer as well as the RTSP server. This is a case where RTSP server is behind a server NAT, while clients may or may not be behind another NAT. Clients out side of the server NAT can connect because the NAT box can forward RTSP port to the RTSP server computer (via, say, Linux ipchains commands). Of course one can ask the daycare to put the RTSP server box in the open, but that means additional cost (it costs $5 dollars/month to get even a dynamic IP address from Time-Warner cable company here in San Diego), some one time fee to change network topology -- not to mention security degradation. Do you think this application is a legitimate use of RTSP protocol? - thomas -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, March 28, 2003 6:47 AM To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] What is symmetric RTP? Magnus Westerlund wrote: >> That said, I still believe that it is desirable to align RTSP NAT >> solutions with SIP. Symmetric RTP is nice, but it is not as general as >> the ICE-based approach I have proposed. There are many topologies >> where symmetric RTP will not work. Any topology where the server >> itself is behind a NAT. A good example is two enterprises. Lets say >> there is a manufacturer that makes widgets. They have customers in >> lots of enterprises. They want to run an RTSP server inside their >> enterprise, so users can connect and see videos providing customer >> support. If the customer enterprises are natted, and so is the widget >> manufacturer, symmetric RTP will not help. ICE would figure out the >> best approach. The only case in which ICE requires more than one >> exchange to work in this case is when both NATs are full-cone. In such >> a case, you can eliminate the second ICE exchange if you use a TURN >> relay. > I can understand your desire to align RTSP and SIP. However when it > comes to usage of ICE it definitely gets problematic. First RTSP does > not have the SETUP exchange in place to accommodate something like ICE > need for one or more exchange with parameters both for the STUN server > and the given addresses. I don't say it is impossible however more work > will be needed to look at how it could be included. Then one will see > how many modifications it would requires. In the end it might be simpler > to take on the SIP session initiation and only keep RTSP's media > control. However this is a radical proposal that would significantly > change the protocol. Well, I suspect it would not change the protocol so much as only use a subset - the parts for control. Regarding having RTSP itself support an offer/answer exchange with SETUP, generally only one exchange would be needed. So, its just an issue of putting more than one address in the SETUP. > > One question I would like to know is how big the envisioned problem will > be with servers that reside in NATed networks. I can understand that SIP > must consider all cases as it set up communication between users which > are more likely to have NATed addresses. However looking at RTSP which > has a clear client to server structure, much like HTTP. If you move a > server to a NATed address you will also have problem setting up the TCP > connection. You simple will require a proxy between the address domains > to be able to communicate. Are there many that deploy HTTP servers in > private address spaces and actually intend them to be used by other > address domains? So far my view has been that as this is server, the > server owner can ensure that the server has an IP address that makes it > reachable by the intended clients. So in your widget manufacturer > example above, why does not he deploy the server in the public IP space. > I would assume that he has HTTP server that are also reachable. If you > don't share my opinion on this please speak up and give some motivation > why this is a useful example. I think that you are making a fair point; if the widget manufacturer meant for this server to be reachable, they need to give it a public address. I think the cases where this might not be true is where "server" becomes more loosely defined. You have in mind a big server meant for consumer streaming media applications. However, I can imagine using RTSP to do things like retrieve voicemails, and even control streams shared directly between two users (for example, one user calling another with sip and letting the called party hear an mp3 that the caller has on their PC). All of these are, IMHO, good uses for RTSP, and none of them will work with the symmetric-RTP only approach you are advocating. [tzeng's comments start] [tzeng's comemnts end] So - are these places you want RTSP to work? -Jonathan R. -- 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 31 03:13:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29039 for ; Mon, 31 Mar 2003 03:13:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V8aJj15901 for mmusic-archive@odin.ietf.org; Mon, 31 Mar 2003 03:36:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V8aJO15898 for ; Mon, 31 Mar 2003 03:36:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29008 for ; Mon, 31 Mar 2003 03:12:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V8aCO15882; Mon, 31 Mar 2003 03:36:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V8ZPO15861 for ; Mon, 31 Mar 2003 03:35:25 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28990 for ; Mon, 31 Mar 2003 03:11:45 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2V8EArs017448; Mon, 31 Mar 2003 10:14:10 +0200 (MEST) Received: from era.ericsson.se (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 HKFZCNL6; Mon, 31 Mar 2003 10:14:10 +0200 Message-ID: <3E87F8D3.8020508@era.ericsson.se> Date: Mon, 31 Mar 2003 10:14:11 +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: Thomas Zeng CC: mmusic@ietf.org Subject: Re: A reason to put RTSP server behind NAT (was RE: [MMUSIC] What is symmetric RTP?) References: <72263E8E8622D611975C0002B32C19D84A7948@MISTY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thomas, I think the application in itself is a valid one. However if one provides services that is assumed to be used from the the public net I still think it is a reasonable thing to assume that the service provider (nanny cam host) in this case uses a public IP address. I think that Jonathan is right in his observation of the big question. Will private persons run RTSP servers to provide functionality in for example conversational calls. If the answer is yes, then we need to address the RTSP servers behind NAT problem. However looking at the current market it seems that the important question is how to solve the RTSP server in public network first. If someone is ready to start digging into solving this problem, please go ahead and provide input. The design of the solution for public IP RTSP servers may need to consider something out of a proposal for how to solve the private IP RTSP server problem. However it is obvious that such a solution must also address how to establish the control connection to the server. Last I have one comment to what you write: Thomas Zeng wrote: >Of course one can ask the daycare to put the RTSP server box in the open, >but that means additional cost (it costs $5 dollars/month to get even a >dynamic IP address from Time-Warner cable company here in San Diego), some >one time fee to change network topology -- not to mention security >degradation. > > I kind of react to the last thing. Security degradation: NATs does not provide any security protection, it only provides some obscurity. A NATed machine may of course not be reachable and can therefore not be be directly attacked. However this a firewall can also provide. The major problem is the huge security gap that the deployment of a NAT creates. With NATs there is basically no guaranteed protection against hijacking or eavesdropping attacks as it is impossible to source authenticate. So saying that removing the NAT will reduce the security I think is wrong. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 31 06:10:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02118 for ; Mon, 31 Mar 2003 06:10:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VBXTd27061 for mmusic-archive@odin.ietf.org; Mon, 31 Mar 2003 06:33:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VBXTO27058 for ; Mon, 31 Mar 2003 06:33:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02096 for ; Mon, 31 Mar 2003 06:09:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VBXFO27029; Mon, 31 Mar 2003 06:33:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VBW6O26999 for ; Mon, 31 Mar 2003 06:32:06 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967 for ; Mon, 31 Mar 2003 06:08:23 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VBAlrs009830 for ; Mon, 31 Mar 2003 13:10:47 +0200 (MEST) Received: from era.ericsson.se (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 2AGW4J7N; Mon, 31 Mar 2003 13:10:48 +0200 Message-ID: <3E882239.4080000@era.ericsson.se> Date: Mon, 31 Mar 2003 13:10:49 +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 teleconference, have or not? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, It was planned to have a RTSP telecon on Wednesday (2 April). I am somewhat short of time but I are willing to have this meeting at 18.00 CET, which after having changed to daylight savings are GMT+2. As I understand it US are changing to daylight saving next sunday and therefore the conference will be one hour earlier than usual. This I have heard is a bit difficult for the people on the US west cost. Due to these considerations I would like to ask your opinion on what to do. Are we going to: 1. Cancel the meeting and having it next week instead? 2. Have the meeting at the proposed time. Please send me your view before 12.00 tuesday (CET). Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 31 13:04: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 NAA17082 for ; Mon, 31 Mar 2003 13:04:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VIRb205661 for mmusic-archive@odin.ietf.org; Mon, 31 Mar 2003 13:27:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIRbK05658 for ; Mon, 31 Mar 2003 13:27:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17062 for ; Mon, 31 Mar 2003 13:03:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIRGK05614; Mon, 31 Mar 2003 13:27:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIJEK04976 for ; Mon, 31 Mar 2003 13:19:14 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16587 for ; Mon, 31 Mar 2003 12:55:22 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id 4A9A3900C1; Mon, 31 Mar 2003 19:57:47 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA02911; Mon, 31 Mar 2003 19:57:46 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA22657; Mon, 31 Mar 2003 19:57:45 +0200 (MET DST) To: Magnus Westerlund Cc: mmusic@ietf.org, Thomas Zeng X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 31 Mar 2003 19:50:30 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 31/03/2003 19:58:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RTSP server behind 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: , Magnus, I concur with Thomas, Since we have telephone handsets that can encode video in real time, Since we have PCs at home with WebCams, Since all these are behind NATs, Since multicast (and SSM) will not be available/desirable/permitted in many cases, We need to make sure that a RTSP server can exist in these environements, as RTSP is the obvious peer-to-peer video protocol to use. I suspect the key issue is that we have to assume that both end points (peers) are behind NATs and then I am afraid that the solution requires a "public" server in the middle. At this moment I suspect that TURN is one possible candidate(?) Some kind of a "reversed" RTSP relay could also do the trick; From the second peer (receiver of streams) point on view that relay would be a plain RTSP server. The special trick is that the first peer (origin of streams) would need to contact this public gateway to "expose" that it has something to stream... And here comes the "reversed" weird stuff: That first peer acts as a RTSP server but it *initiates* the first TCP connection to the RTSP relay and that relay acts as a RTSP client but it is listening on some TCP port... It assumes that there is some way for the first peer to tell the second peer that the streams are available at that relay server. Email could do that, or a voice call, or pigeons ;-) Not sure if/how this is similar/different to what is intended with TURN ? Jonathan can you explain what good TURN is supposed to do to RTSP ? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Thomas Zeng cc: mmusic@ietf.org (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: Re: A reason to put RTSP server behind NAT (was RE: [MMUSIC] What is Magnus Westerlund symmetric RTP?) Classification: Sent by: mmusic-admin@ietf.org 31/03/2003 10:14 Hi Thomas, I think the application in itself is a valid one. However if one provides services that is assumed to be used from the the public net I still think it is a reasonable thing to assume that the service provider (nanny cam host) in this case uses a public IP address. I think that Jonathan is right in his observation of the big question. Will private persons run RTSP servers to provide functionality in for example conversational calls. If the answer is yes, then we need to address the RTSP servers behind NAT problem. However looking at the current market it seems that the important question is how to solve the RTSP server in public network first. If someone is ready to start digging into solving this problem, please go ahead and provide input. The design of the solution for public IP RTSP servers may need to consider something out of a proposal for how to solve the private IP RTSP server problem. However it is obvious that such a solution must also address how to establish the control connection to the server. Last I have one comment to what you write: Thomas Zeng wrote: >Of course one can ask the daycare to put the RTSP server box in the open, >but that means additional cost (it costs $5 dollars/month to get even a >dynamic IP address from Time-Warner cable company here in San Diego), some >one time fee to change network topology -- not to mention security >degradation. > > I kind of react to the last thing. Security degradation: NATs does not provide any security protection, it only provides some obscurity. A NATed machine may of course not be reachable and can therefore not be be directly attacked. However this a firewall can also provide. The major problem is the huge security gap that the deployment of a NAT creates. With NATs there is basically no guaranteed protection against hijacking or eavesdropping attacks as it is impossible to source authenticate. So saying that removing the NAT will reduce the security I think is wrong. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 31 13:20: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 NAA17892 for ; Mon, 31 Mar 2003 13:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VIiI207284 for mmusic-archive@odin.ietf.org; Mon, 31 Mar 2003 13:44:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIiIK07281 for ; Mon, 31 Mar 2003 13:44:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17853 for ; Mon, 31 Mar 2003 13:20:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIi3K07235; Mon, 31 Mar 2003 13:44:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VId6K07009 for ; Mon, 31 Mar 2003 13:39:06 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17618 for ; Mon, 31 Mar 2003 13:15:14 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1903qj-0005kV-00; Mon, 31 Mar 2003 10:17:37 -0800 Date: Mon, 31 Mar 2003 10:17:37 -0800 From: Tom Marshall To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP teleconference, have or not? Message-ID: <20030331181737.GB21571@real.com> References: <3E882239.4080000@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB" Content-Disposition: inline In-Reply-To: <3E882239.4080000@era.ericsson.se> User-Agent: Mutt/1.5.3i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I would not mind cancelling or postponing the call, as it would be nice to be able to sleep in on my b'day. :-) On Mon, Mar 31, 2003 at 01:10:49PM +0200, Magnus Westerlund wrote: > Hi, >=20 > It was planned to have a RTSP telecon on Wednesday (2 April). I am=20 > somewhat short of time but I are willing to have this meeting at 18.00=20 > CET, which after having changed to daylight savings are GMT+2. As I=20 > understand it US are changing to daylight saving next sunday and=20 > therefore the conference will be one hour earlier than usual. This I=20 > have heard is a bit difficult for the people on the US west cost. Due to= =20 > these considerations I would like to ask your opinion on what to do. Are= =20 > we going to: > 1. Cancel the meeting and having it next week instead? > 2. Have the meeting at the proposed time. >=20 > Please send me your view before 12.00 tuesday (CET). --=20 Coding is easy; All you do is sit staring at a terminal until the drops of blood form on your forehead. -- Anonymous --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQE+iIZBqznSmcYu2m8RAkqjAJ9zZ5yrOATQEOTdzxTpiW7xgJHv6gCYtL/A +5/DYLAmkMgjTjkh7pIU1g== =Cs44 -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 31 13:55: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 NAA19093 for ; Mon, 31 Mar 2003 13:55:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VJJBT09551 for mmusic-archive@odin.ietf.org; Mon, 31 Mar 2003 14:19:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VJJBK09548 for ; Mon, 31 Mar 2003 14:19:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19071 for ; Mon, 31 Mar 2003 13:55:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VJJ6K09526; Mon, 31 Mar 2003 14:19:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VJIKK09483 for ; Mon, 31 Mar 2003 14:18:20 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19025 for ; Mon, 31 Mar 2003 13:54:27 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.8/8.12.8) with ESMTP id h2VIuoof017996; Mon, 31 Mar 2003 10:56:50 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 10:56:50 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A794F@MISTY> From: Thomas Zeng To: "'Tom Marshall'" , Magnus Westerlund Cc: IETF MMUSIC WG Subject: RE: [MMUSIC] RTSP teleconference, have or not? Date: Mon, 31 Mar 2003 10:56:42 -0800 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: , Happy Birtheday, Tom. I don't mind skipping this Wed's telecon, either. I am behind in RTSP related work after SF meetings. - thomas -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Monday, March 31, 2003 10:18 AM To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP teleconference, have or not? I would not mind cancelling or postponing the call, as it would be nice to be able to sleep in on my b'day. :-) On Mon, Mar 31, 2003 at 01:10:49PM +0200, Magnus Westerlund wrote: > Hi, > > It was planned to have a RTSP telecon on Wednesday (2 April). I am > somewhat short of time but I are willing to have this meeting at 18.00 > CET, which after having changed to daylight savings are GMT+2. As I > understand it US are changing to daylight saving next sunday and > therefore the conference will be one hour earlier than usual. This I > have heard is a bit difficult for the people on the US west cost. Due to > these considerations I would like to ask your opinion on what to do. Are > we going to: > 1. Cancel the meeting and having it next week instead? > 2. Have the meeting at the proposed time. > > Please send me your view before 12.00 tuesday (CET). -- Coding is easy; All you do is sit staring at a terminal until the drops of blood form on your forehead. -- Anonymous _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Mar 31 16:39: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 QAA26120 for ; Mon, 31 Mar 2003 16:39:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VM2Qd21099 for mmusic-archive@odin.ietf.org; Mon, 31 Mar 2003 17:02:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VM2QK21096 for ; Mon, 31 Mar 2003 17:02:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26104 for ; Mon, 31 Mar 2003 16:38:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VM2FK21084; Mon, 31 Mar 2003 17:02:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VM1RK21033 for ; Mon, 31 Mar 2003 17:01:27 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26086 for ; Mon, 31 Mar 2003 16:37:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2VLdkBd008317; Mon, 31 Mar 2003 16:39:46 -0500 (EST) Message-ID: <3E88B59C.9080604@dynamicsoft.com> Date: Mon, 31 Mar 2003 16:39:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: Magnus Westerlund , mmusic@ietf.org, Thomas Zeng Subject: Re: [MMUSIC] RTSP server behind NAT 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: > Magnus, I concur with Thomas, > > Since we have telephone handsets that can encode video in real time, > Since we have PCs at home with WebCams, Since all these are behind > NATs, Since multicast (and SSM) will not be > available/desirable/permitted in many cases, We need to make sure > that a RTSP server can exist in these environements, as RTSP is the > obvious peer-to-peer video protocol to use. > > I suspect the key issue is that we have to assume that both end > points (peers) are behind NATs and then I am afraid that the solution > requires a "public" server in the middle. > > At this moment I suspect that TURN is one possible candidate(?) NATs on both sides does not always require a relay on the public Internet. It only does if both NATs are symmetric. If at least one is full cone, port restricted, etc., then the relay can be avoided. ICE will make this determination for you, and only use TURN if connectivity cannot be established directly. > > Some kind of a "reversed" RTSP relay could also do the trick; >> From the second peer (receiver of streams) point on view that relay >> would be a plain RTSP server. > The special trick is that the first peer (origin of streams) would > need to contact this public gateway to "expose" that it has something > to stream... And here comes the "reversed" weird stuff: That first > peer acts as a RTSP server but it *initiates* the first TCP > connection to the RTSP relay and that relay acts as a RTSP client but > it is listening on some TCP port... > > It assumes that there is some way for the first peer to tell the > second peer that the streams are available at that relay server. > Email could do that, or a voice call, or pigeons ;-) > > Not sure if/how this is similar/different to what is intended with > TURN ? TURN is similar, in that both sides need to rendezvous at a central server. However, only one side needs to know about TURN. The other will rendezvous by simply sending media to the TURN server. > > Jonathan can you explain what good TURN is supposed to do to RTSP ? It would support the case of the RTSP client and server both behind separate, symmetric NAT. To support it, you need only make sure that RTSP allows the client to specify the IP/port on which it will receive media. This is the same thing you would need to do to support STUN. Getting back to this general issue of peer-to-peer RTSP, in my view this is the ideal case to consider the model where SIP is used to establish the session, and then RTSP is introduced for the control aspects. This way, RTSP does not have to reinvent all the work that is being done in SIP for nat/fw traversal, and all the applications where the media streaming is integrated with person to person communications is very easy. I think that there are no changes to RTSP to support this. We would need some kind of SIP or SDP extensions to signal the usage of RTSP as a control for another media stream, and then use SDP extensions to pass any RTSP information needed to make this work (for example, the session ID). Thoughts? -Jonathan R. -- 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