From exim@www1.ietf.org Tue Jul 1 13:49:14 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 NAA09116 for ; Tue, 1 Jul 2003 13:49:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIN4Q21561 for mmusic-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxsE-0005b3-GV for mmusic-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:02 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09299 for ; Fri, 27 Jun 2003 14:22:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrR-0004pX-DU; Fri, 27 Jun 2003 14:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuOV-0002P9-Gm for mmusic@optimus.ietf.org; Fri, 27 Jun 2003 10:41:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29316 for ; Fri, 27 Jun 2003 10:19:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vu4q-0002ve-00 for mmusic@ietf.org; Fri, 27 Jun 2003 10:19:48 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19Vu4f-0002v6-00 for mmusic@ietf.org; Fri, 27 Jun 2003 10:19:37 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA10631; Fri, 27 Jun 2003 16:18:51 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA29928; Fri, 27 Jun 2003 16:18:53 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 27 Jun 2003 16:18:22 +0200 Message-ID: From: Belling Thomas To: "'Colin Perkins'" , Magnus Westerlund Cc: Belling Thomas , mmusic@ietf.org Subject: Re: [MMUSIC] RTP bandwidth for multiple media streams Date: Fri, 27 Jun 2003 16:18:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Colin I would like to suggest the following additions to the SDP new draft (denoted by ">>> <<<") Alternatively, removing the and the corresponding = explanations from page 19f is acceptable to me, if nobody has concerns = with respect to the backward compatibility. Thanks, Thomas On page 13f: Bandwidth b=3D: ... Two modifiers are initially defined: CT Conference Total If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=3DCT:..." line should be supplied for the session giving the proposed upper limit to the bandwidth used. The = primary purpose of this is to give an approximate idea as to = whether two or more sessions can co-exist simultaneously. >>> For RTP, if several RTP sessions are part of the = conference, the conference total refers to total bandwidth of all RTP = sessions. <<< =20 AS Application-Specific Maximum The bandwidth is interpreted to be application-specific (it will be the application's concept of maximum bandwidth). Normally this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP based applications, AS gives the RTP "session bandwidth" as defined in section 6.2 of [RFC1889]. Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously. On page 19f: Media Announcements m=3D ... The second sub-field is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=3D" field, and = on the transport protocol defined in the third sub-field. Other ports used by the media application (such as the RTCP port [RFC1889]) MAY be derived algorithmically from the base media = port or MAY be specified in a separate attribute (e.g. "a=3Drtcp:" as defined in [RTCPSDP]). For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify = multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=3D" field: m=3D / In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even numbered ports are = used for data and the corresponding one-higher odd port is used for >>> RTCP >>> belonging to this RTP session, and the = denotes the number of RTP sessions<<<. For example: m=3Dvideo 49170/2 RTP/AVP 31 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). If non- contiguous ports are required, they must be signalled using a separate attribute (e.g. "a=3Drtcp:" as defined in [RTCPSDP]) ... -----Urspr=FCngliche Nachricht----- Von: Colin Perkins [mailto:csp@csperkins.org] Gesendet: Mittwoch, 25. Juni 2003 19:03 An: Magnus Westerlund Cc: thomas.belling@siemens.com; mmusic@ietf.org Betreff: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams Can you suggest explicit wording changes to clarify the draft? There is probably still time to incorporate minor edits for clarification. Colin --> Magnus Westerlund writes: > Hi Thomas, >=20 > Even more inline: >=20 > Belling Thomas wrote: > > Hi Magnus, > >=20 > > My answers are inline > >=20 > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Gesendet: Montag, 23. Juni 2003 09:27 > > An: Belling Thomas > > Cc: 'mmusic@ietf.org' > > Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams > >=20 > >=20 > > Hi, > >=20 > > I would agree with the interpretation, at least when it comes to = b=3DAS > > as it clearly specifies that this is the RTP session bandwidth. = When > > one uses a m=3D line with port/2 it becomes two RTP sessions. = However I > > am not certain over how one should in this case interpret any of = the > > other bandwidth attributes. > >=20 > > [Thomas] Fine, but is that 100 Percent clear from the wording of = the > > RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a = clarification > > there >=20 > Yes, this should probably be clarified. I don't think it is obvious. >=20 > >=20 > > The available bandwidth modifiers are: > > CT > > RR > > RS > >=20 > > Lets look at them: > >=20 > > CT is defined in draft-ietf-mmusic-sdp-new-12 as: > > CT Conference Total > > If the bandwidth of a session or media in a session is > > different from the bandwidth implicit from the scope, = a > > "b=3DCT:..." line should be supplied for the session = giving > > the proposed upper limit to the bandwidth used. The > > primary purpose of this is to give an approximate idea = as > > to whether two or more sessions can co-exist > > simultaneously. > >=20 > > Based on this I would interpret that a given CT value should be for = the > > complete media, i.e. counting the total of both RTP sessions. > >=20 > > [Thomas] I agree that this is an interpretation in line with my > > understanding of the intentions of the CT bandwidth modifier. = However, > > the wording is not so clear. What is a "session"? If you understand > > "RTP session", this would contradict your interpretation. As an = aside: > > 3GPP ignores this parameter, so from that perspective a = clarification > > is less urgent than for the AS modifier. >=20 > Yes, the session in the quote is a bit unclear. I think it is a = larger=20 > session concept, like the complete streaming session, or probably = when=20 > it was written the conferencing session with all the media included. = On=20 > media level the text indicates the complete media, which in this case = is=20 > transported over several RTP sessions. So based on these two=20 > interpretations I arrive at my conclusion. >=20 > > When it concerns TIAS I will do the same interpretation that the=20 > > bandwidth value apply per RTP session. > >=20 > > [Thomas] Makes sense if you take TIAS as a kind of refinement of = the AS > > modifier. I did not yet read the draft with that question in mind, = and > > the draft is still in a stage where this can be clarified. >=20 > Yes, it can still be modified. I have made an update and I did not=20 > address the issue. The reason being is that I think the SDP draft = should=20 > first address this. Based on this clarification I would add to the=20 > TIAS draft if necessary. >=20 > >=20 > > My concern is that this simplistic model is probably not what you = would > > like if you would actually use this functionality. If one uses = multiple > > RTP sessions for a single media you are probably doing some form of = > > scalability, etc., and would like to specify the values = independently=20 > > per RTP session. Fortunately there exist today alternatives to = achieve=20 > > this behaviour today. With the help of grouping of media lines it = is=20 > > possible to specify that several m=3D lines are part of the same = media.=20 > > Using FID there is only a pitfall with the following sentence: > > "A media agent handling a media flow that comprises several "m" > > lines MUST send a copy of the media to every "m" line part of = the > > flow as long as the codecs and the direction attribute present = in a > > particular "m" line allow it." > >=20 > > If that is a problem it might be easier to define a new grouping=20 > > attribute for that situation. > > Finally I have a question to the group, has anyone seen that "m=3D = port/2 > > ..." ever been used. And in that case how. > >=20 > > [Thomas] Take the simple example of stereo sound. Why not use the = "m=3D > > port/2 " notification for that? Something in that direction might = have > > been the original motification. From a 3GPP perspective, where this > > relates to thev bandwidth on the air and possibly the rate charged = for > > a service, we should have a clear understanding as this possibility > > exists and might also be misused otherwise. >=20 > I don't think stereo is a good example. First reason is that you=20 > normally don't split left and right channel into different packets,=20 > unless they are really big, reasons are like synchronization. = Therefore=20 > most audio codecs are possible to transport over RTP using a single=20 > source. The sample based codec normally only specify that every other = > sample is left and the other are right. Frame based codec normally = have=20 > more advanced schemes where they encode left and right together to = take=20 > advantage of the similarities between channels. >=20 > My thinking is actually along the lines, if no one uses it, why not=20 > remove it, we will still have to if no implementations are identified = > when going to draft standard. >=20 >=20 > Best Regards >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > = ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 01:18:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28064 for ; Wed, 2 Jul 2003 01:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xa0N-0006BU-TZ for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 01:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h625I73B023766 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 01:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xa0N-0006BF-N1 for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 01:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28051 for ; Wed, 2 Jul 2003 01:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xa0K-0005iy-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 01:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xa0K-0005iu-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 01:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xa0H-0006Ar-3y; Wed, 02 Jul 2003 01:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XZzI-0006Ac-I8 for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 01:17:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28046 for ; Wed, 2 Jul 2003 01:16:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XZzF-0005iV-00 for mmusic@ietf.org; Wed, 02 Jul 2003 01:16:57 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19XZzE-0005i0-00 for mmusic@ietf.org; Wed, 02 Jul 2003 01:16:56 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h625GEiB002673 for ; Wed, 2 Jul 2003 01:16:18 -0400 (EDT) Message-ID: <3F026A96.5000907@dynamicsoft.com> Date: Wed, 02 Jul 2003 01:16:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTP denial of service Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I'd like to draw your attention to the following I-D that I submitted recently: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservice-00.txt This draft describes a denial-of-service attack using RTP. This attack can be launched using any protocol that uses an offer/answer-like SDP exchange, including SIP and RTSP. The draft also discusses ICE as a solution to the problem. Comments welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 06:56:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02962 for ; Wed, 2 Jul 2003 06:56:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfHU-0002jm-2o for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 06:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Au8IA010516 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 06:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfHT-0002jX-VH for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:56:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02809 for ; Wed, 2 Jul 2003 06:56:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfHP-00018e-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 06:56:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfHP-00018b-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 06:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfHO-0002hm-VW; Wed, 02 Jul 2003 06:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfHH-0002ge-Gz for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 06:55:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02737; Wed, 2 Jul 2003 06:55:52 -0400 (EDT) Message-Id: <200307021055.GAA02737@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, 02 Jul 2003 06:55:51 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol Offer Answer Examples Author(s) : A. Johnston, R. Sparks Filename : draft-ietf-mmusic-offer-answer-examples-01.txt Pages : 26 Date : 2003-7-1 This document gives examples of Session Description Protocol (SDP) offer answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examples-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-ietf-mmusic-offer-answer-examples-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-ietf-mmusic-offer-answer-examples-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-7-1134642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-offer-answer-examples-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-offer-answer-examples-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134642.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 12:52:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01073 for ; Wed, 2 Jul 2003 12:52:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkpv-0006eQ-Ch for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 12:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Gq30j025562 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 12:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkpv-0006eD-9l for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01056 for ; Wed, 2 Jul 2003 12:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xkpt-0003sV-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 12:52:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xkpt-0003sS-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 12:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkps-0006dp-KU; Wed, 02 Jul 2003 12:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkpL-0006dR-Fe for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 12:51:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01041 for ; Wed, 2 Jul 2003 12:51:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkpJ-0003sI-00 for mmusic@ietf.org; Wed, 02 Jul 2003 12:51:25 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19XkpJ-0003s3-00 for mmusic@ietf.org; Wed, 02 Jul 2003 12:51:25 -0400 Received: from WDC1EXC0002.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id QAA26030; Wed, 2 Jul 2003 16:50:38 GMT Received: from idc1exc0001.corp.global.level3.com ([10.1.7.194]) by WDC1EXC0002.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 12:49:31 -0400 Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Jul 2003 10:49:29 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [MMUSIC] RTP denial of service Date: Wed, 2 Jul 2003 10:49:28 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DDC7@idc1exc0004.corp.global.level3.com> Thread-Topic: [MMUSIC] RTP denial of service Thread-Index: AcNAWV9ZCyPeNuWrQwWmUbxobr+BmQAWwXSw From: "Hearty, John" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 02 Jul 2003 16:49:29.0008 (UTC) FILETIME=[E74AEB00:01C340B9] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My security knowledge is weak, and I would like some help understanding why the following from the draft is true: There is no requirement that the calls come from unauthenticated sources. The attack can be launched even if the device requires authentication. Of course, authentication might provide some amount of traceability. Wouldn't it be more difficult to launch the attack if authentication was required? I would think RTP would not start sending if the original request could not be authenticated. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 01, 2003 11:16 PM > To: mmusic@ietf.org > Subject: [MMUSIC] RTP denial of service >=20 > Folks, >=20 > I'd like to draw your attention to the following I-D that I submitted > recently: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp- > denialofservice-00.txt >=20 > This draft describes a denial-of-service attack using RTP. This attack > can be launched using any protocol that uses an offer/answer-like SDP > exchange, including SIP and RTSP. The draft also discusses ICE as a > solution to the problem. >=20 > Comments welcome. >=20 > Thanks, > Jonathan R. >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 13:21:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02808 for ; Wed, 2 Jul 2003 13:21:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlHz-000117-Bv for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 13:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62HL3fW003905 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 13:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlHz-00010u-8u for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 13:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02791 for ; Wed, 2 Jul 2003 13:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlHx-0004Vd-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 13:21:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XlHw-0004Va-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 13:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlHx-00010W-Vr; Wed, 02 Jul 2003 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlHF-000105-7j for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 13:20:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02776 for ; Wed, 2 Jul 2003 13:20:14 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlHD-0004VA-00 for mmusic@ietf.org; Wed, 02 Jul 2003 13:20:15 -0400 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 19XlHB-0004V4-00 for mmusic@ietf.org; Wed, 02 Jul 2003 13:20:14 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl6.philips.com (Postfix) with ESMTP id D599E5DEF9; Wed, 2 Jul 2003 19:20:11 +0200 (MET DST) Received: from smtprelay-nl2.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 TAA20352; Wed, 2 Jul 2003 19:20:11 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA09419; Wed, 2 Jul 2003 19:20:10 +0200 (MEST) Subject: RE: [MMUSIC] RTP denial of service To: "Hearty, John" Cc: "Jonathan Rosenberg" , mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 2 Jul 2003 19:11:06 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 02/07/2003 19:21:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Let me check If I understood correctly what jonathan wanted to mean: the point is that the attacker COULD be authenticated e.g. the attacker *buys* a movie (say with a stolen credit card) from www.holywood-movies.com etc .... BUT tweaks the streaming request in a way that the movie will be sent toward whitehouse.gov instead ! Traceability would be if the stolen credit card can be traced, or if the attacker IP address can be traced etc ... BTW jonathan, for this exact reason (to my knowledge most) RTSP server implementations today would refuse to stream except toward the originating RTSP IP address (or at least this feature can be turned on) ... which is actually a problem for NAT traversal in case the NAT attributes a different IP address for the RTSP and RTP traffic ! regards, Philippe Gentric philippe.gentric@philips.com http://www.platform4.philips.com To: "Jonathan Rosenberg" cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: RE: [MMUSIC] RTP denial of service "Hearty, John" Classification: Sent by: mmusic-admin@ietf.org 02/07/2003 18:49 My security knowledge is weak, and I would like some help understanding why the following from the draft is true: There is no requirement that the calls come from unauthenticated sources. The attack can be launched even if the device requires authentication. Of course, authentication might provide some amount of traceability. Wouldn't it be more difficult to launch the attack if authentication was required? I would think RTP would not start sending if the original request could not be authenticated. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 01, 2003 11:16 PM > To: mmusic@ietf.org > Subject: [MMUSIC] RTP denial of service > > Folks, > > I'd like to draw your attention to the following I-D that I submitted > recently: > > http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp- > denialofservice-00.txt > > This draft describes a denial-of-service attack using RTP. This attack > can be launched using any protocol that uses an offer/answer-like SDP > exchange, including SIP and RTSP. The draft also discusses ICE as a > solution to the problem. > > Comments welcome. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 16:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13073 for ; Wed, 2 Jul 2003 16:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHo-0002iG-2y for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 16:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KX4Gg010420 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 16:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHn-0002hz-Vk for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12911 for ; Wed, 2 Jul 2003 16:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoHj-0007IA-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 16:33:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XoHi-0007I5-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 16:32:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHl-0002gt-H1; Wed, 02 Jul 2003 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHS-0002g6-Dp for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 16:32:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12776; Wed, 2 Jul 2003 16:32:36 -0400 (EDT) Message-Id: <200307022032.QAA12776@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, 02 Jul 2003 16:32:36 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-04.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 Filename : draft-ietf-mmusic-rfc2326bis-04.txt,.ps,.pdf Pages : 5 Date : 2003-7-2 This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable con- trolled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161616.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 16:33:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13087 for ; Wed, 2 Jul 2003 16:33:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHo-0002iq-Iz for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 16:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KX4gc010448 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 16:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHo-0002iM-F7 for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12920 for ; Wed, 2 Jul 2003 16:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoHk-0007IG-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 16:33:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XoHj-0007I9-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 16:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHl-0002h6-Ru; Wed, 02 Jul 2003 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHW-0002gB-Vm for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 16:32:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12807; Wed, 2 Jul 2003 16:32:41 -0400 (EDT) Message-Id: <200307022032.QAA12807@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, 02 Jul 2003 16:32:41 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-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. 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) : F. Andreasen, M. Baugher, D. Wing Filename : draft-ietf-mmusic-sdescriptions-01.txt Pages : 22 Date : 2003-7-2 This document defines a Session Description Protocol (SDP) cryptographic attribute for media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This document defines the Secure Real- time Transport Protocol (SRTP) parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-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-ietf-mmusic-sdescriptions-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-ietf-mmusic-sdescriptions-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-7-2161627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161627.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 2 23:49:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13633 for ; Wed, 2 Jul 2003 23:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xv5k-00043f-Dk for mmusic-archive@odin.ietf.org; Wed, 02 Jul 2003 23:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h633n4d1015595 for mmusic-archive@odin.ietf.org; Wed, 2 Jul 2003 23:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xv5k-00043S-AV for mmusic-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 23:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13619 for ; Wed, 2 Jul 2003 23:49:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xv5i-0002L0-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 23:49:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xv5h-0002Kx-00 for mmusic-web-archive@ietf.org; Wed, 02 Jul 2003 23:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xv5h-000433-2b; Wed, 02 Jul 2003 23:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xv4q-00042l-Rd for mmusic@optimus.ietf.org; Wed, 02 Jul 2003 23:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13602 for ; Wed, 2 Jul 2003 23:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xv4o-0002Kh-00 for mmusic@ietf.org; Wed, 02 Jul 2003 23:48:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Xv4n-0002KD-00 for mmusic@ietf.org; Wed, 02 Jul 2003 23:48:05 -0400 Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h633lWiB003686; Wed, 2 Jul 2003 23:47:34 -0400 (EDT) Message-ID: <3F03A74F.6090401@dynamicsoft.com> Date: Wed, 02 Jul 2003 23:47:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: "Hearty, John" , mmusic@ietf.org Subject: Re: [MMUSIC] RTP denial of service References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit philippe.gentric@philips.com wrote: > Let me check If I understood correctly what jonathan wanted to mean: > > the point is that the attacker COULD be authenticated > e.g. the attacker *buys* a movie (say with a stolen credit card) > from www.holywood-movies.com etc .... > BUT tweaks the streaming request in a way that the > movie will be sent toward whitehouse.gov instead ! > > Traceability would be if the stolen credit card can be traced, > or if the attacker IP address can be traced etc ... Yes. But its easier than that. Many media services don't even require the user to pay. For example, if you connect to the free world dialup voicemail server without needing to pay anyone anything. Just go to their website and sign up. > > > BTW jonathan, for this exact reason (to my knowledge most) RTSP server implementations > today would refuse to stream except toward the originating RTSP IP address > (or at least this feature can be turned on) Sure, and the draft discusses this. All this means is that the client needs to spoof the source address. > ... > which is actually a problem for NAT traversal in case the NAT attributes > a different IP address for the RTSP and RTP traffic ! Yup, exactly. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 04:42:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02556 for ; Thu, 3 Jul 2003 04:42:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XzfJ-0004Rj-HE for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 04:42:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h638g5Ri017090 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 04:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XzfJ-0004RZ-B8 for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 04:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02536 for ; Thu, 3 Jul 2003 04:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XzfG-0004Hx-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 04:42:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XzfF-0004Ht-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 04:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XzfF-0004Qz-3i; Thu, 03 Jul 2003 04:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XzeM-0004QS-JX for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 04:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02521 for ; Thu, 3 Jul 2003 04:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XzeJ-0004HZ-00 for mmusic@ietf.org; Thu, 03 Jul 2003 04:41:03 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19XzeI-0004HR-00 for mmusic@ietf.org; Thu, 03 Jul 2003 04:41:03 -0400 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E28FE6A905; Thu, 3 Jul 2003 11:40:56 +0300 (EEST) Message-ID: <3F03EB89.3040808@piuha.net> Date: Thu, 03 Jul 2003 11:38:33 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTP denial of service 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 Jonathan, Thanks for bringing up this problem. I agree that the attack exists, and I also agree that nothing in the RTP packets (such as SRTP) can help prevent such attacks. I not expert enough to say anything about suitability of RTCP or STUN. Attacks of a similar nature have been discussed in the context of other protocols, for instance Mobile IPv6. The general nature of such attacks is that a signaling protocol conveys an address, and the lack of verification for this address results in a vulnerability; attackers choose the address of an innocent third party and start "bombing" this address with packets. What makes these attacks bad is that the attacker can initiate the attack with just few packets, a legitimate entity in the network does all the hard work, and the victim's link becomes congested. The attack has always serious consequences due to its amplification factor. In SIP, this factor is due to the bandwidth difference in signaling vs. payload. In Mobile IPv6, this factor was due to the ability to "open" a connection, speed it up, and then move it towards the victim. What also makes the attack hard is that the packets to the victim never come from the attacker, they come from another, legitimate entity in the network. This makes the tracing of the attack hard: the attacker may be traceable from that entity, but can we be sure that the administrator of the entity can be reached for assistance? This may be easy if the entity is owned by an operator, but what if its my home server or someone's windows PC? However, assuming you do get the help of the administrator, there seems to be a few different levels of hardness for tracing the attacker then: - No verification: The attack was initiated by a packet sent to the entity, no assurance of the authentication of the attacker or the validity of the source address in the packet. SIP INVITE without TLS and authentication appears to allow this, no? What makes this level tricky is that there are designs where DoS attackers can be traced even if they lie about their addresses, e.g. itrace. However, these mechanisms only work for bulk attacks, and here we only send a few signaling packets. - Source address verification: The attack can only be launched after some exchange of packets, where the source address of the packet has been verified to be valid. In SIP, anon Digest would allow you to do source address verification. Similarly, even server-side only authenticated TLS would suffice for this check. Note: in Mobile IPv6, the address of the attacker was conveyed also in the packets to the victim, but this does not appear to be the case in SIP/RTP, because the RTP packets don't contain the address of the node that initiated the signaling. - Authentication: the attacker's identity is authenticated in some manner, you can probably trace the attacker down to his postal address/passport/ credit card. I believe we should strive for making the tracing of the attack at least so hard that the attacker has to give his IP address information, i.e., make the first case not allowed. Still, tracing is a post-attack activity, expensive and unreliable. So I believe you are right in trying to prevent such attacks. A few words about prevention. Typically, a "return routability test" approach is used, as I think you are doing also for STUN. I'm not expert enough in STUN to know if it provides sufficient binding between requests and responses so that off-path attackers can't easily spoof responses? But I would guess you have taken this into account. Another issue is whether there needs to be a binding between the signaling exchange and the STUN exchange, e.g. a session identifier or something like that? Or is it sufficient to rely on the right timing? What about busy servers, wouldn't the timing of the attack be more likely to succeed with them? Finally, the prevention mechanisms themselves may be susceptible to an attack. An example: initiate N sessions with different servers, all pointing to the same victim node, who gets a lot of STUN queries. This attack does not have amplification, but it is hard to trace, harder than a direct dos packet storm from a single source, and harder than than a reflection attack. In some other cases, such attacks have been made easier to trace by using solely the source address of a packet in initiating responses and protocol actions. But I understand that this may not be an option here. Demanding TlS/anon digest from all SIP signaling exchanges does force the attacker to give up a lot of information and some CPU cycles, so that may be sufficient. --Jari _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 09:18:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09873 for ; Thu, 3 Jul 2003 09:18:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3yP-0003iY-1b for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 09:18:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63DI5td014286 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 09:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3yO-0003iL-Ts for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 09:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09861 for ; Thu, 3 Jul 2003 09:18:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3yN-0006BW-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 09:18:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y3yM-0006BT-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 09:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3yL-0003hq-GY; Thu, 03 Jul 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3y2-0003hZ-Lo for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 09:17:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09851 for ; Thu, 3 Jul 2003 09:17:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3y1-0006BK-00 for mmusic@ietf.org; Thu, 03 Jul 2003 09:17:41 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Y3y0-0006BH-00 for mmusic@ietf.org; Thu, 03 Jul 2003 09:17:40 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h63DHcIi028049; Thu, 3 Jul 2003 15:17:39 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW49LVDX; Thu, 3 Jul 2003 15:19:53 +0200 Message-ID: <3F042CF2.5050307@ericsson.com> Date: Thu, 03 Jul 2003 15:17:38 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Aaron Colwell , mmusic@ietf.org, Aravind Narasimhan Subject: Re: [MMUSIC] Aggregate Control URI References: <20030630174155.GC25404@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, A few words in relation to this. When I filed the bug I was thinking of such a case that you try to aggregate two different media that the server did not offer as an aggregated session. However during discussions I have come to the conclusion that it will be difficult to use. However the aggregated control URI resolution may have more usage when it comes to session that are supposed to be used where the aggregated control URL is missing. I do think it is good to have stated a direction on how this is resolved in cased when information is missing but the server allows it. Note that a server can always refuse to perform aggregation of a media with another, by responding to a SETUP request trying to aggregate with a "459 Aggregate operation not allowed" error code. In that case the client will have to perform synchronization, etc. locally using two non-aggregated sessions. "If an Aggregate control URI is not specified in the session description, a client MUST create an URI for aggregate control of the session." I don't think this formulation is good. The reason a session description does not give a aggregated control URI is that it does not desire the media to be aggregated. I would reformulate the sentence into: If an Aggregate control URI is not specified in the session description, it is probably a indication that non-aggregated control SHOULD be used. However a client MAY try to SETUP the session in aggregated control. If the server refuse to aggregate the specified media, the server SHALL use the 459 error code. If the server allows the aggregation, then the client MUST create an URI for aggregate control of the session. This URI MUST contain the servers host address ... As a conclusion, I don't see a problem with this resolution, although it is not what we had discussed. So I can understand any comments to this. What do you think of the updated text? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 10:37:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13699 for ; Thu, 3 Jul 2003 10:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Cp-0006ZQ-5c for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 10:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Eb3KZ025223 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 10:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Co-0006Yg-VW for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13682 for ; Thu, 3 Jul 2003 10:36:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Cm-0007Hm-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 10:37:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y5Cl-0007Hi-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 10:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Cn-0006XK-44; Thu, 03 Jul 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Bx-0006OZ-4a for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 10:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13642 for ; Thu, 3 Jul 2003 10:36:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Bu-0007Gi-00 for mmusic@ietf.org; Thu, 03 Jul 2003 10:36:06 -0400 Received: from [203.145.162.130] (helo=ExchangeIND.bcubedinc.com) by ietf-mx with esmtp (Exim 4.12) id 19Y5Bt-0007Fz-00 for mmusic@ietf.org; Thu, 03 Jul 2003 10:36:05 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34170.5AFF0B74" Date: Thu, 3 Jul 2003 20:05:31 +0530 Message-ID: <9237E3CBCE780448B2DBECB8227424552F6E82@exchangeind.bcubedinc.com> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: reason for teardown Thread-Index: AcNBcFrwpeeefpcyR8OH81Kulxu0EQ== From: "Saurabh Srivastava" To: Subject: [MMUSIC] reason for teardown Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34170.5AFF0B74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQogICAgICBUaGlzIGlzIGEgcmVxdWlyZW1lbnQgdGhhdCB3b3VsZCBlbmFibGUg dGhlIHN0cmVhbWluZyBzZXJ2ZXIgdG8ga25vdyB0aGF0IHdoeSBhIHNlc3Npb24gaXMgYmVpbmcg Y2xvc2VkIGZyb20gY2xpZW50IGFuZCBpbiB0dXJuLCBhbGxvdyBpdCB0byBnaXZlIGd1YXJhbnRl ZWQgZGVsaXZlcnkgc2VydmljZSBpbiBwYXktcGVyLXZpZXcgc2NlbmFyaW9zLg0KIA0KVEVBUkRP V04sIHdoaWNoIGluZGlhY3RlcyB0aGUgZW5kIG9mIHRoZSBzZXNzaW9uIGNhbiBiZSBzZW50IGZy b20gYSBjbGllbnQgZHVlIHRvOi0NCjEuIFRoZSBSVFAgY2hhbm5lbCBpbmRpY2F0aW5nIHRoYXQg dGhlIGNsaXAgaXMgb3Zlci4NCjIuIFRoZSB1c2VyIGluaXRpYXRpbmcgdGhlIHJlcXVlc3QgdG8g ZW5kIHRoZSBzZXNzaW9uLg0KMy4gTmV0d29yayBwcm9ibGVtIGR1ZSB0byB3aGljaCB0aGUgY2xp ZW50IGdldHMgdGltZS1vdXQuDQogDQpXaGF0IGlzIHRoZSBzb2x1dGlvbiBmb3IgdGhpcyBwcm9i bGVtPw0KU2hvdWxkIGl0IGJlIGEgaGVhZGVyIGluIHRoZSBURUFSRE9XTiByZXF1ZXN0Pw0KT3Ig aXQgc2hvdWxkIGJlIGluZmVycmVkIGZyb20gZGF0YSBsZXZlbCBwcm90b2NvbCBsaWtlIFJUUD8N CiANClJlZ2FyZHMsDQpTYXVyYWJoIFNyaXZhc3RhdmENClByaWNpcGFsIE1lbWJlciBFbmdpbmVl cmluZw0KSnVseSBTeXN0ZW1zLg0K ------_=_NextPart_001_01C34170.5AFF0B74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PEhUTUw+CjxIRUFEPgo8TUVUQSBOQU1FPSJHRU5FUkFUT1IiIENvbnRlbnQ9Ik1pY3Jvc29mdCBE SFRNTCBFZGl0aW5nIENvbnRyb2wiPgo8VElUTEU+PC9USVRMRT4KPC9IRUFEPgo8Qk9EWT4KPERJ Vj5IaSBGb2xrcyw8L0RJVj4KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhp cyBpcyBhIHJlcXVpcmVtZW50IAp0aGF0IHdvdWxkIGVuYWJsZSB0aGUgc3RyZWFtaW5nIHNlcnZl ciB0byBrbm93IHRoYXQgd2h5IGEgc2Vzc2lvbiBpcyBiZWluZyAKY2xvc2VkIGZyb20gY2xpZW50 IGFuZCZuYnNwO2luIHR1cm4sJm5ic3A7YWxsb3cgaXQgdG8gZ2l2ZSBndWFyYW50ZWVkIGRlbGl2 ZXJ5IApzZXJ2aWNlIGluIHBheS1wZXItdmlldyBzY2VuYXJpb3MuPC9ESVY+CjxESVY+Jm5ic3A7 PC9ESVY+CjxESVY+VEVBUkRPV04sIHdoaWNoIGluZGlhY3RlcyB0aGUgZW5kIG9mIHRoZSBzZXNz aW9uIGNhbiBiZSAKc2VudCBmcm9tIGEgY2xpZW50IGR1ZSB0bzotPC9ESVY+CjxESVY+MS4mbmJz cDtUaGUmbmJzcDtSVFAgY2hhbm5lbCBpbmRpY2F0aW5nIHRoYXQgdGhlIGNsaXAgCmlzIG92ZXIu PC9ESVY+CjxESVY+Mi4gVGhlIHVzZXIgaW5pdGlhdGluZyB0aGUgcmVxdWVzdCB0byBlbmQgdGhl IApzZXNzaW9uLjwvRElWPgo8RElWPjMuIE5ldHdvcmsgcHJvYmxlbSBkdWUgdG8gd2hpY2ggdGhl IGNsaWVudCBnZXRzIAp0aW1lLW91dC48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5XaGF0 IGlzIHRoZSBzb2x1dGlvbiBmb3IgdGhpcyBwcm9ibGVtPzwvRElWPgo8RElWPlNob3VsZCBpdCBi ZSBhIGhlYWRlciBpbiB0aGUgVEVBUkRPV04gcmVxdWVzdD88L0RJVj4KPERJVj5PciBpdCBzaG91 bGQgYmUgaW5mZXJyZWQgZnJvbSBkYXRhIGxldmVsIHByb3RvY29sIGxpa2UgClJUUD88L0RJVj4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj5SZWdhcmRzLDwvRElWPgo8RElWPlNhdXJhYmggU3JpdmFz dGF2YTwvRElWPgo8RElWPlByaWNpcGFsIE1lbWJlciBFbmdpbmVlcmluZzwvRElWPgo8RElWPkp1 bHkgU3lzdGVtcy48L0RJVj4KPC9CT0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C34170.5AFF0B74-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 11:15:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15038 for ; Thu, 3 Jul 2003 11:15:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5nb-0008ND-33 for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 11:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FF3nL032183 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 11:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5na-0008N0-VH for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:15:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15020 for ; Thu, 3 Jul 2003 11:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5na-00001G-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:15:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y5nZ-00001D-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5nZ-0008MZ-5M; Thu, 03 Jul 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5nF-0008ME-8e for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 11:14:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15007 for ; Thu, 3 Jul 2003 11:14:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5nE-00000t-00 for mmusic@ietf.org; Thu, 03 Jul 2003 11:14:40 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Y5nD-00000p-00 for mmusic@ietf.org; Thu, 03 Jul 2003 11:14:39 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h63FEcGJ015122; Thu, 3 Jul 2003 17:14:38 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW44ZB72; Thu, 3 Jul 2003 17:14:38 +0200 Message-ID: <3F04485E.6080803@ericsson.com> Date: Thu, 03 Jul 2003 17:14:38 +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: Saurabh Srivastava CC: mmusic@ietf.org Subject: Re: [MMUSIC] reason for teardown References: <9237E3CBCE780448B2DBECB8227424552F6E82@exchangeind.bcubedinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Do I understand you correctly that you would like to have some indication on why the client performed the TEARDOWN? If not can you please be more clear about what you desire. I would also like to to point out certain things in your mail. Saurabh Srivastava wrote: > Hi Folks, > This is a requirement that would enable the streaming server to > know that why a session is being closed from client and in turn, allow > it to give guaranteed delivery service in pay-per-view scenarios. > > TEARDOWN, which indiactes the end of the session can be sent from a > client due to:- > 1. The RTP channel indicating that the clip is over. There is no explicit indication on that a clip is over. In streaming this is normally resolved at the client when it notices that the full-range has been played out. The client may also detect that delivery has stopped of RTP packets. To verify that this is not due to transport errors the client should look at the RTCP SR. However this method does not guarantee that a clip is really over, and not simply a part where no packets are delivered. For Live content this is basically very difficult unless other means indicate that the session has expired. On possibility in RTSP to notify clients that the session is really over is to redirect the client to such a message. Introducing the message in the session for live content is also useful, at least for the user. Normally the client will issue a TEARDOWN in this case when the user does not rewind the session or otherwise inactive for some period of time. In other words, the end of the clip does not automatically lead to a TEARDOWN request. > 2. The user initiating the request to end the session. Which is the case you receive a TEARDOWN. > 3. Network problem due to which the client gets time-out. In this case there will be no TEARDOWN request. The server side simply times out the session. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 11:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15790 for ; Thu, 3 Jul 2003 11:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61E-0000nm-5y for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 11:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FT84b003075 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 11:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61D-0000nV-Iw for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15641 for ; Thu, 3 Jul 2003 11:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y61C-0000D0-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:29:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y61B-0000Cw-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y619-0000mp-MR; Thu, 03 Jul 2003 11:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y60y-0000dR-Pf for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 11:28:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15595; Thu, 3 Jul 2003 11:28:50 -0400 (EDT) Message-Id: <200307031528.LAA15595@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:28:50 -0400 Subject: [MMUSIC] I-D ACTION:draft-luoma-mmusic-img-metadata-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 : Internet Media Guide Metadata Baseline Author(s) : J. Luoma Filename : draft-luoma-mmusic-img-metadata-01.txt Pages : 29 Date : 2003-7-3 This document defines the base metadata format for Internet Media Guides (IMGs), applicable to a wide variety of Internet hosts and communication links. IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. An IMG metadata model, semantics of the IMG media metadata entities, and an XML-based framing structure for IMG media metadata are defined. The aim is to reuse existing metadata standards for the IMG metadata format where possible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-luoma-mmusic-img-metadata-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-luoma-mmusic-img-metadata-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-luoma-mmusic-img-metadata-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-7-3111453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-luoma-mmusic-img-metadata-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-luoma-mmusic-img-metadata-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111453.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 11:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16123 for ; Thu, 3 Jul 2003 11:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y627-000174-5g for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 11:30:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FU31Q004275 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 11:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y626-00016p-WF for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15959 for ; Thu, 3 Jul 2003 11:30:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y625-0000ER-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:30:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y625-0000EO-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y625-00014p-Mi; Thu, 03 Jul 2003 11:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61c-0000xM-4I for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 11:29:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15720; Thu, 3 Jul 2003 11:29:29 -0400 (EDT) Message-Id: <200307031529.LAA15720@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:29:29 -0400 Subject: [MMUSIC] I-D ACTION:draft-luoma-mmusic-img-muppet-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport Author(s) : J. Luoma Filename : draft-luoma-mmusic-img-muppet-02.txt Pages : 34 Date : 2003-7-3 This document defines MUPPET, a unidirectional point-to-multipoint transport protocol for the delivery of Internet Media Guide metadata. The MUPPET protocol is based on Asynchronous Layered Coding, a massively scalable protocol for reliable multicast transport. MUPPET is intended to be used with the Internet Media Guide framework, and in addition may be useful with other applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-luoma-mmusic-img-muppet-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-luoma-mmusic-img-muppet-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-luoma-mmusic-img-muppet-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3111602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-luoma-mmusic-img-muppet-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-luoma-mmusic-img-muppet-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 11:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16839 for ; Thu, 3 Jul 2003 11:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y643-0001r5-7y for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 11:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FW3E1007125 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 11:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y643-0001qq-1z for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:32:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16671 for ; Thu, 3 Jul 2003 11:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y641-0000KA-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y640-0000K7-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y641-0001oj-0I; Thu, 03 Jul 2003 11:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y63b-0001cM-QZ for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 11:31:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16500; Thu, 3 Jul 2003 11:31:33 -0400 (EDT) Message-Id: <200307031531.LAA16500@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:31:33 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : How to Enable Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls Author(s) : M. Westerlund, T. Zeng Filename : draft-ietf-mmusic-rtsp-nat-01.txt Pages : 37 Date : 2003-7-3 This document describes six different types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations are given. Further a description on how RTSP relates to firewalls is given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-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-ietf-mmusic-rtsp-nat-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-ietf-mmusic-rtsp-nat-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-7-3112136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112136.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 12:14:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15791 for ; Thu, 3 Jul 2003 11:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61E-0000nl-5n for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 11:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FT80M003080 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 11:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61D-0000nW-KI for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15643 for ; Thu, 3 Jul 2003 11:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y61C-0000D3-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:29:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y61B-0000Cx-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 11:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y618-0000gf-MT; Thu, 03 Jul 2003 11:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y60Z-0000d4-PN for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 11:28:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15498; Thu, 3 Jul 2003 11:28:25 -0400 (EDT) Message-Id: <200307031528.LAA15498@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:28:25 -0400 Subject: [MMUSIC] I-D ACTION:draft-nomura-mmusic-img-framework-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 : A Framework for the Usage of Internet Media Guides Author(s) : Y. Nomura et al. Filename : draft-nomura-mmusic-img-framework-01.txt Pages : 25 Date : 2003-7-3 This document defines a framework for the delivery of Internet Media Guides (IMGs). A media guide is a set of information (metadata) describing the features of multimedia content in order to subscribe to, manage and exchange multimedia content. Several protocols and methods exist that are able to deliver metadata over the Internet, giving information on Internet services, media and content. This existing knowledge is used to provide a general framework for Internet Media Guides and outlines existing scalability and flexibility issues, along with the desirable features that can solve these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nomura-mmusic-img-framework-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-nomura-mmusic-img-framework-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-nomura-mmusic-img-framework-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-7-3111405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nomura-mmusic-img-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-nomura-mmusic-img-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111405.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 12:20:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21031 for ; Thu, 3 Jul 2003 12:20:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6oV-00066w-Hw for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 12:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63GK3Hb023486 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 12:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6oV-00066j-Bn for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 12:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21005 for ; Thu, 3 Jul 2003 12:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6oT-0001lG-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 12:20:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y6oT-0001lD-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 12:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6oT-000662-DZ; Thu, 03 Jul 2003 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6oM-00064w-VV for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 12:19:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20943 for ; Thu, 3 Jul 2003 12:19:51 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6oL-0001ku-00 for mmusic@ietf.org; Thu, 03 Jul 2003 12:19:53 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19Y6oK-0001kp-00 for mmusic@ietf.org; Thu, 03 Jul 2003 12:19:52 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id CF3BB5511B; Thu, 3 Jul 2003 18:19:50 +0200 (MET DST) Received: from smtprelay-nl2.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 SAA09110; Thu, 3 Jul 2003 18:19:50 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA08751; Thu, 3 Jul 2003 18:19:49 +0200 (MEST) Subject: Re: [MMUSIC] reason for teardown To: Magnus Westerlund Cc: mmusic@ietf.org, Saurabh Srivastava X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 3 Jul 2003 18:10:45 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 03/07/2003 18:20:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus you wrote: > There is no explicit indication on that a clip is over. there is RTCP "BYE" ;-) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Saurabh Srivastava cc: mmusic@ietf.org (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: Re: [MMUSIC] reason for teardown Magnus Westerlund Sent by: mmusic-admin@ietf.org 03/07/2003 17:14 Hi, Do I understand you correctly that you would like to have some indication on why the client performed the TEARDOWN? If not can you please be more clear about what you desire. I would also like to to point out certain things in your mail. Saurabh Srivastava wrote: > Hi Folks, > This is a requirement that would enable the streaming server to > know that why a session is being closed from client and in turn, allow > it to give guaranteed delivery service in pay-per-view scenarios. > > TEARDOWN, which indiactes the end of the session can be sent from a > client due to:- > 1. The RTP channel indicating that the clip is over. There is no explicit indication on that a clip is over. In streaming this is normally resolved at the client when it notices that the full-range has been played out. The client may also detect that delivery has stopped of RTP packets. To verify that this is not due to transport errors the client should look at the RTCP SR. However this method does not guarantee that a clip is really over, and not simply a part where no packets are delivered. For Live content this is basically very difficult unless other means indicate that the session has expired. On possibility in RTSP to notify clients that the session is really over is to redirect the client to such a message. Introducing the message in the session for live content is also useful, at least for the user. Normally the client will issue a TEARDOWN in this case when the user does not rewind the session or otherwise inactive for some period of time. In other words, the end of the clip does not automatically lead to a TEARDOWN request. > 2. The user initiating the request to end the session. Which is the case you receive a TEARDOWN. > 3. Network problem due to which the client gets time-out. In this case there will be no TEARDOWN request. The server side simply times out the session. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 12:53:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24352 for ; Thu, 3 Jul 2003 12:53:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7KU-0007j8-T1 for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 12:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Gr6qi029696 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 12:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7KU-0007it-OY for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 12:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24310 for ; Thu, 3 Jul 2003 12:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7KT-00032I-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 12:53:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y7KS-00032F-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 12:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7KO-0007iG-Uh; Thu, 03 Jul 2003 12:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7Ji-0007hr-EU for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 12:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24255 for ; Thu, 3 Jul 2003 12:52:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7Jg-000314-00 for mmusic@ietf.org; Thu, 03 Jul 2003 12:52:16 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19Y7Jg-00030b-00 for mmusic@ietf.org; Thu, 03 Jul 2003 12:52:16 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Thu, 03 Jul 2003 09:51:42 -0700 Date: Thu, 3 Jul 2003 09:58:08 -0700 (PDT) From: Aaron Colwell To: mmusic@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP Transport field question Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The RTSP spec states that the client_port and server_port fields indicate what ports the client and server are expected to receive data on. Is it also safe to assume that the client and server will send data from these ports as well? I didn't see anything in the spec that explicitly states that this is the case. Could someone please clarify. Thanks, Aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 3 15:27:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03106 for ; Thu, 3 Jul 2003 15:27:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9jT-0005gQ-54 for mmusic-archive@odin.ietf.org; Thu, 03 Jul 2003 15:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63JR3PH021840 for mmusic-archive@odin.ietf.org; Thu, 3 Jul 2003 15:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9jS-0005gB-W9 for mmusic-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 15:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03077 for ; Thu, 3 Jul 2003 15:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y9jR-00002Z-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 15:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y9jR-00002W-00 for mmusic-web-archive@ietf.org; Thu, 03 Jul 2003 15:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9jR-0005fl-GD; Thu, 03 Jul 2003 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9jF-0005fa-Nl for mmusic@optimus.ietf.org; Thu, 03 Jul 2003 15:26:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03074 for ; Thu, 3 Jul 2003 15:26:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y9jE-00002O-00 for mmusic@ietf.org; Thu, 03 Jul 2003 15:26:48 -0400 Received: from [203.145.162.130] (helo=ExchangeIND.bcubedinc.com) by ietf-mx with esmtp (Exim 4.12) id 19Y9jD-000023-00 for mmusic@ietf.org; Thu, 03 Jul 2003 15:26:47 -0400 content-class: urn:content-classes:message Subject: RE: [MMUSIC] reason for teardown MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34198.F70AF712" Date: Fri, 4 Jul 2003 00:56:13 +0530 Message-ID: <9237E3CBCE780448B2DBECB8227424552F6E83@exchangeind.bcubedinc.com> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [MMUSIC] reason for teardown Thread-Index: AcNBddVkciGxKidgRg2BwYEN1dYghQAHsXqR From: "Saurabh Srivastava" To: "Magnus Westerlund" Cc: Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34198.F70AF712 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQogICAgVGhpcyBpcyBjb3JyZWN0LiBNeSBxdWVzdGlvbiBpcyB0aGF0IEkgd291bGQgbGlr ZSB0byBoYXZlICJzb21lIGluZGljYXRpb24gb24gd2h5IHRoZSBjbGllbnQgcGVyZm9ybWVkIHRo ZSBURUFSRE9XTiIuIEl0IGlzIG1vcmUgZnJvbSB0aGUgc2VydmVyIHBlcnNwZWN0aXZlIHNvIHRo YXQgaXQgY2FuIHVuZGVyc3RhbmQgdGhlIG5hdHVyZSBvZiB0aGUgcmVxdWVzdCBhbmQgdGhlbiB0 YWtlIGFwcHJvcHJpYXRlIGFjdGlvbi4NCiANCkFzIGZhciBhcyB0aGUgc29sdXRpb25zIGFyZSBj b25jZXJuZWQgZm9yIHRoZSBwcm9ibGVtLCBJIGhhdmUgdHJpZWQgdmFyaW91cyB0aGluZ3MsIGJ1 dCBjb3VsZCBub3QgZmluZCBhIGZvb2wgcHJvb2Ygc29sdXRpb24gdGhhdCB3b3VsZCB3b3JrIGlu IGFsbCBjb25kaXRpb25zLg0KIA0KUlRDUCBCWUUgYXMgcG9pbnRlZCBvdXQgYnkgUGhpbGlwcGUg aXMgYW4gaW5kaWNhdGlvbiBmcm9tIHRoZSBzZXJ2ZXIgaW5kaWNhdGluZyB0aGF0IHRoZSBzZXNz aW9uIGlzIG92ZXIuIEFuZCBSUidzIGtlZXAgaW5kaWNhdGluZyB0aGUgcmVjZXB0aW9uIHF1YWxp dHkgZnJvbSB0aGUgY2xpZW50IGluIHRoZSBpZGVhbCBzY2VuYXJpby4gQnV0IGR1ZSB0byBhIHBv c3NpYmxlIGRlbGF5IGluIG5ldHdvcmtzIChzcGVjaWFsbHkgd2lyZWxlc3MgbmV0d29ya3MpIHRo ZXJlIGNvdWxkIGJlIGEgc2NlbmFyaW8gdGhhdCB0aGUgUlIncyBkbyBub3QgcmVhY2ggdGhlIHNl cnZlciBpbiB0aW1lIGFuZCBtZWFud2hpbGUgdGhlIGNsaWVudCB0aW1lcyBvdXQgKGFjY29yZGlu ZyB0byB0aW1lLW91dCBzZXR0aW5ncyBvbiBVQSkuIEluIHRoYXQgY2FzZSBURUFSRE9XTiBhcnJp dmVzIGZyb20gY2xpZW50LCBhbmQgdGhlIHNlcnZlciBpcyB1bmF3YXJlIG9mIHRoZSByZWFzb24g d2h5IGl0IGNhbWUuDQogDQpSVENQIEJZRSBjYW4gYmUgc2VudCBieSB0aGUgY2xpZW50IHRvIGlu ZGljYXRlIHRoYXQgaXQgaXMgZXhpdGluZyBmcm9tIHRoZSBzZXNzaW9uIGJ1dCB0aGVyZSB0b28g dGhlIHJlYXNvbiBmaWVsZCBpcyBub3QgbWFuZGF0b3J5IChTbyBsZWZ0IGJsYW5rIGluIG1vc3Qg b2YgdGhlIGltcGxlbWVudGF0aW9ucyA6LSkgICAgKS4NCiANCkkgYmVsaWV2ZSwgaWYgdGhlIFRF QVJET1dOIGNvbnRhaW5zIHRoaXMgaW5mb3JtYXRpb24gYWxzbywgdGhlbiB0aGUgc2VydmVyIHdp bGwgcGVyaGFwcyBiZSBhYmxlIHRvIHByb3ZpZGUgdGhlIHN1cHBvcnQgc3lzdGVtcyBtb3JlIGlu Zm9ybWF0aW9uIHNvIHRoYXQgYXBwcm9wcmlhdGUgYWN0aW9ucyBjb3VsZCBiZSB0YWtlbi4gTW9y ZSBzbyBiZWNhdXNlIGluIG1vc3Qgb2YgdGhlIGltcGxlbWVudGF0aW9ucyBSVFNQIHdvdWxkIGJl IGltcGxlbWVudGVkIG9uIFRDUCBhbmQgUlRQIG9uIFVEUC4gQW5kIHNpbmNlIHRoaXMgaW5mb3Jt YXRpb24gYmVjb21lcyBxdWl0ZSBjaXJpdGljYWwgaWYgZW5kIHVzZXIncyBtb25leSBpcyBpbnZv bHZlZCwgUlRTUCB3b3VsZCBiZSBhIGJldHRlciBjaGFubmVsIHRvIGNvbnZleSB0aGlzIGluZm9y bWF0aW9uIG9uIGFjY291bnQgb2YgYSBtb3JlIHJlbGlhYmxlIHRyYW5zcG9ydC4NCiANClJlZ2Fy ZHMsDQp3YWl0aW5nIGZvciBjb21tZW50cywNCiANClNhdXJhYmggU3JpdmFzdGF2YQ0K ------_=_NextPart_001_01C34198.F70AF712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PEhUTUw+CjxIRUFEPgo8TUVUQSBOQU1FPSJHRU5FUkFUT1IiIENvbnRlbnQ9Ik1pY3Jvc29mdCBE SFRNTCBFZGl0aW5nIENvbnRyb2wiPgo8VElUTEU+PC9USVRMRT4KPC9IRUFEPgo8Qk9EWSBkaXI9 bHRyPgo8RElWPkhpLDwvRElWPgo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIGNvcnJl Y3QuIE15IHF1ZXN0aW9uIGlzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIApoYXZlJm5ic3A7InNvbWUg aW5kaWNhdGlvbiBvbiB3aHkgdGhlIGNsaWVudCBwZXJmb3JtZWQgdGhlIFRFQVJET1dOIi4gSXQg aXMgbW9yZSAKZnJvbSB0aGUgc2VydmVyIHBlcnNwZWN0aXZlIHNvIHRoYXQgaXQgY2FuIHVuZGVy c3RhbmQgdGhlIG5hdHVyZSBvZiB0aGUgcmVxdWVzdCAKYW5kIHRoZW4gdGFrZSBhcHByb3ByaWF0 ZSBhY3Rpb24uPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+QXMgZmFyIGFzIHRoZSBzb2x1 dGlvbnMgYXJlIGNvbmNlcm5lZCBmb3IgdGhlIHByb2JsZW0sIEkgaGF2ZSB0cmllZCB2YXJpb3Vz IAp0aGluZ3MsIGJ1dCBjb3VsZCBub3QgZmluZCBhIGZvb2wgcHJvb2Ygc29sdXRpb24gdGhhdCB3 b3VsZCB3b3JrIGluIGFsbCAKY29uZGl0aW9ucy48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJ Vj5SVENQIEJZRSBhcyBwb2ludGVkIG91dCBieSBQaGlsaXBwZSBpcyBhbiBpbmRpY2F0aW9uIGZy b20gdGhlIHNlcnZlciAKaW5kaWNhdGluZyB0aGF0IHRoZSBzZXNzaW9uIGlzIG92ZXIuIEFuZCBS UidzIGtlZXAgaW5kaWNhdGluZyB0aGUgcmVjZXB0aW9uIApxdWFsaXR5IGZyb20gdGhlIGNsaWVu dCBpbiB0aGUgaWRlYWwgc2NlbmFyaW8uIEJ1dCBkdWUgdG8gYSBwb3NzaWJsZSBkZWxheSBpbiAK bmV0d29ya3MgKHNwZWNpYWxseSB3aXJlbGVzcyBuZXR3b3JrcykgdGhlcmUgY291bGQgYmUgYSBz Y2VuYXJpbyB0aGF0IHRoZSBSUidzIApkbyBub3QgcmVhY2ggdGhlIHNlcnZlciBpbiB0aW1lIGFu ZCBtZWFud2hpbGUgdGhlIGNsaWVudCB0aW1lcyBvdXQgKGFjY29yZGluZyB0byAKdGltZS1vdXQg c2V0dGluZ3Mgb24gVUEpLiBJbiB0aGF0IGNhc2UgVEVBUkRPV04gYXJyaXZlcyBmcm9tIGNsaWVu dCwgYW5kIHRoZSAKc2VydmVyIGlzIHVuYXdhcmUgb2YgdGhlIHJlYXNvbiB3aHkgaXQgY2FtZS48 L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5SVENQIEJZRSBjYW4gYmUgc2VudCBieSB0aGUg Y2xpZW50IHRvIGluZGljYXRlIHRoYXQgaXQgaXMgZXhpdGluZyBmcm9tIHRoZSAKc2Vzc2lvbiBi dXQgdGhlcmUgdG9vIHRoZSByZWFzb24gZmllbGQgaXMgbm90IG1hbmRhdG9yeSAoU28gbGVmdCBi bGFuayBpbiBtb3N0IApvZiB0aGUgaW1wbGVtZW50YXRpb25zIDotKSZuYnNwOyZuYnNwOyZuYnNw OyApLjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkkgYmVsaWV2ZSwgaWYgdGhlIFRFQVJE T1dOIGNvbnRhaW5zIHRoaXMgaW5mb3JtYXRpb24gYWxzbywgdGhlbiB0aGUgc2VydmVyIAp3aWxs IHBlcmhhcHMgYmUgYWJsZSB0byBwcm92aWRlIHRoZSBzdXBwb3J0IHN5c3RlbXMgbW9yZSBpbmZv cm1hdGlvbiBzbyB0aGF0IAphcHByb3ByaWF0ZSBhY3Rpb25zIGNvdWxkIGJlIHRha2VuLiBNb3Jl IHNvIGJlY2F1c2UgaW4gbW9zdCBvZiB0aGUgCmltcGxlbWVudGF0aW9ucyBSVFNQIHdvdWxkIGJl IGltcGxlbWVudGVkIG9uIFRDUCBhbmQgUlRQIG9uIFVEUC4gQW5kIHNpbmNlIHRoaXMgCmluZm9y bWF0aW9uIGJlY29tZXMgcXVpdGUgY2lyaXRpY2FsIGlmIGVuZCB1c2VyJ3MgbW9uZXkgaXMgaW52 b2x2ZWQsIFJUU1Agd291bGQgCmJlIGEgYmV0dGVyIGNoYW5uZWwgdG8gY29udmV5IHRoaXMgaW5m b3JtYXRpb24gb24gYWNjb3VudCBvZiBhIG1vcmUgcmVsaWFibGUgCnRyYW5zcG9ydC48L0RJVj4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj5SZWdhcmRzLDwvRElWPgo8RElWPndhaXRpbmcgZm9yIGNv bW1lbnRzLDwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlNhdXJhYmggU3JpdmFzdGF2YTwv RElWPgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C34198.F70AF712-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 4 10:33:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28141 for ; Fri, 4 Jul 2003 10:33:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRcZ-0007zq-V0 for mmusic-archive@odin.ietf.org; Fri, 04 Jul 2003 10:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64EX7Bs030738 for mmusic-archive@odin.ietf.org; Fri, 4 Jul 2003 10:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRcZ-0007zh-QF for mmusic-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 10:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28133 for ; Fri, 4 Jul 2003 10:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRcX-00069c-00 for mmusic-web-archive@ietf.org; Fri, 04 Jul 2003 10:33:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YRcW-00069Y-00 for mmusic-web-archive@ietf.org; Fri, 04 Jul 2003 10:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRcS-0007wA-QS; Fri, 04 Jul 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRbx-0007vW-RK for mmusic@optimus.ietf.org; Fri, 04 Jul 2003 10:32:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28085 for ; Fri, 4 Jul 2003 10:32:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRbv-00068r-00 for mmusic@ietf.org; Fri, 04 Jul 2003 10:32:27 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19YRbu-00068l-00 for mmusic@ietf.org; Fri, 04 Jul 2003 10:32:26 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h64EWOGJ017306; Fri, 4 Jul 2003 16:32:24 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4QHFXV; Fri, 4 Jul 2003 16:32:56 +0200 Message-ID: <3F058FF5.1020802@ericsson.com> Date: Fri, 04 Jul 2003 16:32:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saurabh Srivastava CC: mmusic@ietf.org Subject: Re: [MMUSIC] reason for teardown References: <9237E3CBCE780448B2DBECB8227424552F6E83@exchangeind.bcubedinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Comments inline Saurabh Srivastava wrote: > Hi, > This is correct. My question is that I would like to have "some > indication on why the client performed the TEARDOWN". It is more from > the server perspective so that it can understand the nature of the > request and then take appropriate action. > > As far as the solutions are concerned for the problem, I have tried > various things, but could not find a fool proof solution that would work > in all conditions. > > RTCP BYE as pointed out by Philippe is an indication from the server > indicating that the session is over. The RTCP BYE is sent when the RTP session is closed, this is normally done as a result of a RTSP TEARDOWN. RTCP BYE shall not be used to indicate the end of a media stream. And RR's keep indicating the > reception quality from the client in the ideal scenario. But due to a > possible delay in networks (specially wireless networks) there could be > a scenario that the RR's do not reach the server in time and meanwhile > the client times out (according to time-out settings on UA). In that > case TEARDOWN arrives from client, and the server is unaware of the > reason why it came. In a streaming server -> client scenario the server will mostly be sending Sender reports, when not active sending media it will switch to RRs after a few reporting interval, normally 2. If any RTCP bandwidth is assigned to the session, the limiting factor in a point to point case is the 5 second minimal rule. This means that RTCP packet will at most be sent from each end every 7.5 seconds. The default RTSP session time-out is 60 seconds, that means that it will be time for at least 8 RTCP packet. This means that the probability to all be lost is very small. Therefore a server should not time out a client unnecessary. And when a server times out a client no TEARDOWN request is sent from the client or server. The server simply removes the session. When it comes to client side time outs they must be reasonably set. They must allow for some transport problems. And a client would not time out a session while it receives media. And I don't see a reason for timing out the session very quickly even if no media is received. One must also give the user time to react to the end of the clip. Therefore I would not recommend such a timer to be shorter than 30 seconds. > > RTCP BYE can be sent by the client to indicate that it is exiting from > the session but there too the reason field is not mandatory (So left > blank in most of the implementations :-) ). Yes, reasons field is seldom used. Also the RTCP bye is normally only sent once, therefore has high probability to become lost. > > I believe, if the TEARDOWN contains this information also, then the > server will perhaps be able to provide the support systems more > information so that appropriate actions could be taken. More so because > in most of the implementations RTSP would be implemented on TCP and RTP > on UDP. And since this information becomes quite ciritical if end user's > money is involved, RTSP would be a better channel to convey this > information on account of a more reliable transport. > When it comes to sending charging related information in protocols from the client I have a view that this is difficult. The most normal problem is how to avoid fraud. If a client can implement in the teardown a reason which will mean that the user doesn't have to pay, it will be exploited. Could you please further elaborate on what the different cases you want to distinguish are? I have some trouble seeing how different TEARDOWN reasons will have impact. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 4 10:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28353 for ; Fri, 4 Jul 2003 10:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRkG-0000L7-10 for mmusic-archive@odin.ietf.org; Fri, 04 Jul 2003 10:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Ef4JC001301 for mmusic-archive@odin.ietf.org; Fri, 4 Jul 2003 10:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRkF-0000Ku-UW for mmusic-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 10:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28336 for ; Fri, 4 Jul 2003 10:41:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRkD-0006FQ-00 for mmusic-web-archive@ietf.org; Fri, 04 Jul 2003 10:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YRkC-0006FN-00 for mmusic-web-archive@ietf.org; Fri, 04 Jul 2003 10:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRkE-0000JG-LE; Fri, 04 Jul 2003 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRk4-0000HY-PE for mmusic@optimus.ietf.org; Fri, 04 Jul 2003 10:40:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28331 for ; Fri, 4 Jul 2003 10:40:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRk2-0006FB-00 for mmusic@ietf.org; Fri, 04 Jul 2003 10:40:50 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19YRk1-0006F8-00 for mmusic@ietf.org; Fri, 04 Jul 2003 10:40:49 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h64EemIi016345; Fri, 4 Jul 2003 16:40:48 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW440B3B; Fri, 4 Jul 2003 16:40:48 +0200 Message-ID: <3F0591ED.2080503@ericsson.com> Date: Fri, 04 Jul 2003 16:40:45 +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: Aaron Colwell CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP Transport field question 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 Aaron, It is strongly encouraged that you do this. As you point out it is not written in the RFC 2326. We should clarify this recommendation with motivation in the updated specification. However I don't think we can mandate it. What would people say about a SHOULD? Reasons for sending media from the respective ports that you also receive are: NAT traversal and Firewalls. Also source filtering needs this. I could understand that server manufactures desire clients to send RTCP from their designated port, otherwise server running many sessions on the same port has problems. I don't know if all implementations do this, probably not. Any one knowing this? Cheers Magnus Aaron Colwell wrote: > The RTSP spec states that the client_port and server_port fields indicate > what ports the client and server are expected to receive data on. Is it > also safe to assume that the client and server will send data from these > ports as well? I didn't see anything in the spec that explicitly states > that this is the case. Could someone please clarify. > > Thanks, > Aaron > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 03:51:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16553 for ; Mon, 7 Jul 2003 03:51:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQmG-0003xW-6O for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 03:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h677pCd5015217 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 03:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQmF-0003xM-QC for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 03:51:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16516 for ; Mon, 7 Jul 2003 03:51:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZQmD-0001dU-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 03:51:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZQmC-0001dQ-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 03:51:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQm5-0003wK-S7; Mon, 07 Jul 2003 03:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQlc-0003vl-3e for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 03:50:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16484; Mon, 7 Jul 2003 03:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZQlU-0001ca-00; Mon, 07 Jul 2003 03:50:24 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19ZQlT-0001cW-00; Mon, 07 Jul 2003 03:50:23 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h677oM1R000384; Mon, 7 Jul 2003 16:50:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h677oL8E011473; Mon, 7 Jul 2003 16:50:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h677oKeH007805; Mon, 7 Jul 2003 16:50:21 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA15432; Mon, 7 Jul 2003 16:50:19 +0900 (JST) Received: from [127.0.0.1] by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA22703; Mon, 7 Jul 2003 16:50:19 +0900 (JST) Date: Mon, 07 Jul 2003 16:49:18 +0900 From: "NAKAMURA, Hidefumi" To: sip@ietf.org, mmusic@ietf.org Cc: hidefumi.nakamura@staff.east.ntt.co.jp Message-Id: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Appropriate usage of SIP and RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, all. I have a question about the relationship between SIP and RTSP. In RFC3261, there is a description that says "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, ..." (RFC3261 Section 2) However, my understanding is that both SIP and RTSP have the capability for "discovery of UAs or media streams." If I use SIP to establish a stream session and use RTSP to control the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and SETUP-OK. Was there any discussion on how to use these two protocols appropriately? With SIP application server, network providers can provide various services on contents delivery while we will not be able to do so only with RTSP, I think. On the other hand, RTSP has enough capability for discovery of media streams and for negotiation of SDPs. So, I think, for the simple delivery of contents, RTSP is appropriate to use, and for various session control services regarding contents delivery, SIP with RTSP is appropriate to use. Any opinions? I wonder why no contents delivery server seems to prepare SIP stack now. Is it because, up to now, there exists only a simple contents delivery service? best regards, -- NAKAMURA, Hidefumi NTT ServiceIntegration /NetworkServiceSystems Labs. tel: +81(422)59 3904; fax:+81(422)60 4012 --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 04:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17400 for ; Mon, 7 Jul 2003 04:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRTg-0005kX-2n for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 04:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h678a4pC022100 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 04:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRTf-0005kL-OG for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 04:36:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17384 for ; Mon, 7 Jul 2003 04:36:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRTc-00027l-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 04:36:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZRTb-00027i-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 04:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRTe-0005jo-09; Mon, 07 Jul 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRSo-0005jR-Pc for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 04:35:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17358; Mon, 7 Jul 2003 04:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRSl-00026o-00; Mon, 07 Jul 2003 04:35:07 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ZRSk-00026j-00; Mon, 07 Jul 2003 04:35:07 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h678Z7Ii004491; Mon, 7 Jul 2003 10:35:07 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8X2QR16; Mon, 7 Jul 2003 10:35:07 +0200 Message-ID: <3F0930B4.8090202@ericsson.com> Date: Mon, 07 Jul 2003 10:35:00 +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: "NAKAMURA, Hidefumi" CC: sip@ietf.org, mmusic@ietf.org, hidefumi.nakamura@staff.east.ntt.co.jp Subject: Re: [MMUSIC] Appropriate usage of SIP and RTSP References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> 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, See comments inline: NAKAMURA, Hidefumi wrote: > Hi, all. > > I have a question about the relationship between SIP and RTSP. > > In RFC3261, there is a description that says > "SIP is not a vertically integrated communications system. SIP is > rather a component that can be used with other IETF protocols to > build a complete multimedia architecture. Typically, these > architectures will include protocols such as the Real-time Transport > Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and > providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC > 2326 [29]) for controlling delivery of streaming media, ..." > (RFC3261 Section 2) > > However, my understanding is that both SIP and RTSP have the capability > for "discovery of UAs or media streams." > If I use SIP to establish a stream session and use RTSP to control > the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and > SETUP-OK. > > Was there any discussion on how to use these two protocols appropriately? Not to my knowledge. The SIP and RTSP combination has not been explored, however it seem to contain a number of use cases. For example inviting a media server into a SIP session or a conference session. There are significant overlap in SIP and RTSP, mostly in regards to session establishment that are done i different ways. > > With SIP application server, network providers can provide various > services on contents delivery while we will not be able to do so only > with RTSP, I think. On the other hand, RTSP has enough capability for > discovery of media streams and for negotiation of SDPs. > So, I think, for the simple delivery of contents, RTSP is appropriate to > use, and for various session control services regarding contents > delivery, SIP with RTSP is appropriate to use. What do you mean with "session control services regarding contents delivery"? > > Any opinions? > > I wonder why no contents delivery server seems to prepare SIP stack now. > Is it because, up to now, there exists only a simple contents delivery > service? I believe that no one has looked into this and have had a need. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 05:30:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18541 for ; Mon, 7 Jul 2003 05:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSJv-0007pq-97 for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 05:30:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h679U3im030112 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 05:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSJv-0007pb-5B for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 05:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18521 for ; Mon, 7 Jul 2003 05:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZSJr-0002as-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 05:29:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZSJr-0002ap-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 05:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSJt-0007oz-LO; Mon, 07 Jul 2003 05:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSJO-0007oQ-Ey for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 05:29:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18518; Mon, 7 Jul 2003 05:29:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZSJL-0002am-00; Mon, 07 Jul 2003 05:29:27 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19ZSJJ-0002aj-00; Mon, 07 Jul 2003 05:29:26 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h679TL1R016892; Mon, 7 Jul 2003 18:29:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h679TL8E027105; Mon, 7 Jul 2003 18:29:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h679TLeH001479; Mon, 7 Jul 2003 18:29:21 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA23972; Mon, 7 Jul 2003 18:29:20 +0900 (JST) Received: from [127.0.0.1] by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA02492; Mon, 7 Jul 2003 18:29:20 +0900 (JST) Date: Mon, 07 Jul 2003 18:28:19 +0900 From: "NAKAMURA, Hidefumi" To: Magnus Westerlund Subject: Re: [MMUSIC] Appropriate usage of SIP and RTSP Cc: sip@ietf.org, mmusic@ietf.org In-Reply-To: <3F0930B4.8090202@ericsson.com> References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> <3F0930B4.8090202@ericsson.com> Message-Id: <20030707174715.1826.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Magnus, Thank you for your quick response. I wrote down my opinion after your comments. > Hi, > > See comments inline: > > NAKAMURA, Hidefumi wrote: > > Hi, all. > > > > I have a question about the relationship between SIP and RTSP. > > > > In RFC3261, there is a description that says > > "SIP is not a vertically integrated communications system. SIP is > > rather a component that can be used with other IETF protocols to > > build a complete multimedia architecture. Typically, these > > architectures will include protocols such as the Real-time Transport > > Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and > > providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC > > 2326 [29]) for controlling delivery of streaming media, ..." > > (RFC3261 Section 2) > > > > However, my understanding is that both SIP and RTSP have the capability > > for "discovery of UAs or media streams." > > If I use SIP to establish a stream session and use RTSP to control > > the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and > > SETUP-OK. > > > > Was there any discussion on how to use these two protocols appropriately? > > Not to my knowledge. The SIP and RTSP combination has not been explored, > however it seem to contain a number of use cases. For example inviting a > media server into a SIP session or a conference session. > > There are significant overlap in SIP and RTSP, mostly in regards to > session establishment that are done i different ways. > > > > With SIP application server, network providers can provide various > > services on contents delivery while we will not be able to do so only > > with RTSP, I think. On the other hand, RTSP has enough capability for > > discovery of media streams and for negotiation of SDPs. > > So, I think, for the simple delivery of contents, RTSP is appropriate to > > use, and for various session control services regarding contents > > delivery, SIP with RTSP is appropriate to use. > > What do you mean with "session control services regarding contents > delivery"? For example, if we establish a stream session via SIP application server owned by the network provider, the application server can redirect the session to the appropriate contents delivery server from the standpoint of location, bandwidth prepared between terminals and the server, or condition of contents server (i.e. in congestion, failure, and so on.) Say, we get a media stream URI from a portal server. The terminal(or set top box) requests a session initiation to the media stream URI to the SIP application server. The SIP application server routes the request to the contents delivery server that stores the media. However, if the server is in congestion and returns 503, the SIP application server can select and redirect the session to another contents delivery server instead. I do not think this is possible with only RTSP. (though the interaction among the portal server, contents delivery servers and the terminals might enable this type of service in some extent.) > > Any opinions? > > > > I wonder why no contents delivery server seems to prepare SIP stack now. > > Is it because, up to now, there exists only a simple contents delivery > > service? > > I believe that no one has looked into this and have had a need. I understand. Thank you very much for your comments. Maybe it is interesting to investigate the use case, anyway. > Best Regards > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- NAKAMURA, Hidefumi NTT ServiceIntegration /NetworkServiceSystems Labs. tel: +81(422)59 3904; fax:+81(422)60 4012 --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 07:42:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21628 for ; Mon, 7 Jul 2003 07:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUNf-0004x1-Jn for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 07:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Bg3TR019027 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 07:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUNf-0004wo-Gm for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 07:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21609 for ; Mon, 7 Jul 2003 07:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZUNe-0003SD-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 07:42:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZUNe-0003SA-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 07:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUNc-0004wQ-Su; Mon, 07 Jul 2003 07:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUNU-0004wC-Aw for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 07:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21604 for ; Mon, 7 Jul 2003 07:41:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZUNT-0003S5-00 for mmusic@ietf.org; Mon, 07 Jul 2003 07:41:51 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ZUNS-0003S2-00 for mmusic@ietf.org; Mon, 07 Jul 2003 07:41:50 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h67BfjGJ023056; Mon, 7 Jul 2003 13:41:45 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4QRQL5; Mon, 7 Jul 2003 13:42:28 +0200 Message-ID: <3F095C79.7070109@ericsson.com> Date: Mon, 07 Jul 2003 13:41:45 +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: Jonathan Rosenberg CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTP denial of service References: <3F026A96.5000907@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, I have now had time to read your draft. It summaries the problem of the attack fairly well. However I think one can elaborate a bit more on some use cases and in relation to NAT traversal. First, the problem of destination addresses in combination with NATs that use multiple addresses. If a NAT would assign different NAT mappings to different external addresses there is a problem with the limiting text that RTSP has. This also is present for a single RTP session where RTP and RTCP will be separate flows. This leads to that simple limitations can't be used while still NAT traversal or TURN servers are in use. Secondly the RTCP prevention that you mention in chapter 3 has more flaws then you describe, but not one of them you describe I would say. I don't see a reason to force the sending side to have this stop and go behaviour you describe. I would more work in the terms of how TFRC behave, I think. If no RTCP reports are received the sending bit-rate is throttled back, to almost non existing levels. This will limit the severity of the attack. However with using many sessions it might still be possible to achieve enough force amplification. The flaw you missed in your description of using RTCP as limiting factor is first that if the attacker directs a RTCP stream to itself and only the RTP stream to the target, it can simple generate false RTCP reports. The senders RTCP reports contains the number of packets sent, which makes it easy to increase the RTCP receiver reports extended counter. The initial RTP sequence number are usually transmitted in RTSP's RTP-Info header. Therefore all necessary information for faking a perfect reception pattern exist, keeping any congestion control based on RTCP reports happy. Third, the solution space. As you mention an alternative to using STUN in this requesting mechanism would be to develop a RTP payload format and RTCP packet type to contain necessary information of granting a media stream. What may be missing in STUN is the possibility to provide information about the media stream that the receiver accepts. However I don't know if such a solution would be any better. Maybe on the paper it would have a clearer demultiplexing than between STUN and RTP. However STUN can be used with any media protocol that can be differentiated on the first byte, while a RTP/RTCP solution would be limited to that protocol. Fourth, have you looked at what solutions DCCP would provide to this problem? I think that the session establishment could ensure that the client accepts the media stream. Fifth, what is the current status of ICE? Can we expect any progress for ICE within the IETF. Sixth, doesn't one need to use STUN with authentication to prevent other security attacks that based on falsifying STUN responses, even when the session establisher is not an attacker? Best Regards Magnus Westerlund Jonathan Rosenberg wrote: > Folks, > > I'd like to draw your attention to the following I-D that I submitted > recently: > > http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservice-00.txt > > > This draft describes a denial-of-service attack using RTP. This attack > can be launched using any protocol that uses an offer/answer-like SDP > exchange, including SIP and RTSP. The draft also discusses ICE as a > solution to the problem. > > Comments welcome. > > Thanks, > Jonathan R. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 12:39:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02474 for ; Mon, 7 Jul 2003 12:39:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZ17-0003xY-GX for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 12:39:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Gd5FU015217 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 12:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZ17-0003xM-CF for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 12:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02427 for ; Mon, 7 Jul 2003 12:39:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ15-0006OC-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 12:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZZ14-0006O9-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 12:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZ13-0003vq-FT; Mon, 07 Jul 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZ06-0003v0-Bh for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 12:38:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02397 for ; Mon, 7 Jul 2003 12:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ04-0006NW-00 for mmusic@ietf.org; Mon, 07 Jul 2003 12:38:00 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ04-0006NN-00 for mmusic@ietf.org; Mon, 07 Jul 2003 12:38:00 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Mon, 07 Jul 2003 09:37:21 -0700 Date: Mon, 7 Jul 2003 09:44:16 -0700 (PDT) From: Aaron Colwell To: Magnus Westerlund cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP Transport field question In-Reply-To: <3F0591ED.2080503@ericsson.com> Message-ID: References: <3F0591ED.2080503@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think adding a SHOULD about this is fine. We should also list the reasons you stated below so that people think of it being closer to a MUST if they want a more robust and interoperable implementation. Aaron On Fri, 4 Jul 2003, Magnus Westerlund wrote: > Hi Aaron, > > It is strongly encouraged that you do this. As you point out it is not > written in the RFC 2326. We should clarify this recommendation with > motivation in the updated specification. However I don't think we can > mandate it. What would people say about a SHOULD? > > Reasons for sending media from the respective ports that you also > receive are: NAT traversal and Firewalls. Also source filtering needs > this. I could understand that server manufactures desire clients to send > RTCP from their designated port, otherwise server running many sessions > on the same port has problems. > > I don't know if all implementations do this, probably not. Any one > knowing this? > > Cheers > > Magnus > > Aaron Colwell wrote: > > The RTSP spec states that the client_port and server_port fields indicate > > what ports the client and server are expected to receive data on. Is it > > also safe to assume that the client and server will send data from these > > ports as well? I didn't see anything in the spec that explicitly states > > that this is the case. Could someone please clarify. > > > > Thanks, > > Aaron > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 17:35:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17199 for ; Mon, 7 Jul 2003 17:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZddZ-00083X-Tm for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 17:35:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67LZ5h5030963 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 17:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZddZ-00083K-QE for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 17:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17188 for ; Mon, 7 Jul 2003 17:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZddX-0003Hm-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 17:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZddW-0003Hj-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 17:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZddV-00082O-Mm; Mon, 07 Jul 2003 17:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdcq-00081P-86 for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 17:34:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17176; Mon, 7 Jul 2003 17:34:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zdcn-0003HU-00; Mon, 07 Jul 2003 17:34:17 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19Zdcl-0003HR-00; Mon, 07 Jul 2003 17:34:16 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 7 Jul 2003 16:29:17 UT To: avt@ietf.org, avt-admin@ietf.org, mmusic@ietf.org Cc: , , , csp@csperkins.org, Orit Levin , Roni Even , nismail@cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Mon, 7 Jul 2003 17:34:10 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 07/07/2003 05:30:03 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488" Content-Disposition: inline Subject: [MMUSIC] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488 Content-type: text/plain; charset=us-ascii Attached you will find draft-basso-avt-videoconreq-00.txt Abstract: A variety of communication services such as video conferencing and video messaging rely on the capability of video encoders and decoders to exchange control commands. This document outlines this set of commands as well as the requirements for their transport. Comments are more than welcome. Andrea Basso NMS Communications (732) 936-2118 (See attached file: draft-basso-avt-videoconreq-00.zip) --0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488 Content-type: application/zip; name="draft-basso-avt-videoconreq-00.zip" Content-Disposition: attachment; filename="draft-basso-avt-videoconreq-00.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAM+L5y44JHRBrRsAAH5dAAAiAAAAZHJhZnQtYmFzc28tYXZ0LXZpZGVvY29ucmVx LTAwLnR4dO1cW28byXJ+D3L+Q8MvkXBIWqRk2TKCYGVZ9sqxLEWUfRAYRtCcaZJ9PBee6RnJXORf nCC/N3Xp21x08R6vn8LF0hQ5U11dXZevqqvnT/8k6HXcpLoUn3SqSnFdycJsyqoWb6uy2YhHv/5k iZ0VtaoKVYvXlVzW99/TfR1PxCtpTOmJvS6TJldF/VKkSG28wF/H8qYe3yC3SVlU6m/jvb1J/c0O 9eF8Lk7KPG8Knchal4XxxP6h18XkvbrRxY8gdnX8+tPZ/Oziw48g9mEizkwudfaPEjvRJinFfGtq lQeZnX7b6EqZl+KdLBpZbcVsb+/gfkLu9a7J6PL9wNk9H/h1pf7WwHi45EYsy0rUXh3LpaA1F7Do dVVm8G+eyyI1D5Kf17JuDBKo19qIc5WX/Uuv8afUqpuAz7LwqjxmVYbB8AdQgmWT4fgFcAgsJErc 6nrtSUn4cVOVN9qQ+sG4c5WgKorpHv519eZktjc7FJ+nXyYDTLdHBUYqoF9WX3Wx8gza2ahgbafF ShdKVXiVn5M0X8WbsgIGd85Or9/sjoRmgtKMeDrwp6O9Qns3wNGHslZAXNZtvkoYr7JXiVxuYZ5g qak2daUXTT3EpDRhNt6kaVaTx82brD4ieCMznZJiSGDhm86bHCVh9DdPJgf1WBuaHTK5UKLZpLJW 6UhUapPJBD8BgXJhykzB92KxtXNzJKIJ4KpvRa1zBYI5q3n95QaWd1NpiXIqRWNUj3mvCwZGXapK oZbkcAPcleHwcF+iSc4qt8ODyAu84QkKUkS+BkZbgRGayZMhvVUigzVAMSRNVaH2dplJgC7IQSYJ EIEJw6xadreu683Lp09vb28nWtXLSVmtnuKHp1OdjuUCFlgmsGToY4eG7ZjJfC3T8la8BjtO6rLS 6vcxYIjMZF3n2YCynJSbbaVX6xq1VYNsO54k/itcu3OyS5x7q5mXCQy4FTvTo6OjMTqrXVjnYzDg K7whrOOVMqq6UemkO1D8anN5bAXXZ/4Y9LiicSOnFoUsgWPBpIwwTbJGleCL3P3oeUil0NpQ0fnn HIQrV/hdpcD1Ah30EIncyIXOdDyaIwQkylRVbC2psn+AaqpvCSjjSvWc7aTjKL1zaOoM/I9hF2sU 66Pz0DCDWwVClYZYqrpe3lGBH3Xk83vrHr0TEhD9lw1Y4t6A9flSwtymX4DUPw/Q4NcJSCOBdxZA KzLFr26Yi9/jD+EvIHkDZCg4NGgOumCx9aTaMrevaosuFsT55Pzj/PrJiP8VHy7o89Xpf3w8uzp9 jZ/nvx6/f+8/eCr2yvmvFx/fvw6fAoWTi/Pz0w+viQhQP/7PJxwmHIEnF5fXgFuO3z/p84zuGjQH zFyjdW0q8q2w4qkyCUQInqe3pzcn49l0eiQ+z764ZW7P+louMoVahCtAUu9JZTpBS67KtKHwOvn+ 18zTmiH0TL5ieCvSh28ceAWcsz+xYBoMCszx4Vt7r0DrYCI+Qnw5kUaZh+8begVazyZeqa01f+/r WazPzyZT8ZqdhjeT76DcoTUDCPMDaB1OxFtVqAqibOxmHibhX4cxX4cwxyuFER408fQbRDz0r5dV WUPykT1ItkNrJs4lWAf836dFQWlVgZ9+HK19cXxTAhh63WwyihtA69EMdmgdiNPlUkMoLJK7Rr/7 9dzTeh70q+80HyY0iWkROZR9pskR3EBkAhDfQMJnv0nhA3x7J8MdWjOwIR8J2SdtHu01OrT2kS8O 1YT8c5VqCVHPmEcQ7NA66NAyelUAyn2c23jRpvVMvNIp4S4gBxYQIukjXh1ah6BN4HeNZpE9fH/8 6tB6Lj4itjGcQ503Wc1/zZvNw9x1aL1g9FZuwMbtapLcGENv7lf8Dq0jcQ3IPts+qEtDr0DrxQQz vAZtF1XfgO+vuPbwMBV+HXlaRxNxnHwtyttMpavvdV30CrSuXObxOyNHTOu4qddl9S9GHKcp5iLf TRNy314A5w+dMN6/7P/x8u/Ay/wxev8BiHn2RyPmFgpr/QzafH0pPh9+wRQcheIsnQS3LjEHpILR OkQG/KlS6AfByj0dctYTIHdyOeIVL/ONLFCP3Oo52iOs5ZS3sEBlTuSp2uAJlYXGBBcUyFZjOA54 ZyKOC1CZNVaIUhpPLJVKFzBBYRLI+wNPqoCQRtopVohedOLUC7WLikmpEmuNooQvmGtI9mHZizQu +VgNRagNHpZQC+S5VFDISrRasQalWihVtHE5CDZoz1znOpMVzDprOE25BfNxbHD9xWxUogEzWIxr J2Qt0BGSqfh1Mjucis/7X+jTvvh88IWDwOXp2/GB+PwsroGdcAEj29LCwJCw1kUpTA13yCoNa244 cHCVyq6R9GRWIP5CyI0FRmjY95gohw9p70LxJZOWUgr/qQPs+57KTmBQKCB3K4zZl5GTxj58JFFM R2I2OvCEQC58zQHpPBZQeGmtR9ropG7QalsFpmUlYbgRV+YcKQwmVFcC7amkvQZLUJCipUAGFzS+ L74+KorxNRNKRbsjugIP6ywqVKo2Ct5wLZ1xBN9HkTqm1+UECJhagfYkskIzLoAKknAUUr10DGgu wgb8hEYBAAiXvCwUzjMvQZN2aEJW7D6wFIX6Jj6QQpKwd/tTw9/qdcNzJE6iiTpCmqcYM1MRqrtR zl57hEG3SdQD1a03TYUyIsa76w1fFSVpGKfXUtyuS4DDi4ZzcEdjI6taIyds4CbHsvQiK5OvOJUM 4IXIZVKVi5K/2zl/tUuTVeQ6z1+FyaHkUg2MNHDfloeewBXMTVmtwHv+ZoepAVYrKk9jzCag7ugY uAiQEtqCuwzvZ2ZGeLfTmkQ5pekYmvMEI2EyCviwvLxPBde/shN5W74yu92iAqqZc46welSbpyIs 2pQzfivlAaMSUdS12opry78x2wYRBBbUyW4QfmflChykq7OjVXWmU0IGkuvfLIjhkEAuDUWebzIK nvyrN6j2xOg9rhH0lemaEUZiybDTp8oThQjDyAMjdx+8RGT8B4Brx/5umGySNSnZCUVoC630N5Az BtbS4IRzhPybLA54rMB8uSmbKiGzhxWBRApuyVT3mhpCeT4RpzIKMBTYZYsK4QOqQ8kU77bm52Ej coSiGLU8CrLOTBcQookCoi5FKYvnpKsUy6rMW2RajNAuhY+TuOvitNrpWaqWurA7EEVLx8j0WceH 9ohmiC3Yjz5qJUipIC9UoLRBRfyquPmF21jahmfo8bNir5JowEvxJgei4W0hc52QgzAqA3UzPCee saPnKoTEKnkM7QlF7z8Aq+7/hOouoPgNuF0Um1NP3G+zLrRQty1pWrmgryOwSCvjSN3qLAsqd7em AZO4Ped0HUJShS6tkxXYtUbTA6+xKR1wRKtAlwwfOYTx2mmzyWQ7xNqpOc7zErQNRHG7VpwmGQi2 YIhlAnmvjeKxwkWlXs5wEoC4lS55nqYuNz2kTu7e4qcg0Vb9Wdd8/62ETw7t3ykqK6OFWqIx6ZB8 Me/KQmmwDL5ywr921nj/XlMbwppI0XsRPyaVdQIYoFV0AUn6ladkhmCqLoYDYCVrtdpCiKK9VlpI kmEPKKAaATB2UEvgjZ4OogWCSwtVI8pzHulvEOIp9UV6CZfdpA3alkfe/PWEFBormDIGvwJVxssf NA9FVg0AnIMH/FdPnpy1JDgPeRvDHBDYBhIqSKBtfkPh1plFjfpY65XknVZIlhUgx6QOcwlZw0Mm ZxcLo1/3UlLKsERWuc0GJgBrTghSQeDBojTuHMsVz4wDLxlpVZVVcKi6wOynqBmg5DnBTtoqirCH i2hxpjEg6mf3628vSnjj0JGHb3sDCtKRd7PW0/UBJBVE8lUT7YLe5Z0gBuZKcr+EHAYksT1hJMft e+tGrBg6boRXhxE8WKl3G8y9I8U8d9YUS9lF0spHW5P7HgXqiop1NKdqQY2lJy9zL6TS3+ike4GE 21+GiM5CZRfSDwVttnBwyeEZ1nh054K0lBo8Sg2hP0g6ihvkhyxj1o9EmAW1Iscdj4UqAO7UvEYQ EnJVr0tKYUpI5k0XqrXDIxrVBgfiH6nklWuqt7tFj+TSFLXO0OOnoCFJa5Hwqo5ERpzsBvOYjbjI JOs7+UlLZSgPW0tO8VJsn7pRHJIWaqWLwipkL5jbmqDXZPB3BtG+Xm5749XYwkMZrSZo5aICWzGE Yx2j4XWAlugwPb7r5p7d5OjwO31EDPb8CvVBn1XPNoJ3OMSggYJfiY26hS7JbKl9JCqBIdm1Xq1R 0RewwBTUQHuMtrDGkaImrJgciCpD0FVgxkUu0zozVKWK9s/QyMCZy21c5YN0Q6sb1nFNWbsDHlYg JZZvIQO12z+2nhTsyBFqjDMU17nkJ4CNMRvbikQCdneTEBZtZIZih9zGab81I4oO9kpiLDLBV5Fr 9VWvUDoTS3yzvjbGpqiZ5DiDF0gb64V6c6D1BAZaeBOvRAxiahvHggGpooTFkDW2Yi1puby6WEUB pTSPpMCYyYi0ISUIPPwV/iE7rESmJC7jEPjGicr0r41hg89ARZh/tq9AjmxVcTwBMBFptCOVS4TF zh8RpYGM/QfkNwc/Ib+5DlpO8bNssjRKUnCGXT0YWZlFDk4hqOQVMKR3RVeDxqRBhVqVNUZEahCz 5hT5FzCykQ3fPqu2O6+0DiMX6QNis1aEyxZFMiyas5XixRALkT/PBhdg+CZbZ+6n4PTe66foXHVf g0RH0lNbWX5TKfWburROPNDzn7AH0UIqE0WLaLfgXmTkNd4iJL47AAPTLAyuLxVuXV4IwuCISha6 qWP3SNEowLMKogBGD/wa8M9vcVGtQN0xTY4FzCqXAVy0QAUgXOOqXpOoF5UponQ8RTeYn5TlA3QP Xb+bM1XdXcXdl3pxwb2jmStFkS84BPjjGStbIdQ3iSJFemvwlFTNd2Pl1Fi4oNvTLvy+r6ulq1Gk A7Qcb6SpP1LPal8PHlADl1B21YC+/w41gPtpH4qCE7c792Bk3aKkZJVpymDJYpoCewa46nojs8Yn PCS86JqAM1oaZfly83FZjs9+raG76+SN1Fmr2Ox2vUCbuLhIthpvynC2YzeSnEpZDQvOgjWMYRd4 /KA0I0Hdd6g19iav+6XP9tcxKeeT2E7IEJzmRw7Gb9r7VB5L4/F+is8rUAMkdqsXXAi9jWM1XLCl +rot7o3oD7h0ZdujDFap7OaoEZmsVly3wTI9e2lHKmzPOJYmGBsaQs2usmMCHiWv2luRBSzarU5r ig28HYEX2t6qGCW7xSBQTAg0VVlUc3AlcpQyRgFJYsnKYqWqEF/q7QYhaii2NpV1Kh3fO+vZ3duL VztLXZkaPoxE0eQLVV0s4Q+z+3iXHNniRlW0eQymhG0v3JCOsx6q+uIwE+GGx7XHSohN8pgXv6WG FzCcdiR8szuaSMz5nYTox0EinSyuVjAFYsn2rdIWrY+jhrdClgC4yNi5MoZ7ywdfRp6QnqgJMDe4 a7OLlAVl/4VRSUNljsColxJtW/FtpIDSlnuC+z0vK04/vG/zHoQ3kAwnbtr2nSh2J5ADWTflCP0d m6kAWza0H471+CfYIC56X1NRLMM9S0oIeFee1jPS2oIWHERIko21kN5/ACp89pNQofL9gozeV2UF epCbKMvp21QMCjmVSMUKnGkdF5ajII75tc3065p3CyS5qyjtBINa45phcbCxwCPnZcQIqArDocez 6ALXUlZjFdWWbfZhy1Y4dKHwuAL4NhgOfi1XBXtG7r1oAAfBvCQWD7xyF3RAZbjgSfju2tYB51wb vK5kqi6Wyx308N92f1+gt/Vi/B3JjcvlEsu6tyqOBq7+SCDPFiYxNnKHB3ZgAQMwFwxLdM4GMD5H mgscZH8aSJXelWALTFmXhS0FoJ82uuJGHMrS49pz5E3OQhTy6IRqapJ3KSma2dM7g06+ZVP3O/u2 7gJkF1fAzBUnMTvn8tsrTahi9xGydzrTlz6pXTcl7sBkdohxxgLzI2sJOj4RzBHyGDw2bY5751zQ bvJSTPf2cKynhlNarmzRtGhvv8OMq1o4MuhrEs62YpYYs7VpeRpYVGpHCs7t4LteeudvitI6WBVy wkOp3YDRHE5orfCEz3KLS4UzssIZWK5rripiUx/tAlNFgjokOOdzQCNaf3d5FDlao3SW4C7Rx8L2 /iQWemvRwQEFnIRBVSNWBIZXpd3SYf1qKU97jUJa1OEXjYa7Y/qb02FBg9bfkdne0UXfvmQq7muN H/Bl1+Q648K+FT+s1ZpqC6BZvptRpTaYYHEmg3mnwesrN1w4H+p7wzCSILT1ZUFW6XClIxK6yXhw LobRvhmVCRsWX0Y4eWWzJ1QA45p9PTuZ7XFvC2gmHtXvP+B40E2o2kXSaAmQBXea9LlrX4wl6nXG TzdX6KO0yYU7LiQWIM2vQYi+aRqtmMOoI4PNirfYekdNkrVtBsc7QLB5vzfhsecSBrWO338ACjr8 SSioq8xO0OFcFbg8FoMtiTSF7c2P1x3WtL8WEx5iWSbNQIsOoqNoC6tNF8GLtG3aVBQeXmmF/f3t 7tH+dQjv7aYDR0LaXPYF/qCYUYTyCgpz+AslCVRE6dB2TYOrSiYKSwxby1HUV4dY2mbo7fnHXmnE RQXFxxWwAh9vEHNtnTJRmVFjVk1bZuia7zCyrh3Hx2Me49WGbM+qBMCwrNwGGXQ9iO2+tBWCjMTq sDbWVpTPYa+BdKHRo3dCcmJPIBBgptoK0BpbPx1Yg8sKXieQFyRUxoQdDEcKk7W7PDZFH/ut8R2Z dfssTNRrxGhOrgDwrwgMlJwN3SU6FFyhslb/x0avVlt0SdYZu7hOe5l+R9aqa4V+G2btD8QM+Jp7 Tyy1L3zUWaS7tMOW/CgFsEU9rvTS9O7LDIIew4VxgoQtiqHDNN7CiQHOKEJQnpRVdQJG3cNUw27O jjhcnhwNpnqg6Nto3zVU7CERX7rejjLqm492Diw3NuWLoa9n2OZ9gFMIVfsScbejiNUxSjwjGuTU 0OHQVhd6zfggyBLPbnu6btdjHaV71EZv5DI6QYT+tonafzChqlSPTOTihuRBeeUOl0ogA1GV+7G3 l7zbzql5A63lvu4++TaA0E7abRfhNvSWCjsvrTumrIGRdoBujko4WUBFKI//effGVdMZ3M1fX8LE YE5PwfBvVTVq9S8sSjwRR0tk7AYCZ+mmm0vYHOIBpEdlq6FjIvC3UT04Sv3w0cSsEivuWlh2B++4 lntPCQbZt0zN8+TcX+n7oIeccI5blhGDUVLn63LtYXVw2tg1TI7Ue2FHxiuAZQLCTocMNZHYwVwE rW9Ld0fQyaFlAvokXdpZR+PADZumwiaQiTgOQTrjtlhvKcRBl7fEaZ9fW9/20A5Ff8w27POfADXP 7Fn7xO2sWRlkIXe34iWEjw22uFXAmhrhMjLgQU0aSL7blvQ4dbRmsywpk/JKie0tdKAIQtua2wJk 3XbQg+oZCQB0YnzHkc9Q0sXFb3PWi8u8Xcc5DparbjQbqE2WtYlxYMePHoi7juoOS+8uZOO9kV+t sL3T3aALQ7R9mO868SIMS2jZvfMwcJ/bc7eAFpKXlV5hZwUaFAomeN3oZKL0jtmRoWMydUtvAgAm V8Up9kKPY8b8yay4xm856ipm71xyfzInQ7opzBby8G9RsLLpgm0bUtLouJnJny+jYwTaxV/Mubpa 38uBHzzvPBB479MXUhPazKTibSIzZbOXQaRNxoX6Tb0P47occxNEwywNHSf4I0afz8/Fzpz78eYO /HlR8FGjNasR7wVGPTRlylvP9LApe27ou5j2NXybBotj5Oa42ArLkdf8wFBnQn43035vj6i481ec pzky3B5R45Yr90nGDYptTP3oE+zxTQ9Mt+1R2Mh0z2c6SgEZlL6rihAspqZg8meXY27pdjtn8VFr R8SzOYpON+7P9kf0z4Hts4BP5x0v2jtz319ZPEJBJ25t36A73U3WaCdT+ybQbmnAUfFZS7xt5LaL wNFjdaSgfRDbqBbjwZC44D6Gb4vHdnbwHCBULAbYyiJvTkdbidiGFznbeB3p/QfAjhc/AXb04hQg +QwCA7rM1lFLG7No1warDzU1XHZ2P0KC1C5lt0a9+0kKfS351+uL1xf/Ft/df3bCgA1JepCBsc1s mf5K/l/6+xzCyu1xe4x/ks+jx4HZWgU1sIi1yqg5uaLzXKL1YKSJuKQ2VNoqttuILUtalVzCuSoL LU5vZDF44os/hCc6DFzRe7lfpkK8qmRaYHY1h5TyCcohPAPN46fLqsQdTzEew0D8+EKx/2QUj/Dq 5FIcjfDxTQKfYTgSF0ld4v789OjocMBJz7pD/7t/ihUGkYZ7a4AcieDM7StGGhuP/h7ShcwAR8jG 9MDyMZ0CR+eyAi8EXDzvM7EPCPL64/gayPK6puzL+Dg2Pvttf3cUTnaD5VDjFz4VFaTQRJ1qQgRv BHFuIybi8EB8pa2gaPb+08HdA+/TwC/igVGFcGTGSHX7xI7wOpe0djaj0Z6Js/nF07PTE5DNwdHh ePYSbHv69DhPJ1P8OAP5n0VHlGssIZZZudqKcV+PTnzHGElibEVRLv5Kfd5j0uvZS2Afv4dFwcGC PQtxKN4R8OD5XePWFxBjgWB4cMy+uwaGR+Lv/PhA/j1ipiM7vPMN7ZjZ6wubLxKWdMqMI/HoESVm xIERJrfjF2hi+wL/uyPF6Z44/nSyO/qfmFRvZjvvPl3v0vzszXiqn6dJA3w6OX07EnDROKLydu/Z nlNddMMDaxp9fC7eTcRFXQuFQBqMiZGwO7gJ1rvUFpzhwyZsEH/jHjkRUdyB658ef7rEJ4Lyg3Xx sYv0XN2qTjZj95iK8d4BPvUR+G7ArbEGRWTwmaK8ChPxF/vMyo17VuWANbwQ1xAxmypTda1JNicg 9EbXKpf4/DmchNxmpUwRAoCS0lzYSlnU0eBz14bHvmh/dqcv8p+OgJaYJ+sm+63SkM6iS8JT0+Sd ribiDUQnfPbGV+6e+jSBQJzgc0ILy93/xgwcR89K9pt6JHwlszEFw+NwjA29lne5iAmYUvT+A1DB 0c94oqF9hOuA5mzGkB+Np1PWGacRl1YjWqrzobxR1NfFTqOv9p1B6UP/GUT9G4+LFA9atx8jfc9D oWF8MQeNqH+DaWEx3f1wBbbzShagCx/eib3nz/dCB8zluizUS7HzfH+2K472D/FJhuFpUKf4NOaX qEHAyH/Rqv5S5GAR4MY607oAoCP4udJhXP906MDj4aH4VVaVNjUmHVdoIOHlrnqbKfwtYY4/zo9F l2Hx5+l4tjcdH744Gh/u7+91Wca8v/4FwjXH/ojhaJgPqsqx7m2fOu2/bz0/GnU9iWDM9Pme+AuW z68l3FZYUccvd+Ucfn1XGrDNk2Nx9Gy6fzCGmwFo0ITiK+2k/jwVB3svxItn++LF8+lBd05Ye4AP vyTIHs2IaTz+vzAmvf8jZmqfO7pHZvp/UEsBAhQAFAAAAAgAz4vnLjgkdEGtGwAAfl0AACIAAAAA AAAAAQAgALaBAAAAAGRyYWZ0LWJhc3NvLWF2dC12aWRlb2NvbnJlcS0wMC50eHRQSwUGAAAAAAEA AQBQAAAA7RsAAAAA --0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 7 18:51:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20546 for ; Mon, 7 Jul 2003 18:51:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zep4-0003TZ-6W for mmusic-archive@odin.ietf.org; Mon, 07 Jul 2003 18:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Mp2GS013357 for mmusic-archive@odin.ietf.org; Mon, 7 Jul 2003 18:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zep4-0003TM-1g for mmusic-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 18:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20516 for ; Mon, 7 Jul 2003 18:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zep0-0003tB-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 18:50:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zep0-0003t8-00 for mmusic-web-archive@ietf.org; Mon, 07 Jul 2003 18:50:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zep2-0003Sb-8t; Mon, 07 Jul 2003 18:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zep0-0003SO-Da for mmusic@optimus.ietf.org; Mon, 07 Jul 2003 18:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20513 for ; Mon, 7 Jul 2003 18:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zeox-0003t5-00 for mmusic@ietf.org; Mon, 07 Jul 2003 18:50:55 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Zeow-0003t2-00 for mmusic@ietf.org; Mon, 07 Jul 2003 18:50:54 -0400 Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h67MokYU021427; Tue, 8 Jul 2003 00:50:46 +0200 (MEST) Message-ID: <3F09F983.2050304@tzi.uni-bremen.de> Date: Tue, 08 Jul 2003 00:51:47 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org, csp@csperkins.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Draft MMUSIC Agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, attached is the draft MMUSIC agenda. Please let us know if there is anything we missed. Thanks, Joerg 57th IETF: Draft MMUSIC Agenda ============================== Thursday, 17 July 2003, 0900 - 1130, Hall IK -------------------------------------------- 0900 Agenda Bashing and Status Update (chairs, 15) Recent RFCs - draft-ietf-mmusic-reservation-flows-01.txt -> RFC 3524 Status Updates - draft-ietf-mmusic-sdp-new-13.txt - draft-ietf-mmusic-sdp4nat-05.txt - draft-ietf-mmusic-sdpng-trans-03.txt - draft-rajeshkumar-mmusic-gpmd-03.txt - draft-ietf-mmusic-sdp-bwparam-01.txt - draft-ietf-mmusic-srcfilter-03.txt - draft-ietf-mmusic-sdp-comedia-05.txt - draft-camarillo-mmusic-alt-01.txt 0915 SDP Security Descriptions for Media Streams (Wing, 10) - draft-ietf-mmusic-sdescriptions-01.txt 0925 SDP Offer Answer Examples (Johnston, 10) - draft-ietf-mmusic-offer-answer-examples-01.txt 0935 SDPng Update (Kutscher, 20) - draft-ietf-mmusic-sdpng-06.txt 0955 RTP DoS Attack (Rosenberg, 10) - draft-rosenberg-mmusic-rtp-denialofservice-00.txt 1010 RTSP Update (Westerlund, 15) - draft-ietf-mmusic-rfc2326bis-04.txt - draft-ietf-mmusic-rtsp-nat-01.txt 1030 Internet Media Guides (Manyfolks, 60) - draft-luoma-mmusic-img-metadata-01.txt - draft-luoma-mmusic-img-muppet-02.txt - draft-nomura-mmusic-img-framework-01.txt - draft-nomura-mmusic-img-requirements-00.txt - draft-nomura-mmusic-pguide-framework-00.txt - draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt 1130 Close Second (formal) meeting still to be scheduled for RTSP ------------------------------------------------------ Tentatively Wednesday night over dinner RTSP spec editing and bug fixing (Westerlund/Lanphier, 120) ----------------------------------------------------------------------------- NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 8 05:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15568 for ; Tue, 8 Jul 2003 05:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zodo-0007La-HK for mmusic-archive@odin.ietf.org; Tue, 08 Jul 2003 05:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h689K4GP028236 for mmusic-archive@odin.ietf.org; Tue, 8 Jul 2003 05:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zodo-0007LL-Ce for mmusic-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 05:20:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15555 for ; Tue, 8 Jul 2003 05:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zodl-00009V-00 for mmusic-web-archive@ietf.org; Tue, 08 Jul 2003 05:20:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zodk-00009R-00 for mmusic-web-archive@ietf.org; Tue, 08 Jul 2003 05:20:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zodm-0007Kr-CF; Tue, 08 Jul 2003 05:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZodQ-0007KD-Rd for mmusic@optimus.ietf.org; Tue, 08 Jul 2003 05:19:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15541; Tue, 8 Jul 2003 05:19:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZodN-00009B-00; Tue, 08 Jul 2003 05:19:37 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ZodM-000098-00; Tue, 08 Jul 2003 05:19:36 -0400 Received: from rubin.informatik.uni-bremen.de (rubin.informatik.uni-bremen.de [134.102.224.59]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h689JRZj019823; Tue, 8 Jul 2003 11:19:27 +0200 (MEST) From: Joerg Ott Received: (from jo@localhost) by rubin.informatik.uni-bremen.de (8.11.6/8.8.7) id h689JPR29408; Tue, 8 Jul 2003 11:19:25 +0200 Message-Id: <200307080919.h689JPR29408@rubin.informatik.uni-bremen.de> To: agenda@ietf.org Date: Tue, 8 Jul 2003 11:19:25 +0200 (MEST) Cc: mmusic@ietf.org, csp@csperkins.org, jo@informatik.uni-bremen.de (Joerg Ott) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] 57th IETF: MMUSIC Agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The MMUSIC Agenda for the 57th IETF is now available at http://www.dmn.tzi.org/ietf/mmusic/57/agenda.txt http://www.dmn.tzi.org/ietf/mmusic/57/agenda.html There have been few changes and version number updates compared to what we sent to the list yesterday. Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 8 16:42:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09417 for ; Tue, 8 Jul 2003 16:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzHp-0004P0-7E for mmusic-archive@odin.ietf.org; Tue, 08 Jul 2003 16:42:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Kg5MP016918 for mmusic-archive@odin.ietf.org; Tue, 8 Jul 2003 16:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzHp-0004On-35 for mmusic-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 16:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09392 for ; Tue, 8 Jul 2003 16:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZzHn-0006CC-00 for mmusic-web-archive@ietf.org; Tue, 08 Jul 2003 16:42:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZzHm-0006C9-00 for mmusic-web-archive@ietf.org; Tue, 08 Jul 2003 16:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzHl-0004Nv-50; Tue, 08 Jul 2003 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzGv-0004NP-P0 for mmusic@optimus.ietf.org; Tue, 08 Jul 2003 16:41:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09346; Tue, 8 Jul 2003 16:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZzGt-0006BT-00; Tue, 08 Jul 2003 16:41:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZzGs-0006Au-00; Tue, 08 Jul 2003 16:41:06 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68KePiB005887; Tue, 8 Jul 2003 16:40:30 -0400 (EDT) Message-ID: <3F0B2C34.6040709@dynamicsoft.com> Date: Tue, 08 Jul 2003 16:40:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "NAKAMURA, Hidefumi" CC: Magnus Westerlund , sip@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Appropriate usage of SIP and RTSP References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> <3F0930B4.8090202@ericsson.com> <20030707174715.1826.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> In-Reply-To: <20030707174715.1826.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that there is significant overlap between RTSP and SIP, and this is something that has been bothering more and more over time. I have had in mind to write a draft on the ways in which they could be better merged, but have not had the time. The primary place where they overlap is session establishment. In this area, I think SIP is much richer, in terms of features. SIP would allow connections to media servers running on PCs and other end-user devices. Its rich routing facilities could allow nice policy-based connection to content. It has had a lot of work on firewall/nat traversal which is now only getting repeated for RTSP. Plus, in many cases, you might initiate a session, but not know, in advance, that the session is to be connected to a content server. As an example, I'd like to be able to make a sip call to a user, and instead get connected to a voicemail greeting that I can control with RTSP. IMHO, the most obvious way to make this work is to use SIP to initiate a session. If the session is to a media server, then, using SDP negotiations, one can add an additional "media channel", which is actually RTSP, doing just media controls (play, fast-forward, etc.). Thus, SIP would set up an RTSP session to control the media that the SIP call connected to. I havent really fleshed this out much, but it seemed like a start. -Jonathan R. NAKAMURA, Hidefumi wrote: > Dear Magnus, > > Thank you for your quick response. > I wrote down my opinion after your comments. > > >>Hi, >> >>See comments inline: >> >>NAKAMURA, Hidefumi wrote: >> >>>Hi, all. >>> >>>I have a question about the relationship between SIP and RTSP. >>> >>>In RFC3261, there is a description that says >>> "SIP is not a vertically integrated communications system. SIP is >>> rather a component that can be used with other IETF protocols to >>> build a complete multimedia architecture. Typically, these >>> architectures will include protocols such as the Real-time Transport >>> Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and >>> providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC >>> 2326 [29]) for controlling delivery of streaming media, ..." >>> (RFC3261 Section 2) >>> >>>However, my understanding is that both SIP and RTSP have the capability >>>for "discovery of UAs or media streams." >>>If I use SIP to establish a stream session and use RTSP to control >>>the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and >>>SETUP-OK. >>> >>>Was there any discussion on how to use these two protocols appropriately? >> >>Not to my knowledge. The SIP and RTSP combination has not been explored, >>however it seem to contain a number of use cases. For example inviting a >>media server into a SIP session or a conference session. >> >>There are significant overlap in SIP and RTSP, mostly in regards to >>session establishment that are done i different ways. >> >>>With SIP application server, network providers can provide various >>>services on contents delivery while we will not be able to do so only >>>with RTSP, I think. On the other hand, RTSP has enough capability for >>>discovery of media streams and for negotiation of SDPs. >>>So, I think, for the simple delivery of contents, RTSP is appropriate to >>>use, and for various session control services regarding contents >>>delivery, SIP with RTSP is appropriate to use. >> >>What do you mean with "session control services regarding contents >>delivery"? > > > For example, if we establish a stream session via SIP application server > owned by the network provider, the application server can redirect the > session to the appropriate contents delivery server from the standpoint > of location, bandwidth prepared between terminals and the server, or > condition of contents server (i.e. in congestion, failure, and so on.) > Say, we get a media stream URI from a portal server. The terminal(or > set top box) requests a session initiation to the media stream URI to > the SIP application server. The SIP application server routes the > request to the contents delivery server that stores the media. However, > if the server is in congestion and returns 503, the SIP application > server can select and redirect the session to another contents delivery > server instead. > I do not think this is possible with only RTSP. > (though the interaction among the portal server, contents delivery > servers and the terminals might enable this type of service in some > extent.) > > >>>Any opinions? >>> >>>I wonder why no contents delivery server seems to prepare SIP stack now. >>>Is it because, up to now, there exists only a simple contents delivery >>>service? >> >>I believe that no one has looked into this and have had a need. > > > I understand. Thank you very much for your comments. > Maybe it is interesting to investigate the use case, anyway. > > >>Best Regards >> >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 8 18:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14312 for ; Tue, 8 Jul 2003 18:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a158-0004nE-Ie for mmusic-archive@odin.ietf.org; Tue, 08 Jul 2003 18:37:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Mb6E8018420 for mmusic-archive@odin.ietf.org; Tue, 8 Jul 2003 18:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a158-0004n1-Fb for mmusic-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 18:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14286 for ; Tue, 8 Jul 2003 18:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a155-0000EG-00 for mmusic-web-archive@ietf.org; Tue, 08 Jul 2003 18:37:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a155-0000ED-00 for mmusic-web-archive@ietf.org; Tue, 08 Jul 2003 18:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a153-0004kr-De; Tue, 08 Jul 2003 18:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a14z-0004kJ-Tn for mmusic@optimus.ietf.org; Tue, 08 Jul 2003 18:36:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14279 for ; Tue, 8 Jul 2003 18:36:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a14x-0000Dy-00 for mmusic@ietf.org; Tue, 08 Jul 2003 18:36:55 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19a14w-0000DZ-00 for mmusic@ietf.org; Tue, 08 Jul 2003 18:36:54 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2003 15:39:08 -0700 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.9/8.12.6) with ESMTP id h68MaLrm001325; Tue, 8 Jul 2003 15:36:22 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn4-820.cisco.com [10.21.83.51]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AIX58366; Tue, 8 Jul 2003 15:27:20 -0700 (PDT) From: "Dan Wing" To: Cc: "Flemming Andreasen" , "Mark Baugher" Date: Tue, 8 Jul 2003 15:36:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-ietf-mmusic-sdescriptions-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We revised sdescriptions . If you're unfamiliar with this I-D, the abstract is: This document defines a Session Description Protocol (SDP) cryptographic attribute for media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This document defines the Secure Real- time Transport Protocol (SRTP) parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. Significant changes from -00 to -01 are: * New syntax for a=crypto attribute parameter. This includes - removing the "grouping" which occured before (now everything for one crypto suite is on one line); - a new key "use" attribute (encrypt, decrypt, both); - created SRC tuple for SSRC, SEQ, and ROC in the SRTP session parameter (which also allows specifying multiples of each), the syntax is "SRC=(ssrc,seq,roc)"; - removed application=srtp|srtcp; - other smaller ABNF changes and bugfixes. * Please see the Open Issues section (8.0). * Revisions to Offer / Answer (specifically section 5.2 [answerer processing, 5.4 [non-RTP/SAVP answerers, and 5.8 [keymgt]). Offer / Answer still needs further refinement. I will be presenting these changes during the MMUSIC meeting in Vienna. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 9 03:10:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20999 for ; Wed, 9 Jul 2003 03:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95e-0000BJ-KF for mmusic-archive@odin.ietf.org; Wed, 09 Jul 2003 03:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697AA4G000690 for mmusic-archive@odin.ietf.org; Wed, 9 Jul 2003 03:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95e-0000B3-B4 for mmusic-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:10:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20969 for ; Wed, 9 Jul 2003 03:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a95a-0004EQ-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 03:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a95Z-0004EN-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 03:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95Z-0000AZ-58; Wed, 09 Jul 2003 03:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95O-000097-F9 for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 03:09:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20966 for ; Wed, 9 Jul 2003 03:09:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a95K-0004EK-00 for mmusic@ietf.org; Wed, 09 Jul 2003 03:09:50 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19a95J-0004EG-00 for mmusic@ietf.org; Wed, 09 Jul 2003 03:09:49 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA06418; Wed, 9 Jul 2003 09:09:37 +0200 (MET DST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id JAA14207; Wed, 9 Jul 2003 09:05:10 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 09:05:42 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB701620F18@mchh2a8e.mchh.siemens.de> From: Euchner Martin To: Euchner Martin , "'mmusic@ietf.org'" Cc: "'Fredrik.Lindholm@era.ericsson.se'" Date: Wed, 9 Jul 2003 09:05:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C345E8.8204D5B0" Subject: [MMUSIC] FW: draft-ietf-mmusic-kmgmt-ext-07.txt: RFC 3548 on The Base16, B ase32, and Base64 Data Encodings Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C345E8.8204D5B0 Content-Type: text/plain; charset="ISO-8859-1" RFC 3548 should be considered as a proper reference to Base 64 encoding procedure. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] Sent: Wednesday, July 09, 2003 1:36 AM Cc: rfc-editor@rfc-editor.org Subject: RFC 3548 on The Base16, Base32, and Base64 Data Encodings <> A new Request for Comments is now available in online RFC libraries. RFC 3548 Title: The Base16, Base32, and Base64 Data Encodings Author(s): S. Josefsson, Ed. Status: Informational Date: July 2003 Mailbox: simon@josefsson.org Pages: 13 Characters: 26363 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-josefsson-base-encoding-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3548.txt This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ------_=_NextPart_000_01C345E8.8204D5B0 Content-Type: message/rfc822 Content-Description: Unbenannte Anlage To: Subject: Date: Wed, 9 Jul 2003 09:05:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C345E8.8204D5B0" ------_=_NextPart_002_01C345E8.8204D5B0 Content-Type: text/plain ------_=_NextPart_002_01C345E8.8204D5B0 Content-Type: application/octet-stream; name="ATT30293" Content-Disposition: attachment; filename="ATT30293" Content-type: message/external-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030708163442.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3548 ------_=_NextPart_002_01C345E8.8204D5B0 Content-Type: message/external-body; site="in-notes"; dir="rfc3548.txt"; mode="ftp.isi.edu"; access-type="anon-ftp" ------_=_NextPart_002_01C345E8.8204D5B0-- ------_=_NextPart_000_01C345E8.8204D5B0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 9 04:07:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23310 for ; Wed, 9 Jul 2003 04:07:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9yj-0007OX-GT for mmusic-archive@odin.ietf.org; Wed, 09 Jul 2003 04:07:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69875vw028423 for mmusic-archive@odin.ietf.org; Wed, 9 Jul 2003 04:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9yi-0007OM-JD for mmusic-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 04:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23304 for ; Wed, 9 Jul 2003 04:07:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9yf-0004wE-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 04:07:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a9yf-0004wB-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 04:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9yg-0007NC-LT; Wed, 09 Jul 2003 04:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9yS-0007Me-4P for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 04:06:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23295 for ; Wed, 9 Jul 2003 04:06:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9yP-0004vv-00 for mmusic@ietf.org; Wed, 09 Jul 2003 04:06:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19a9yO-0004vs-00 for mmusic@ietf.org; Wed, 09 Jul 2003 04:06:44 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6986JiB006203; Wed, 9 Jul 2003 04:06:20 -0400 (EDT) Message-ID: <3F0BCCF5.1030508@dynamicsoft.com> Date: Wed, 09 Jul 2003 04:06:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTP denial of service References: <3F03EB89.3040808@piuha.net> In-Reply-To: <3F03EB89.3040808@piuha.net> 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 Thanks for your comments. Responses inline. Jari Arkko wrote: > > Jonathan, > > Thanks for bringing up this problem. I agree that the attack > exists, and I also agree that nothing in the RTP packets (such > as SRTP) can help prevent such attacks. I not expert enough > to say anything about suitability of RTCP or STUN. > > Attacks of a similar nature have been discussed in the context > of other protocols, for instance Mobile IPv6. The general > nature of such attacks is that a signaling protocol conveys > an address, and the lack of verification for this address > results in a vulnerability; attackers choose the address of > an innocent third party and start "bombing" this address > with packets. What makes these attacks bad is that the > attacker can initiate the attack with just few packets, > a legitimate entity in the network does all the hard work, > and the victim's link becomes congested. Right. I agree its the same attack as can be done in Mobile IP. > > The attack has always serious consequences due to its > amplification factor. In SIP, this factor is due to > the bandwidth difference in signaling vs. payload. In > Mobile IPv6, this factor was due to the ability to "open" > a connection, speed it up, and then move it towards the > victim. > > What also makes the attack hard is that the packets to > the victim never come from the attacker, they come from > another, legitimate entity in the network. This makes the > tracing of the attack hard: the attacker may be traceable > from that entity, but can we be sure that the administrator > of the entity can be reached for assistance? This may be > easy if the entity is owned by an operator, but what if > its my home server or someone's windows PC? However, > assuming you do get the help of the administrator, there > seems to be a few different levels of hardness > for tracing the attacker then: > > - No verification: The attack was initiated by a > packet sent to the entity, no assurance of the > authentication of the attacker or the validity > of the source address in the packet. > > SIP INVITE without TLS and authentication appears > to allow this, no? Yes. We do have a way for a server to prevent this level, though. SIP provides an anonymous digest authentication. Really, the only purpose of this is for the server to verify that the client can be reached at their advertised IP address. I should probably mention in the I-D that servers ought to do this. Generally its a good idea not to process packets that are completely unauthenticated... > > What makes this level tricky is that there are > designs where DoS attackers can be traced even > if they lie about their addresses, e.g. itrace. > However, these mechanisms only work for bulk > attacks, and here we only send a few signaling > packets. Right. Worse yet, the signaling can be relayed through proxies, which would mask the identity of the attacker from the entity, if no authentication is used. > > - Source address verification: The attack can only > be launched after some exchange of packets, where > the source address of the packet has been verified > to be valid. > > In SIP, anon Digest would allow you to do source > address verification. Similarly, even server-side > only authenticated TLS would suffice for this > check. Right, I see we are on the same page about anonymous digest here. > > Note: in Mobile IPv6, the address of the attacker > was conveyed also in the packets to the victim, > but this does not appear to be the case in SIP/RTP, > because the RTP packets don't contain the address > of the node that initiated the signaling. Right. > > - Authentication: the attacker's identity is > authenticated in some manner, you can probably > trace the attacker down to his postal address/passport/ > credit card. > > I believe we should strive for making the tracing > of the attack at least so hard that the attacker has > to give his IP address information, i.e., make the first > case not allowed. Agreed. > Still, tracing is a post-attack > activity, expensive and unreliable. So I believe you > are right in trying to prevent such attacks. > > A few words about prevention. Typically, a "return > routability test" approach is used, as I think you > are doing also for STUN. Right. Thats exactly why STUN works. I'm not expert enough in > STUN to know if it provides sufficient binding > between requests and responses so that off-path > attackers can't easily spoof responses? But I would > guess you have taken this into account. Yes. STUN has a transaction ID present in the request, which has to be mirrored in the resposne. An off-path attacker would need to be able to eavesdrop the stun request in order to generate a response. STUN itself has extensive security considerations, and we protected it as best as possible. > > Another issue is whether there needs to be a binding > between the signaling exchange and the STUN exchange, > e.g. a session identifier or something like that? Or > is it sufficient to rely on the right timing? What about > busy servers, wouldn't the timing of the attack be > more likely to succeed with them? Not sure I follow this. In ICE, the STUN exchange is correlated with the signaling exchange through the STUN username and password, which are conveyed in the SDP. Thus, when a UA receives a STUN request, it knows from the username and password the exact sip dialog and media stream its associated with. I'm not sure what this has to do with busy servers, though. > > Finally, the prevention mechanisms themselves may > be susceptible to an attack. An example: initiate > N sessions with different servers, all pointing to the > same victim node, who gets a lot of STUN queries. > This attack does not have amplification, but it > is hard to trace, harder than a direct dos packet > storm from a single source, and harder than than > a reflection attack. In some other cases, such > attacks have been made easier to trace by using > solely the source address of a packet in initiating > responses and protocol actions. But I understand > that this may not be an option here. Demanding > TlS/anon digest from all SIP signaling exchanges > does force the attacker to give up a lot of > information and some CPU cycles, so that may > be sufficient. I think so. There are many other ways to launch the no-amplification version you describe. For example, sip itself! Send a response with a Via header pointing to the target. Or a request with a Route header pointing to the target. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 9 05:17:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24993 for ; Wed, 9 Jul 2003 05:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4V-0002Sm-HM for mmusic-archive@odin.ietf.org; Wed, 09 Jul 2003 05:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h699H7F9009465 for mmusic-archive@odin.ietf.org; Wed, 9 Jul 2003 05:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4V-0002Sa-AJ for mmusic-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 05:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24975 for ; Wed, 9 Jul 2003 05:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aB4S-0005L5-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 05:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aB4R-0005L2-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 05:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4Q-0002Rd-G4; Wed, 09 Jul 2003 05:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4K-0002R1-5K for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 05:16:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24970; Wed, 9 Jul 2003 05:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aB4G-0005Kz-00; Wed, 09 Jul 2003 05:16:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aB4G-0005Kv-00; Wed, 09 Jul 2003 05:16:52 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h699GGiB006258; Wed, 9 Jul 2003 05:16:17 -0400 (EDT) Message-ID: <3F0BDD5A.9030406@dynamicsoft.com> Date: Wed, 09 Jul 2003 05:16:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paolo Asprino CC: "NAKAMURA, Hidefumi" , sip@ietf.org, mmusic@ietf.org References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> <000801c345ed$49699dd0$47a4cdc1@cori8> In-Reply-To: <000801c345ed$49699dd0$47a4cdc1@cori8> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paolo Asprino wrote: > Hi all > > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > In particular in the IMS, I think that to provide multilmedia > service (i.e video on demand), one can estabilish a subscription to the service by SIP and then activate the service with RTSP by DIGEST autentication with the > parameters exchanged early during the subscription (username and password) > > What do you think about that? I'm not sure I follow; it seems like you want SIP to be an enrollment protocol. I believe the right path forward is for SIP to setup the session. If you want to execute controls, it would be possible to open a control session (using an offer/answer exchange), where the control protocol is RTSP. In that usage you would only use the PLAY, PAUSE, RECORD, GET-PARAMTER and SET-PARAMETER methods. I think the others would not be needed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 9 11:13:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04400 for ; Wed, 9 Jul 2003 11:13:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdA-00019a-TE for mmusic-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDGYf004428 for mmusic-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdA-00019L-PE for mmusic-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:13:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04150 for ; Wed, 9 Jul 2003 11:13:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aGd9-0007H6-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aGd9-0007H2-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd4-00011z-BJ; Wed, 09 Jul 2003 11:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aERy-00064X-VL for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 08:53:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29146; Wed, 9 Jul 2003 08:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aERx-0006Oa-00; Wed, 09 Jul 2003 08:53:33 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19aERw-0006OX-00; Wed, 09 Jul 2003 08:53:32 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h69CrTGJ001262; Wed, 9 Jul 2003 14:53:29 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJCB70; Wed, 9 Jul 2003 14:53:29 +0200 Message-ID: <3F0C1049.4010103@ericsson.com> Date: Wed, 09 Jul 2003 14:53:29 +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: "Pianigiani, Jacopo (Jacopo)" CC: sip@ietf.org, mmusic@ietf.org References: <5160DD6EC1C0D41196D700508B5C167101F805EF@it2020exch001u.it.lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, When it comes to IMS and 3G terminals, most will already before having=20 an IMS functionality have support for PSS. PSS is Packet-based Streaming = Service which is an umbrella kind of standard for streaming service=20 defined in 3GPP targeted at low bit-rates and mobile networks.=20 Specification available from Rel 4 in TS 26.233 and TS 26.234. Already=20 today there exist GSM/GPRS phones that has a PSS client. So I think that dual stack implementations will not be that impossible=20 to foresee. However I think the main issue in this discussion is to look at what=20 applications that has need for SIP-RTSP interactions. Based on this we=20 can see if there is solutions easily available or not. I can agree with Rosenberg that if we where going to design a RTSP=20 functionality protocol today, looking at SIP for session establishment=20 would be interesting. However that opportunity has passed as RTSP has=20 started to be deployed in increasing numbers. I think even the latest=20 Windows media player does support RTSP. Best Regards Magnus Westerlund Pianigiani, Jacopo (Jacopo) wrote: > Hello all, > In my undertanding RTSP is suitable for broadcast, unicast or multicast= streams distribution. The RTSP protocol was ideated for typical content = delivery, and in effect for this application could be more than suitable.= But referring to an IMS domain, in my point of view adopting RSTP as med= ia streams control, would imply adopting at least a double protocol stack= in the terminal equipment. The IMS concept was mainly driven by the conc= ept - in my understanding - of simplifying the terminal (making it simple= r from a protocol stack implementation means lowering costs and increasin= g penetration on the market) by adopting a single protocol stack in the t= erminal, and having the RAN and the core evolving toward a unified transp= ort mechanism for which an almost unified level of control on the network= resources allocated to a session (whatever session we refer to, voice , = multimedia p-t-t call, web browsing, multimedia session with voice call a= nd dynamic web pages). > So in this sense, my understanding is that the RTSP could be suitable f= or media content, but it would imply again new complexity on the IMS UMTS= /CDMA terminal itself, which is against the idea of IMS of enhancing the = services the user can access by having an homogeneous protocol stack on t= he terminal itself for all types of services. >=20 > After all, the RTSP , apart from content delivery (of streams), could n= ot definitely handle appropriately sessions like Voice calls + Interactiv= e Web Pages.=20 > Regards >=20 > Jacopo Pianigiani > Lucent Technologies - Italy > =E839 335 7350536 >=20 > -----Original Message----- > From: Paolo Asprino [mailto:asprino@coritel.it] > Sent: Wednesday, July 09, 2003 9:40 AM > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > Subject: Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > Hi all >=20 > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > In particular in the IMS, I think that to provide multilmedia > service (i.e video on demand), one can estabilish a subscription to the= service by SIP and then activate the service with RTSP by DIGEST autenti= cation with the=20 > parameters exchanged early during the subscription (username and passwo= rd)=20 >=20 > What do you think about that? >=20 > Best Regards=20 >=20 > ----- Original Message -----=20 > From: "NAKAMURA, Hidefumi" > To: ; > Cc: > Sent: Monday, July 07, 2003 9:49 AM > Subject: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 >=20 >>Hi, all. >> >>I have a question about the relationship between SIP and RTSP.=20 >> >>In RFC3261, there is a description that says=20 >> "SIP is not a vertically integrated communications system. SIP is >> rather a component that can be used with other IETF protocols to >> build a complete multimedia architecture. Typically, these >> architectures will include protocols such as the Real-time Transport= >> Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and >> providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC= >> 2326 [29]) for controlling delivery of streaming media, ..." >> (RFC3261 Section 2) >> >>However, my understanding is that both SIP and RTSP have the capability= >>for "discovery of UAs or media streams." >>If I use SIP to establish a stream session and use RTSP to control >>the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and >>SETUP-OK. >> >>Was there any discussion on how to use these two protocols appropriatel= y? >> >>With SIP application server, network providers can provide various >>services on contents delivery while we will not be able to do so only >>with RTSP, I think. On the other hand, RTSP has enough capability for >>discovery of media streams and for negotiation of SDPs. >>So, I think, for the simple delivery of contents, RTSP is appropriate t= o >>use, and for various session control services regarding contents >>delivery, SIP with RTSP is appropriate to use. >> >>Any opinions? >> >>I wonder why no contents delivery server seems to prepare SIP stack now= =2E=20 >>Is it because, up to now, there exists only a simple contents delivery >>service? >> >>best regards, >> >>--=20 >>NAKAMURA, Hidefumi=20 >>NTT ServiceIntegration /NetworkServiceSystems Labs. >>tel: +81(422)59 3904; fax:+81(422)60 4012 >>--- >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >=20 >=20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.495 / Virus Database: 294 - Release Date: 30/06/2003J*fj)b= z b=B2=D8m=B6>?=FF=0C0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2= X=AC=B6+=1F=A2=B3DY=D7=AFzZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=AC= S~=A6=A6W=A6z{h=AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB=AD=E9=ED= =B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17s=A6(tm= )bq=ABb=A2z=1F >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 9 14:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12648 for ; Wed, 9 Jul 2003 14:12:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJQC-0000jB-Ae for mmusic-archive@odin.ietf.org; Wed, 09 Jul 2003 14:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69IC4Od002793 for mmusic-archive@odin.ietf.org; Wed, 9 Jul 2003 14:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJQC-0000iy-6G for mmusic-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 14:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12636 for ; Wed, 9 Jul 2003 14:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJQ9-0001R0-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 14:12:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aJQ9-0001Qx-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 14:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJQA-0000iS-1q; Wed, 09 Jul 2003 14:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJPN-0000gq-T5 for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 14:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12615; Wed, 9 Jul 2003 14:11:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJPL-0001Qh-00; Wed, 09 Jul 2003 14:11:11 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 19aJPK-0001QZ-00; Wed, 09 Jul 2003 14:11:10 -0400 content-class: urn:content-classes:message Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 9 Jul 2003 11:10:39 -0700 Message-ID: Thread-Topic: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Thread-Index: AcNGLV4de+FJnurnRWaKHIBOOZMeaQAEiCBA From: "Yutaka Takeda" To: , Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The applications that have need for SIP and RTSP features I can imagine are: - Voice&video mail (similar to 'sipum' but VM server is in the SIP = phone) - Personal broadcast station from my PC at home. - Watching video recorded with VCR at home or office from remote... What I am not sure is if RTSP has any solution or a framework for a RTSP server behind a NAT. If not, the solution is likely to be a repeat of what SIP provides. I thought TURN could be used in order for = signaling message to reach RTSP server behind a NAT, but I noticed that it is not=20 applicable (purposefully) for a server running behind a NAT because of a security consideration. Lots of issues for RTSP in this area alone? I believe a lot of people are interested in this discussion. Best regards, Yutaka > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, July 09, 2003 5:53 AM > To: Pianigiani, Jacopo (Jacopo) > Cc: sip@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > Hi, >=20 > When it comes to IMS and 3G terminals, most will already=20 > before having=20 > an IMS functionality have support for PSS. PSS is=20 > Packet-based Streaming=20 > Service which is an umbrella kind of standard for streaming service=20 > defined in 3GPP targeted at low bit-rates and mobile networks.=20 > Specification available from Rel 4 in TS 26.233 and TS=20 > 26.234. Already=20 > today there exist GSM/GPRS phones that has a PSS client. >=20 > So I think that dual stack implementations will not be that=20 > impossible=20 > to foresee. >=20 > However I think the main issue in this discussion is to look at what=20 > applications that has need for SIP-RTSP interactions. Based=20 > on this we=20 > can see if there is solutions easily available or not. >=20 > I can agree with Rosenberg that if we where going to design a RTSP=20 > functionality protocol today, looking at SIP for session=20 > establishment=20 > would be interesting. However that opportunity has passed as RTSP has=20 > started to be deployed in increasing numbers. I think even the latest=20 > Windows media player does support RTSP. >=20 >=20 > Best Regards >=20 > Magnus Westerlund >=20 >=20 > Pianigiani, Jacopo (Jacopo) wrote: > > Hello all, > > In my undertanding RTSP is suitable for broadcast, unicast=20 > or multicast streams distribution. The RTSP protocol was=20 > ideated for typical content delivery, and in effect for this=20 > application could be more than suitable. But referring to an=20 > IMS domain, in my point of view adopting RSTP as media=20 > streams control, would imply adopting at least a double=20 > protocol stack in the terminal equipment. The IMS concept was=20 > mainly driven by the concept - in my understanding - of=20 > simplifying the terminal (making it simpler from a protocol=20 > stack implementation means lowering costs and increasing=20 > penetration on the market) by adopting a single protocol=20 > stack in the terminal, and having the RAN and the core=20 > evolving toward a unified transport mechanism for which an=20 > almost unified level of control on the network resources=20 > allocated to a session (whatever session we refer to, voice ,=20 > multimedia p-t-t call, web browsing, multimedia session with=20 > voice call and dynamic web pages). > > So in this sense, my understanding is that the RTSP could=20 > be suitable for media content, but it would imply again new=20 > complexity on the IMS UMTS/CDMA terminal itself, which is=20 > against the idea of IMS of enhancing the services the user=20 > can access by having an homogeneous protocol stack on the=20 > terminal itself for all types of services. > >=20 > > After all, the RTSP , apart from content delivery (of=20 > streams), could not definitely handle appropriately sessions=20 > like Voice calls + Interactive Web Pages.=20 > > Regards > >=20 > > Jacopo Pianigiani > > Lucent Technologies - Italy > > =E839 335 7350536 > >=20 > > -----Original Message----- > > From: Paolo Asprino [mailto:asprino@coritel.it] > > Sent: Wednesday, July 09, 2003 9:40 AM > > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > Subject: Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > > Hi all > >=20 > > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > > In particular in the IMS, I think that to provide multilmedia > > service (i.e video on demand), one can estabilish a=20 > subscription to the service by SIP and then activate the=20 > service with RTSP by DIGEST autentication with the=20 > > parameters exchanged early during the subscription=20 > (username and password)=20 > >=20 > > What do you think about that? > >=20 > > Best Regards=20 > >=20 > > ----- Original Message -----=20 > > From: "NAKAMURA, Hidefumi" > > To: ; > > Cc: > > Sent: Monday, July 07, 2003 9:49 AM > > Subject: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > >=20 > >>Hi, all. > >> > >>I have a question about the relationship between SIP and RTSP.=20 > >> > >>In RFC3261, there is a description that says=20 > >> "SIP is not a vertically integrated communications=20 > system. SIP is > >> rather a component that can be used with other IETF protocols to > >> build a complete multimedia architecture. Typically, these > >> architectures will include protocols such as the=20 > Real-time Transport > >> Protocol (RTP) (RFC 1889 [28]) for transporting=20 > real-time data and > >> providing QoS feedback, the Real-Time streaming protocol=20 > (RTSP) (RFC > >> 2326 [29]) for controlling delivery of streaming media, ..." > >> (RFC3261 Section 2) > >> > >>However, my understanding is that both SIP and RTSP have=20 > the capability > >>for "discovery of UAs or media streams." > >>If I use SIP to establish a stream session and use RTSP to control > >>the stream, there will be redundant sequences, i.e.=20 > INVITE-OK-ACK and > >>SETUP-OK. > >> > >>Was there any discussion on how to use these two protocols=20 > appropriately? > >> > >>With SIP application server, network providers can provide various > >>services on contents delivery while we will not be able to=20 > do so only > >>with RTSP, I think. On the other hand, RTSP has enough=20 > capability for > >>discovery of media streams and for negotiation of SDPs. > >>So, I think, for the simple delivery of contents, RTSP is=20 > appropriate to > >>use, and for various session control services regarding contents > >>delivery, SIP with RTSP is appropriate to use. > >> > >>Any opinions? > >> > >>I wonder why no contents delivery server seems to prepare=20 > SIP stack now.=20 > >>Is it because, up to now, there exists only a simple=20 > contents delivery > >>service? > >> > >>best regards, > >> > >>--=20 > >>NAKAMURA, Hidefumi=20 > >>NTT ServiceIntegration /NetworkServiceSystems Labs. > >>tel: +81(422)59 3904; fax:+81(422)60 4012 > >>--- > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > >=20 > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.495 / Virus Database: 294 - Release Date:=20 > 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> = 0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY= =D7=AF > = zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7,r?= n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > = =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17= s=A6(tm)bq=ABb=A2z=1F > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 9 14:42:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13529 for ; Wed, 9 Jul 2003 14:42:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJtK-00028L-NV for mmusic-archive@odin.ietf.org; Wed, 09 Jul 2003 14:42:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69IgA9P008195 for mmusic-archive@odin.ietf.org; Wed, 9 Jul 2003 14:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJtK-000286-J1 for mmusic-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 14:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13504 for ; Wed, 9 Jul 2003 14:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJtH-0001gP-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 14:42:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aJtH-0001gM-00 for mmusic-web-archive@ietf.org; Wed, 09 Jul 2003 14:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJtD-00027M-79; Wed, 09 Jul 2003 14:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJsq-00026a-Ae for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 14:41:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13489; Wed, 9 Jul 2003 14:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJsn-0001fz-00; Wed, 09 Jul 2003 14:41:37 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19aJsl-0001fl-00; Wed, 09 Jul 2003 14:41:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26636; Wed, 9 Jul 2003 14:41:00 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09953; Wed, 9 Jul 2003 14:41:01 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MQBM7>; Wed, 9 Jul 2003 14:41:01 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Yutaka Takeda'" , sip@ietf.org, mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Date: Wed, 9 Jul 2003 14:40:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id OAA26636 Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I've been thinking for a long time about what an appropriate mechanism to provide a voice/videomail client on a sipphone would be. It's really clear that you record and play messages with VCR like functionality. For that, you need start/stop/pause/ rewind/fast forward, and so I was thinking RTSP. On the other hand, you surely establish the session to the voicemail server with a sip call. Thus, I like the way Jonathan is thinking, but you also need message selection/creation/deletion functions, and for those I was thinking KPML, and then you wonder if you just use that as the signalling mechanism for the record/play, and I get confused. Brian > -----Original Message----- > From: Yutaka Takeda [mailto:takeday@kmerl.com] > Sent: Wednesday, July 09, 2003 2:11 PM > To: sip@ietf.org; mmusic@ietf.org > Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > The applications that have need for SIP and RTSP features I > can imagine are: >=20 > - Voice&video mail (similar to 'sipum' but VM server is in=20 > the SIP phone) > - Personal broadcast station from my PC at home. > - Watching video recorded with VCR at home or office from remote... >=20 > What I am not sure is if RTSP has any solution or a framework for a > RTSP server behind a NAT. If not, the solution is likely to=20 > be a repeat > of what SIP provides. I thought TURN could be used in order=20 > for signaling > message to reach RTSP server behind a NAT, but I noticed that=20 > it is not=20 > applicable (purposefully) for a server running behind a NAT because of > a security consideration. Lots of issues for RTSP in this area alone? >=20 > I believe a lot of people are interested in this discussion. >=20 > Best regards, > Yutaka >=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Wednesday, July 09, 2003 5:53 AM > > To: Pianigiani, Jacopo (Jacopo) > > Cc: sip@ietf.org; mmusic@ietf.org > > Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > > Hi, > >=20 > > When it comes to IMS and 3G terminals, most will already=20 > > before having=20 > > an IMS functionality have support for PSS. PSS is=20 > > Packet-based Streaming=20 > > Service which is an umbrella kind of standard for streaming service=20 > > defined in 3GPP targeted at low bit-rates and mobile networks.=20 > > Specification available from Rel 4 in TS 26.233 and TS=20 > > 26.234. Already=20 > > today there exist GSM/GPRS phones that has a PSS client. > >=20 > > So I think that dual stack implementations will not be that=20 > > impossible=20 > > to foresee. > >=20 > > However I think the main issue in this discussion is to=20 > look at what=20 > > applications that has need for SIP-RTSP interactions. Based=20 > > on this we=20 > > can see if there is solutions easily available or not. > >=20 > > I can agree with Rosenberg that if we where going to design a RTSP=20 > > functionality protocol today, looking at SIP for session=20 > > establishment=20 > > would be interesting. However that opportunity has passed=20 > as RTSP has=20 > > started to be deployed in increasing numbers. I think even=20 > the latest=20 > > Windows media player does support RTSP. > >=20 > >=20 > > Best Regards > >=20 > > Magnus Westerlund > >=20 > >=20 > > Pianigiani, Jacopo (Jacopo) wrote: > > > Hello all, > > > In my undertanding RTSP is suitable for broadcast, unicast=20 > > or multicast streams distribution. The RTSP protocol was=20 > > ideated for typical content delivery, and in effect for this=20 > > application could be more than suitable. But referring to an=20 > > IMS domain, in my point of view adopting RSTP as media=20 > > streams control, would imply adopting at least a double=20 > > protocol stack in the terminal equipment. The IMS concept was=20 > > mainly driven by the concept - in my understanding - of=20 > > simplifying the terminal (making it simpler from a protocol=20 > > stack implementation means lowering costs and increasing=20 > > penetration on the market) by adopting a single protocol=20 > > stack in the terminal, and having the RAN and the core=20 > > evolving toward a unified transport mechanism for which an=20 > > almost unified level of control on the network resources=20 > > allocated to a session (whatever session we refer to, voice ,=20 > > multimedia p-t-t call, web browsing, multimedia session with=20 > > voice call and dynamic web pages). > > > So in this sense, my understanding is that the RTSP could=20 > > be suitable for media content, but it would imply again new=20 > > complexity on the IMS UMTS/CDMA terminal itself, which is=20 > > against the idea of IMS of enhancing the services the user=20 > > can access by having an homogeneous protocol stack on the=20 > > terminal itself for all types of services. > > >=20 > > > After all, the RTSP , apart from content delivery (of=20 > > streams), could not definitely handle appropriately sessions=20 > > like Voice calls + Interactive Web Pages.=20 > > > Regards > > >=20 > > > Jacopo Pianigiani > > > Lucent Technologies - Italy > > > =E839 335 7350536 > > >=20 > > > -----Original Message----- > > > From: Paolo Asprino [mailto:asprino@coritel.it] > > > Sent: Wednesday, July 09, 2003 9:40 AM > > > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > > Subject: Re: [Sip] Appropriate usage of SIP and RTSP > > >=20 > > >=20 > > > Hi all > > >=20 > > > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > > > In particular in the IMS, I think that to provide multilmedia > > > service (i.e video on demand), one can estabilish a=20 > > subscription to the service by SIP and then activate the=20 > > service with RTSP by DIGEST autentication with the=20 > > > parameters exchanged early during the subscription=20 > > (username and password)=20 > > >=20 > > > What do you think about that? > > >=20 > > > Best Regards=20 > > >=20 > > > ----- Original Message -----=20 > > > From: "NAKAMURA, Hidefumi" > > > To: ; > > > Cc: > > > Sent: Monday, July 07, 2003 9:49 AM > > > Subject: [Sip] Appropriate usage of SIP and RTSP > > >=20 > > >=20 > > >=20 > > >>Hi, all. > > >> > > >>I have a question about the relationship between SIP and RTSP.=20 > > >> > > >>In RFC3261, there is a description that says=20 > > >> "SIP is not a vertically integrated communications=20 > > system. SIP is > > >> rather a component that can be used with other IETF=20 > protocols to > > >> build a complete multimedia architecture. Typically, these > > >> architectures will include protocols such as the=20 > > Real-time Transport > > >> Protocol (RTP) (RFC 1889 [28]) for transporting=20 > > real-time data and > > >> providing QoS feedback, the Real-Time streaming protocol=20 > > (RTSP) (RFC > > >> 2326 [29]) for controlling delivery of streaming media, ..." > > >> (RFC3261 Section 2) > > >> > > >>However, my understanding is that both SIP and RTSP have=20 > > the capability > > >>for "discovery of UAs or media streams." > > >>If I use SIP to establish a stream session and use RTSP to control > > >>the stream, there will be redundant sequences, i.e.=20 > > INVITE-OK-ACK and > > >>SETUP-OK. > > >> > > >>Was there any discussion on how to use these two protocols=20 > > appropriately? > > >> > > >>With SIP application server, network providers can provide various > > >>services on contents delivery while we will not be able to=20 > > do so only > > >>with RTSP, I think. On the other hand, RTSP has enough=20 > > capability for > > >>discovery of media streams and for negotiation of SDPs. > > >>So, I think, for the simple delivery of contents, RTSP is=20 > > appropriate to > > >>use, and for various session control services regarding contents > > >>delivery, SIP with RTSP is appropriate to use. > > >> > > >>Any opinions? > > >> > > >>I wonder why no contents delivery server seems to prepare=20 > > SIP stack now.=20 > > >>Is it because, up to now, there exists only a simple=20 > > contents delivery > > >>service? > > >> > > >>best regards, > > >> > > >>--=20 > > >>NAKAMURA, Hidefumi=20 > > >>NTT ServiceIntegration /NetworkServiceSystems Labs. > > >>tel: +81(422)59 3904; fax:+81(422)60 4012 > > >>--- > > >> > > >> > > >> > > >>_______________________________________________ > > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>This list is for NEW development of the core SIP Protocol > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > >>Use sipping@ietf.org for new developments on the=20 > application of sip > > >> > > >=20 > > >=20 > > >=20 > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.495 / Virus Database: 294 - Release Date:=20 > > 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> > 0=D6'=AD~S=E0=FEf=A2-f=A7=FE= X=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY=D7=AF > > zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7= ,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > > =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'= =B6=17s=A6(tm)bq=ABb=A2z=1F > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > >=20 > >=20 > >=20 > > --=20 > >=20 > > Magnus Westerlund > >=20 > > Multimedia Technologies, Ericsson Research EAB/TVA/A > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 03:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20980 for ; Thu, 10 Jul 2003 03:25:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVnd-0006Mp-J3 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 03:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A7P5R5024474 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 03:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVnd-0006Mf-D6 for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 03:25:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20957 for ; Thu, 10 Jul 2003 03:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVnb-00009X-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 03:25:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aVna-00009U-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 03:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVnY-0006Ks-W9; Thu, 10 Jul 2003 03:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVmq-0006Ju-Tv for mmusic@optimus.ietf.org; Thu, 10 Jul 2003 03:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20950; Thu, 10 Jul 2003 03:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVmo-00009K-00; Thu, 10 Jul 2003 03:24:14 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19aVmn-00009G-00; Thu, 10 Jul 2003 03:24:13 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6A7ODIi024452; Thu, 10 Jul 2003 09:24:13 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJHS49; Thu, 10 Jul 2003 09:24:13 +0200 Message-ID: <3F0D149A.70807@ericsson.com> Date: Thu, 10 Jul 2003 09:24:10 +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: avt@ietf.org, mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [AVT] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 remarks around the posting of these messages. First is the receipients list, its way to long. I would recommed that we drop it to only the mailing lists. I assume that all persons being directly addressed are in fact part at least one of the lists. The list is in fact so long that it get caugth in the mailing list software and needs approval for every mail. The second thing is the crosspostings. We should move to a single list, I propose AVT as it has the most subscribers while I know there is need to include both communities. Due to the crosspostings, if a person is not memeber of both list it will get caught in that lists filter and need manual approval by the chairs. If you need to inform some other list about a subject, the recommended way is to post to each list individually and state that any discussion will take place on one of these list. Third, don't post to avt-admin@ietf.org unless it has something to do with administrative matters regarding the mailing list. We chairs are members of the list and don't need to get a second copy through the avt-admin@ietf.org address. In fact before trimming this receipient list I should have received 4 copies of each mail. So please follow this recommendations any you will make us chairs life easier. Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 17:23:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22369 for ; Thu, 10 Jul 2003 17:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001oy-1k for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNBHA006999 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisg-0001oo-UU for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22342 for ; Thu, 10 Jul 2003 17:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aise-0007Se-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisd-0007S6-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisX-0001ls-J2; Thu, 10 Jul 2003 17:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAia-0000yo-KM for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 04:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24461; Wed, 9 Jul 2003 04:54:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aAiX-0005CL-00; Wed, 09 Jul 2003 04:54:25 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19aAiW-0005C3-00; Wed, 09 Jul 2003 04:54:24 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h698rpw26363; Wed, 9 Jul 2003 03:53:51 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 10:53:49 +0200 Message-ID: <5160DD6EC1C0D41196D700508B5C167101F805EF@it2020exch001u.it.lucent.com> From: "Pianigiani, Jacopo (Jacopo)" To: "'Paolo Asprino'" , "NAKAMURA, Hidefumi" , sip@ietf.org, mmusic@ietf.org Date: Wed, 9 Jul 2003 10:53:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: [Sip] Appropriate usage of SIP and RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello all, In my undertanding RTSP is suitable for broadcast, unicast or multicast = streams distribution. The RTSP protocol was ideated for typical content = delivery, and in effect for this application could be more than = suitable. But referring to an IMS domain, in my point of view adopting = RSTP as media streams control, would imply adopting at least a double = protocol stack in the terminal equipment. The IMS concept was mainly = driven by the concept - in my understanding - of simplifying the = terminal (making it simpler from a protocol stack implementation means = lowering costs and increasing penetration on the market) by adopting a = single protocol stack in the terminal, and having the RAN and the core = evolving toward a unified transport mechanism for which an almost = unified level of control on the network resources allocated to a = session (whatever session we refer to, voice , multimedia p-t-t call, = web browsing, multimedia session with voice call and dynamic web = pages). So in this sense, my understanding is that the RTSP could be suitable = for media content, but it would imply again new complexity on the IMS = UMTS/CDMA terminal itself, which is against the idea of IMS of = enhancing the services the user can access by having an homogeneous = protocol stack on the terminal itself for all types of services. After all, the RTSP , apart from content delivery (of streams), could = not definitely handle appropriately sessions like Voice calls + = Interactive Web Pages.=20 Regards Jacopo Pianigiani Lucent Technologies - Italy =E839 335 7350536 -----Original Message----- From: Paolo Asprino [mailto:asprino@coritel.it] Sent: Wednesday, July 09, 2003 9:40 AM To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org Subject: Re: [Sip] Appropriate usage of SIP and RTSP Hi all I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. In particular in the IMS, I think that to provide multilmedia service (i.e video on demand), one can estabilish a subscription to the = service by SIP and then activate the service with RTSP by DIGEST = autentication with the=20 parameters exchanged early during the subscription (username and = password)=20 What do you think about that? Best Regards=20 ----- Original Message -----=20 From: "NAKAMURA, Hidefumi" To: ; Cc: Sent: Monday, July 07, 2003 9:49 AM Subject: [Sip] Appropriate usage of SIP and RTSP > Hi, all. >=20 > I have a question about the relationship between SIP and RTSP.=20 >=20 > In RFC3261, there is a description that says=20 > "SIP is not a vertically integrated communications system. SIP is > rather a component that can be used with other IETF protocols to > build a complete multimedia architecture. Typically, these > architectures will include protocols such as the Real-time = Transport > Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and > providing QoS feedback, the Real-Time streaming protocol (RTSP) = (RFC > 2326 [29]) for controlling delivery of streaming media, ..." > (RFC3261 Section 2) >=20 > However, my understanding is that both SIP and RTSP have the = capability > for "discovery of UAs or media streams." > If I use SIP to establish a stream session and use RTSP to control > the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and > SETUP-OK. >=20 > Was there any discussion on how to use these two protocols = appropriately? >=20 > With SIP application server, network providers can provide various > services on contents delivery while we will not be able to do so only > with RTSP, I think. On the other hand, RTSP has enough capability = for > discovery of media streams and for negotiation of SDPs. > So, I think, for the simple delivery of contents, RTSP is appropriate = to > use, and for various session control services regarding contents > delivery, SIP with RTSP is appropriate to use. >=20 > Any opinions? >=20 > I wonder why no contents delivery server seems to prepare SIP stack = now.=20 > Is it because, up to now, there exists only a simple contents = delivery > service? >=20 > best regards, >=20 > --=20 > NAKAMURA, Hidefumi=20 > NTT ServiceIntegration /NetworkServiceSystems Labs. > tel: +81(422)59 3904; fax:+81(422)60 4012 > --- >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.495 / Virus Database: 294 - Release Date: = 30/06/2003J*fj)bz = b=B2=D8m=B6>?=FF=0C0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2= X=AC=B6+=1F=A2=B3DY=D7=AFzZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=AC= S~=A6=A6W=A6z{h=AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB=AD=E9= =ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17s=A6= (tm)bq=ABb=A2z=1F _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 17:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22387 for ; Thu, 10 Jul 2003 17:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001q5-IV for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNBsA007063 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001pP-E7 for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22327 for ; Thu, 10 Jul 2003 17:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aisc-0007SI-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisa-0007Rx-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisX-0001li-7Q; Thu, 10 Jul 2003 17:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a7n6-0007up-2t for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 01:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22922; Wed, 9 Jul 2003 01:46:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a7n2-0003kJ-00; Wed, 09 Jul 2003 01:46:52 -0400 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 19a7n1-0003k8-00; Wed, 09 Jul 2003 01:46:51 -0400 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id <31W6KGSH>; Wed, 9 Jul 2003 08:46:24 +0300 Message-ID: From: "Even, Roni" To: "'Gary Sullivan'" , Andrea Basso , avt@ietf.org, avt-admin@ietf.org, mmusic@ietf.org Cc: casner@acm.org, jo@tzi.uni-bremen.de, magnus.westerlund@ericsson.com, csp@csperkins.org, Orit Levin , "Even, Roni" , nismail@cisco.com Date: Wed, 9 Jul 2003 08:46:19 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Subject: [MMUSIC] RE: [AVT] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Gary About "It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC." In case of a video switch in a multipoint conference there is a need to get a new recovery point since the decoder will receive a stream without a previous recovery point. The procedure in H.241 allows for either a full picture at once or gradual recovery based on an SEI recovery point message. Both method are fine as an encoder response to a fast update request. Regards Roni Even -----Original Message----- From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Wednesday, July 09, 2003 3:03 AM To: Andrea Basso; avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org Cc: casner@acm.org; jo@tzi.uni-bremen.de; magnus.westerlund@ericsson.com; csp@csperkins.org; Orit Levin; Roni Even; nismail@cisco.com Subject: RE: [AVT] Requirements draft on video control Much of the content of this ID will look familiar to those with experience with ITU-T systems control specifications (such as H.245). Some of it seems like it could use a bit of updating in that regard (e.g., videofastupdateGOB). Draft Recommendation H.241 is one good place to look for such information. Section 3 is a bit confused in its terminology. For example it seems to say that intra frames are also known as inter frames, which is definitely not the case. It mixes the terms "predictive" and "prediction" and seems to consider a "reference" frame to be synonymous with an intra frame. The terms "picture" and "frame" are also kind of mixed up. A more consistent terminology would be as follows: An intra picture is a picture that can be decoded without first decoding any other picture. A predicted (or non-intra) picture is a picture that may require data from one or more previously-decoded pictures in order to be properly decoded. A reference picture is a picture that is stored in the decoder for use as a reference in the decoding process of some subsequent picture in the bitstream. A non-reference picture is a picture that is not used as a reference for the decoding process of any other picture in the bitstream. The concepts of intra versus non-Intra and reference versus non-reference are independent. A particular picture can (in general) be any one of the four types (intra reference, non-intra reference, intra non-reference, non-intra non-reference). A "fast update", also known as an "instantaneous decoder refresh", involves sending an intra picture and thereafter refraining from using any picture sent prior to that intra picture as a reference for the decoding process of any subsequent picture sent in the stream. In particular it is worth noting that some concepts that applied to some older codecs are not really valid in general and should be avoided (e.g., that a non-reference picture is called a B picture or that an intra picture is the same thing as a fast update or that an intra picture is always a reference picture). The characterization of a "slice" or "GOB" as being a "stripe" is not really quite right. For example, a single slice in MPEG-1, H.263 Annex O, or MPEG-4 can consist of a few macroblocks at the right edge of one row and a few macroblocks at the left edge of the next row (i.e., two distinct rectangular regions quite far apart from each other in the picture can be in a single slice). A GOB in H.261 CIF consists of THREE partial rows of macroblocks extending only halfway across a picture. And in H.264/AVC, a slice can be ANY collection of macroblocks scattered around absolutely anywhere in the picture (by use of a feature known as a "slice group map"). In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known as MPEG-2 Video) also supports a freeze picture release within the ITU-T extension. It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC. Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On +> Behalf Of Andrea Basso +> Sent: Monday, July 07, 2003 2:34 PM +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit +> Levin; Roni Even; nismail@cisco.com +> Subject: [AVT] Requirements draft on video control +> +> +> Attached you will find draft-basso-avt-videoconreq-00.txt +> +> Abstract: +> +> A variety of communication services such as video +> conferencing and video messaging rely on the capability of video +> encoders and decoders to exchange control commands. This document +> outlines this set of commands as well as the requirements for +> their transport. +> +> Comments are more than welcome. +> +> +> +> +> +> Andrea Basso +> NMS Communications +> (732) 936-2118 +> (See attached file: draft-basso-avt-videoconreq-00.zip) +> _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 17:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22384 for ; Thu, 10 Jul 2003 17:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001pq-GA for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNBFC007039 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001p5-Ai for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22338 for ; Thu, 10 Jul 2003 17:23:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aisd-0007SO-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisa-0007Ry-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisY-0001mj-JJ; Thu, 10 Jul 2003 17:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLkA-00020W-2D for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 16:40:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20891; Wed, 9 Jul 2003 16:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLk7-000396-00; Wed, 09 Jul 2003 16:40:47 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 19aLk7-00038N-00; Wed, 09 Jul 2003 16:40:47 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Jul 2003 13:40:14 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Jul 2003 13:40:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jul 2003 13:40:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jul 2003 13:40:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 9 Jul 2003 13:40:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jul 2003 13:39:46 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A34750@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] Requirements draft on video control Thread-Index: AcNGTsrjAD4hxGGpTxa5o1h1z7W8RAABxXyg From: "Gary Sullivan" To: "Andrea Basso" Cc: , , , , , , , "Orit Levin" , "Roni Even" X-OriginalArrivalTime: 09 Jul 2003 20:40:12.0799 (UTC) FILETIME=[4BBA08F0:01C3465A] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: [AVT] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Andrea et al, Perhaps I was having some trouble understanding the purpose of this ID. I thought it was some sort of draft of a formal specification, rather than just an expression of needs to be taken as input by the group. So I criticized the language more heavily than necessary. In regard to the "intra frames" =3D "inter frames" mix-up: +> >intra frames are also known as inter frames, which is +> >definitely not the case +>=20 +> I do not think the text says this. Here is the sentence: +>=20 +> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 +> [5], H.264 [6] can encode video pictures as reference=20 +> frames, also +> known as intra frames or predicted frames, also known as inter +> frames. It seems like what we have is a scoping problem. To what set of words does the first "also known as" phrase apply? To me, when you said "A, also known as B or C, also known as D", I interpreted this as saying that A, B, C, and D are all synonyms (with the first "also known as" applying to the "B or C"). Apparently that's not what you meant. Also, the way the term "reference frame" is used in this document may have contributed to my confusion. As I noted in my original message, that term is used differently here than it is in some other video coding discussions. Best Regards, Gary Sullivan +> -----Original Message----- +> From: Andrea Basso [mailto:Andrea_Basso@nmss.com]=20 +> Sent: Wednesday, July 09, 2003 12:17 PM +> To: Gary Sullivan +> Cc: Andrea Basso; avt@ietf.org; casner@acm.org;=20 +> csp@csperkins.org; jo@tzi.uni-bremen.de;=20 +> magnus.westerlund@ericsson.com; mmusic@ietf.org;=20 +> nismail@cisco.com; Orit Levin; Roni Even +> Subject: RE: [AVT] Requirements draft on video control +>=20 +>=20 +>=20 +> Gary, +> here are some comments. +>=20 +>=20 +> > Some of it seems like it could use a bit of updating in that regard +> > (e.g., videofastupdateGOB). +> > Draft Recommendation H.241 is one good place to look for such +> > information. +>=20 +> H.241 is very focused on H.264 and in very early stages in addressing +> Commands and Indications applicable to all codecs. +> If you look at the H.241 draft section 6 says: +>=20 +>=20 +>=20 +> 6 Commands and Indications +>=20 +>=20 +>=20 +> 6.1 C&I applicable to all video codecs +>=20 +> For further study. +>=20 +>=20 +> We plan to monitor the evolution the H.241 and to update the=20 +> ID accordingly +> if needed. +>=20 +>=20 +> >intra frames are also known as inter frames, which is +> >definitely not the case +>=20 +> I do not think the text says this. Here is the sentence: +>=20 +> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 +> [5], H.264 [6] can encode video pictures as reference=20 +> frames, also +> known as intra frames or predicted frames, also known as inter +> frames. +>=20 +>=20 +> >The terms "picture" and "frame" are also kind of +> >mixed up. +>=20 +> For progressive video, a picture is identical to a frame.=20 +> The difference +> appears for interlaced video only. +> The new text will use the term 'picture' only. +>=20 +>=20 +> >The characterization of a "slice" or "GOB" as being a=20 +> "stripe" is not +> >really quite right. +>=20 +> The text does not say "image stripe" says "stripe" and in=20 +> particular it +> does not imply that such stripe goes border-to-border in the=20 +> image (i.e. +> can cover a partial macroblock row) nor that is should only include a +> single macroblock row (i.e., can cover multiple partial=20 +> rows as in H.261). +> Clarifications will be addressed in the new version of the draft. +>=20 +>=20 +> -A +>=20 +> Andrea Basso +> NMS Communications +> (732) 936-2118 +>=20 +>=20 +>=20 +> =20 +> =20 +> "Gary Sullivan" =20 +> =20 +> "Andrea Basso" , , =20 +> rosoft.com> =20 +> , =20 +> =20 +> cc: =20 +> , , =20 +> 07/08/2003 08:03 PM =20 +> , , "Orit=20 +> Levin" =20 +> =20 +> , "Roni Even" ,=20 +> =20 +> =20 +> =20 +> =20 +> Subject: =20 +> RE: [AVT] Requirements draft on video control =20 +> =20 +> =20 +>=20 +>=20 +>=20 +>=20 +>=20 +> Much of the content of this ID will look familiar to those with +> experience with ITU-T systems control specifications (such as H.245). +>=20 +> Some of it seems like it could use a bit of updating in that regard +> (e.g., videofastupdateGOB). +> Draft Recommendation H.241 is one good place to look for such +> information. +>=20 +> Section 3 is a bit confused in its terminology. For example=20 +> it seems to +> say that intra frames are also known as inter frames, which is +> definitely not the case. It mixes the terms "predictive" and +> "prediction" and seems to consider a "reference" frame to be=20 +> synonymous +> with an intra frame. The terms "picture" and "frame" are=20 +> also kind of +> mixed up. +>=20 +> A more consistent terminology would be as follows: +>=20 +> An intra picture is a picture that can be decoded without=20 +> first decoding +> any other picture. +>=20 +> A predicted (or non-intra) picture is a picture that may require data +> from one or more previously-decoded pictures in order to be properly +> decoded. +>=20 +> A reference picture is a picture that is stored in the=20 +> decoder for use +> as a reference in the decoding process of some subsequent=20 +> picture in the +> bitstream. +>=20 +> A non-reference picture is a picture that is not used as a=20 +> reference for +> the decoding process of any other picture in the bitstream. +>=20 +> The concepts of intra versus non-Intra and reference versus +> non-reference are independent. A particular picture can (in=20 +> general) be +> any one of the four types (intra reference, non-intra=20 +> reference, intra +> non-reference, non-intra non-reference). +>=20 +> A "fast update", also known as an "instantaneous decoder refresh", +> involves sending an intra picture and thereafter refraining=20 +> from using +> any picture sent prior to that intra picture as a reference for the +> decoding process of any subsequent picture sent in the stream. +>=20 +> In particular it is worth noting that some concepts that=20 +> applied to some +> older codecs are not really valid in general and should be avoided +> (e.g., that a non-reference picture is called a B picture or that an +> intra picture is the same thing as a fast update or that an intra +> picture is always a reference picture). +>=20 +> The characterization of a "slice" or "GOB" as being a "stripe" is not +> really quite right. For example, a single slice in MPEG-1,=20 +> H.263 Annex +> O, or MPEG-4 can consist of a few macroblocks at the right=20 +> edge of one +> row and a few macroblocks at the left edge of the next row (i.e., two +> distinct rectangular regions quite far apart from each other in the +> picture can be in a single slice). A GOB in H.261 CIF=20 +> consists of THREE +> partial rows of macroblocks extending only halfway across a picture. +> And in H.264/AVC, a slice can be ANY collection of=20 +> macroblocks scattered +> around absolutely anywhere in the picture (by use of a=20 +> feature known as +> a "slice group map"). +>=20 +> In regard to section 5.1 VideoFreezePicture, I believe H.262=20 +> (also known +> as MPEG-2 Video) also supports a freeze picture release=20 +> within the ITU-T +> extension. +>=20 +> It is also possible to obtain random access recovery without a fast +> update. This is sometimes called "gradual decoder refresh". See for +> example the recovery point SEI message in H.264/AVC. +>=20 +> Best Regards, +>=20 +> Gary Sullivan +>=20 +>=20 +> +> -----Original Message----- +> +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On +> +> Behalf Of Andrea Basso +> +> Sent: Monday, July 07, 2003 2:34 PM +> +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; +> +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit +> +> Levin; Roni Even; nismail@cisco.com +> +> Subject: [AVT] Requirements draft on video control +> +> +> +> +> +> Attached you will find draft-basso-avt-videoconreq-00.txt +> +> +> +> Abstract: +> +> +> +> A variety of communication services such as video +> +> conferencing and video messaging rely on the capability of video +> +> encoders and decoders to exchange control commands. This document +> +> outlines this set of commands as well as the requirements for +> +> their transport. +> +> +> +> Comments are more than welcome. +> +> +> +> +> +> +> +> +> +> +> +> Andrea Basso +> +> NMS Communications +> +> (732) 936-2118 +> +> (See attached file: draft-basso-avt-videoconreq-00.zip) +> +> +>=20 +>=20 +>=20 +>=20 +>=20 +>=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 17:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22391 for ; Thu, 10 Jul 2003 17:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisk-0001qX-DU for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNEn9007091 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisk-0001qI-9O for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22330 for ; Thu, 10 Jul 2003 17:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aisc-0007SH-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisa-0007Rw-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisY-0001mw-Tz; Thu, 10 Jul 2003 17:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOIa-0000By-S3 for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 19:24:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28806; Wed, 9 Jul 2003 19:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOIZ-0005BG-00; Wed, 09 Jul 2003 19:24:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19aOIY-0005AL-00; Wed, 09 Jul 2003 19:24:30 -0400 Received: from SCOTTF-W2K5.cisco.com (dhcp-128-107-141-78.cisco.com [128.107.141.78]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h69NNapq018857; Wed, 9 Jul 2003 16:23:37 -0700 (PDT) Message-Id: <4.3.1.2.20030709161949.02181180@mira-sjcm-3.cisco.com.> X-Sender: nismail@mira-sjcm-3.cisco.com. X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 09 Jul 2003 16:25:05 -0700 To: "Gary Sullivan" From: Nermeen Ismail Cc: "Andrea Basso" , , , , , , , "Orit Levin" , "Roni Even" In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE24602A34750@WIN-MSG-10.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] RE: [AVT] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Gary, Thanks for the comments. Definitely we need to add consistency in the terms we are using in the draft. >Andrea et al, > >Perhaps I was having some trouble understanding the purpose of this ID. >I thought it was some sort of draft of a formal specification, rather >than just an expression of needs to be taken as input by the group. So >I criticized the language more heavily than necessary. So now that this is clarified we need to discuss the requirements that are specified in that draft and see if people think that these are legitimate requirements that need to be addressed or not. nermeen >In regard to the "intra frames" = "inter frames" mix-up: > >+> >intra frames are also known as inter frames, which is >+> >definitely not the case >+> >+> I do not think the text says this. Here is the sentence: >+> >+> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 >+> [5], H.264 [6] can encode video pictures as reference >+> frames, also >+> known as intra frames or predicted frames, also known as inter >+> frames. > >It seems like what we have is a scoping problem. To what set of words >does the first "also known as" phrase apply? To me, when you said "A, >also known as B or C, also known as D", I interpreted this as saying >that A, B, C, and D are all synonyms (with the first "also known as" >applying to the "B or C"). Apparently that's not what you meant. > >Also, the way the term "reference frame" is used in this document may >have contributed to my confusion. As I noted in my original message, >that term is used differently here than it is in some other video coding >discussions. > >Best Regards, > >Gary Sullivan > > >+> -----Original Message----- >+> From: Andrea Basso [mailto:Andrea_Basso@nmss.com] >+> Sent: Wednesday, July 09, 2003 12:17 PM >+> To: Gary Sullivan >+> Cc: Andrea Basso; avt@ietf.org; casner@acm.org; >+> csp@csperkins.org; jo@tzi.uni-bremen.de; >+> magnus.westerlund@ericsson.com; mmusic@ietf.org; >+> nismail@cisco.com; Orit Levin; Roni Even >+> Subject: RE: [AVT] Requirements draft on video control >+> >+> >+> >+> Gary, >+> here are some comments. >+> >+> >+> > Some of it seems like it could use a bit of updating in that regard >+> > (e.g., videofastupdateGOB). >+> > Draft Recommendation H.241 is one good place to look for such >+> > information. >+> >+> H.241 is very focused on H.264 and in very early stages in addressing >+> Commands and Indications applicable to all codecs. >+> If you look at the H.241 draft section 6 says: >+> >+> >+> >+> 6 Commands and Indications >+> >+> >+> >+> 6.1 C&I applicable to all video codecs >+> >+> For further study. >+> >+> >+> We plan to monitor the evolution the H.241 and to update the >+> ID accordingly >+> if needed. >+> >+> >+> >intra frames are also known as inter frames, which is >+> >definitely not the case >+> >+> I do not think the text says this. Here is the sentence: >+> >+> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 >+> [5], H.264 [6] can encode video pictures as reference >+> frames, also >+> known as intra frames or predicted frames, also known as inter >+> frames. >+> >+> >+> >The terms "picture" and "frame" are also kind of >+> >mixed up. >+> >+> For progressive video, a picture is identical to a frame. >+> The difference >+> appears for interlaced video only. >+> The new text will use the term 'picture' only. >+> >+> >+> >The characterization of a "slice" or "GOB" as being a >+> "stripe" is not >+> >really quite right. >+> >+> The text does not say "image stripe" says "stripe" and in >+> particular it >+> does not imply that such stripe goes border-to-border in the >+> image (i.e. >+> can cover a partial macroblock row) nor that is should only include a >+> single macroblock row (i.e., can cover multiple partial >+> rows as in H.261). >+> Clarifications will be addressed in the new version of the draft. >+> >+> >+> -A >+> >+> Andrea Basso >+> NMS Communications >+> (732) 936-2118 >+> >+> >+> >+> >+> >+> "Gary Sullivan" >+> >+> +> "Andrea Basso" , , >+> rosoft.com> >+> , >+> >+> cc: >+> , , >+> 07/08/2003 08:03 PM >+> , , "Orit >+> Levin" >+> >+> , "Roni Even" , >+> >+> >+> >+> >+> Subject: >+> RE: [AVT] Requirements draft on video control >+> >+> >+> >+> >+> >+> >+> >+> Much of the content of this ID will look familiar to those with >+> experience with ITU-T systems control specifications (such as H.245). >+> >+> Some of it seems like it could use a bit of updating in that regard >+> (e.g., videofastupdateGOB). >+> Draft Recommendation H.241 is one good place to look for such >+> information. >+> >+> Section 3 is a bit confused in its terminology. For example >+> it seems to >+> say that intra frames are also known as inter frames, which is >+> definitely not the case. It mixes the terms "predictive" and >+> "prediction" and seems to consider a "reference" frame to be >+> synonymous >+> with an intra frame. The terms "picture" and "frame" are >+> also kind of >+> mixed up. >+> >+> A more consistent terminology would be as follows: >+> >+> An intra picture is a picture that can be decoded without >+> first decoding >+> any other picture. >+> >+> A predicted (or non-intra) picture is a picture that may require data >+> from one or more previously-decoded pictures in order to be properly >+> decoded. >+> >+> A reference picture is a picture that is stored in the >+> decoder for use >+> as a reference in the decoding process of some subsequent >+> picture in the >+> bitstream. >+> >+> A non-reference picture is a picture that is not used as a >+> reference for >+> the decoding process of any other picture in the bitstream. >+> >+> The concepts of intra versus non-Intra and reference versus >+> non-reference are independent. A particular picture can (in >+> general) be >+> any one of the four types (intra reference, non-intra >+> reference, intra >+> non-reference, non-intra non-reference). >+> >+> A "fast update", also known as an "instantaneous decoder refresh", >+> involves sending an intra picture and thereafter refraining >+> from using >+> any picture sent prior to that intra picture as a reference for the >+> decoding process of any subsequent picture sent in the stream. >+> >+> In particular it is worth noting that some concepts that >+> applied to some >+> older codecs are not really valid in general and should be avoided >+> (e.g., that a non-reference picture is called a B picture or that an >+> intra picture is the same thing as a fast update or that an intra >+> picture is always a reference picture). >+> >+> The characterization of a "slice" or "GOB" as being a "stripe" is not >+> really quite right. For example, a single slice in MPEG-1, >+> H.263 Annex >+> O, or MPEG-4 can consist of a few macroblocks at the right >+> edge of one >+> row and a few macroblocks at the left edge of the next row (i.e., two >+> distinct rectangular regions quite far apart from each other in the >+> picture can be in a single slice). A GOB in H.261 CIF >+> consists of THREE >+> partial rows of macroblocks extending only halfway across a picture. >+> And in H.264/AVC, a slice can be ANY collection of >+> macroblocks scattered >+> around absolutely anywhere in the picture (by use of a >+> feature known as >+> a "slice group map"). >+> >+> In regard to section 5.1 VideoFreezePicture, I believe H.262 >+> (also known >+> as MPEG-2 Video) also supports a freeze picture release >+> within the ITU-T >+> extension. >+> >+> It is also possible to obtain random access recovery without a fast >+> update. This is sometimes called "gradual decoder refresh". See for >+> example the recovery point SEI message in H.264/AVC. >+> >+> Best Regards, >+> >+> Gary Sullivan >+> >+> >+> +> -----Original Message----- >+> +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On >+> +> Behalf Of Andrea Basso >+> +> Sent: Monday, July 07, 2003 2:34 PM >+> +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org >+> +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; >+> +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit >+> +> Levin; Roni Even; nismail@cisco.com >+> +> Subject: [AVT] Requirements draft on video control >+> +> >+> +> >+> +> Attached you will find draft-basso-avt-videoconreq-00.txt >+> +> >+> +> Abstract: >+> +> >+> +> A variety of communication services such as video >+> +> conferencing and video messaging rely on the capability of video >+> +> encoders and decoders to exchange control commands. This document >+> +> outlines this set of commands as well as the requirements for >+> +> their transport. >+> +> >+> +> Comments are more than welcome. >+> +> >+> +> >+> +> >+> +> >+> +> >+> +> Andrea Basso >+> +> NMS Communications >+> +> (732) 936-2118 >+> +> (See attached file: draft-basso-avt-videoconreq-00.zip) >+> +> >+> >+> >+> >+> >+> >+> > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 17:36:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22905 for ; Thu, 10 Jul 2003 17:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj5A-00035b-HD for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALa4b0011871 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj59-00035O-1D for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:36:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22874 for ; Thu, 10 Jul 2003 17:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aj56-0007cP-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:36:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aj56-0007cM-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj57-000350-9l; Thu, 10 Jul 2003 17:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj49-00034F-Eq for mmusic@optimus.ietf.org; Thu, 10 Jul 2003 17:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22859 for ; Thu, 10 Jul 2003 17:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aj47-0007cC-00 for mmusic@ietf.org; Thu, 10 Jul 2003 17:34:59 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19aj46-0007c9-00 for mmusic@ietf.org; Thu, 10 Jul 2003 17:34:58 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6ALYQAk027115; Thu, 10 Jul 2003 14:34:26 -0700 (PDT) Received: from sun.com (vpn-129-150-17-247.SFBay.Sun.COM [129.150.17.247]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id OAA01986; Thu, 10 Jul 2003 14:34:25 -0700 (PDT) Message-ID: <3F0DDBB0.2040001@sun.com> Date: Thu, 10 Jul 2003 17:33:36 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <20030630174155.GC25404@real.com> <3F042CF2.5050307@ericsson.com> In-Reply-To: <3F042CF2.5050307@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments line: Magnus Westerlund wrote: > Hi, > > A few words in relation to this. When I filed the bug I was thinking > of such a case that you try to aggregate two different media that the > server did not offer as an aggregated session. However during > discussions I have come to the conclusion that it will be difficult to > use. However the aggregated control URI resolution may have more usage > when it comes to session that are supposed to be used where the > aggregated control URL is missing. I do think it is good to have > stated a direction on how this is resolved in cased when information > is missing but the server allows it. > > Note that a server can always refuse to perform aggregation of a media > with another, by responding to a SETUP request trying to aggregate > with a "459 Aggregate operation not allowed" error code. In that case > the client will have to perform synchronization, etc. locally using > two non-aggregated sessions. > > "If an Aggregate control URI is not specified in the session > description, a client MUST create an URI for aggregate control of the > session." > > I don't think this formulation is good. The reason a session > description does not give a aggregated control URI is that it does not > desire the media to be aggregated. I would reformulate the sentence into: > > If an Aggregate control URI is not specified in the session > description, it is probably a indication that non-aggregated control > SHOULD be used. However a client MAY try to SETUP the session in > aggregated control. If the server refuse to aggregate the specified > media, the server SHALL use the 459 error code. If the server allows > the aggregation, then the client MUST create an URI for aggregate > control of the session. This URI MUST contain the servers host address ... > > As a conclusion, I don't see a problem with this resolution, although > it is not what we had discussed. So I can understand any comments to > this. What do you think of the updated text? I think this works. My only comment is that I think we need clarify the definition of exactly what aggregate control means. The spec. is till unclear about this in many places. I think it is important to make sure that we re-check the use of the phrases "aggregate control" and "non-aggregate control" within the spec. Specifically aggregate control should be anything that happens within a session, whether a session has 0, 1 or more media. "Non-aggregate control" should be anything that happens between multiple sessions, regardless of how many media resources each session has. What we need to clearly state is that RTSP only deals with specifying aggregate control of media through a RTSP session, and not with other problem of non-aggregate control of multiple sessions. Do people agree with this interpretation? Thanks Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 17:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23505 for ; Thu, 10 Jul 2003 17:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajLb-00050m-Rs for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALr330019262 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajLb-00050b-5J for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23492 for ; Thu, 10 Jul 2003 17:52:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ajLY-0007iO-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:53:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ajLX-0007iL-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajLZ-00050D-4N; Thu, 10 Jul 2003 17:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajLL-000502-W0 for mmusic@optimus.ietf.org; Thu, 10 Jul 2003 17:52:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23477 for ; Thu, 10 Jul 2003 17:52:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ajLJ-0007i6-00 for mmusic@ietf.org; Thu, 10 Jul 2003 17:52:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ajLI-0007i1-00 for mmusic@ietf.org; Thu, 10 Jul 2003 17:52:44 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2003 14:50:22 -0700 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.9/8.12.6) with ESMTP id h6ALq9ro022393; Thu, 10 Jul 2003 14:52:11 -0700 (PDT) Received: from cisco.com (dhcp-171-71-97-84.cisco.com [171.71.97.84]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIZ98611; Thu, 10 Jul 2003 14:49:56 -0700 (PDT) Message-ID: <3F0DE007.2020505@cisco.com> Date: Thu, 10 Jul 2003 14:52:07 -0700 From: Bill May User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aravind Narasimhan CC: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <20030630174155.GC25404@real.com> <3F042CF2.5050307@ericsson.com> <3F0DDBB0.2040001@sun.com> In-Reply-To: <3F0DDBB0.2040001@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 Aravind Narasimhan wrote: > Specifically aggregate control > should be anything that happens within a session, whether a session has > 0, 1 or more media. "Non-aggregate control" should be anything that > happens between multiple sessions, regardless of how many media > resources each session has. What we need to clearly state is that RTSP > only deals with specifying aggregate control of media through a RTSP > session, and not with other problem of non-aggregate control of multiple > sessions. > > Do people agree with this interpretation? No, not really. Aggregate control to me has meant a method of controlling all streams in a session simultaneously. This can happen only if there is an a=control statement before any media. Non aggregate control has meant individual control of streams within a session. These use the a=control statement required by the media. I guess I do not understand where multiple sessions come in. Can you enlighten me as to where I'm wrong ? Bill May Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 18:11:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22388 for ; Thu, 10 Jul 2003 17:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001ph-FG for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNBKB007023 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001p4-8J for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22333 for ; Thu, 10 Jul 2003 17:23:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aisd-0007SC-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisa-0007Rv-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisW-0001la-Tn; Thu, 10 Jul 2003 17:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a2Ru-0001bP-Qv for mmusic@optimus.ietf.org; Tue, 08 Jul 2003 20:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16378; Tue, 8 Jul 2003 20:04:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a2Rs-0001f9-00; Tue, 08 Jul 2003 20:04:40 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 19a2Rr-0001eL-00; Tue, 08 Jul 2003 20:04:39 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jul 2003 17:03:51 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 17:03:51 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jul 2003 17:03:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jul 2003 17:03:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 8 Jul 2003 17:03:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jul 2003 17:03:29 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A3474A@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] Requirements draft on video control Thread-Index: AcNEz9VQ6y2SEFg1QmuFNQm9pmX67wA1yBiA From: "Gary Sullivan" To: "Andrea Basso" , , , Cc: , , , , "Orit Levin" , "Roni Even" , X-OriginalArrivalTime: 09 Jul 2003 00:03:49.0718 (UTC) FILETIME=[932A2F60:01C345AD] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: [AVT] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Much of the content of this ID will look familiar to those with experience with ITU-T systems control specifications (such as H.245). Some of it seems like it could use a bit of updating in that regard (e.g., videofastupdateGOB). Draft Recommendation H.241 is one good place to look for such information. Section 3 is a bit confused in its terminology. For example it seems to say that intra frames are also known as inter frames, which is definitely not the case. It mixes the terms "predictive" and "prediction" and seems to consider a "reference" frame to be synonymous with an intra frame. The terms "picture" and "frame" are also kind of mixed up. A more consistent terminology would be as follows: An intra picture is a picture that can be decoded without first decoding any other picture. A predicted (or non-intra) picture is a picture that may require data from one or more previously-decoded pictures in order to be properly decoded. A reference picture is a picture that is stored in the decoder for use as a reference in the decoding process of some subsequent picture in the bitstream. A non-reference picture is a picture that is not used as a reference for the decoding process of any other picture in the bitstream. The concepts of intra versus non-Intra and reference versus non-reference are independent. A particular picture can (in general) be any one of the four types (intra reference, non-intra reference, intra non-reference, non-intra non-reference). A "fast update", also known as an "instantaneous decoder refresh", involves sending an intra picture and thereafter refraining from using any picture sent prior to that intra picture as a reference for the decoding process of any subsequent picture sent in the stream. In particular it is worth noting that some concepts that applied to some older codecs are not really valid in general and should be avoided (e.g., that a non-reference picture is called a B picture or that an intra picture is the same thing as a fast update or that an intra picture is always a reference picture). The characterization of a "slice" or "GOB" as being a "stripe" is not really quite right. For example, a single slice in MPEG-1, H.263 Annex O, or MPEG-4 can consist of a few macroblocks at the right edge of one row and a few macroblocks at the left edge of the next row (i.e., two distinct rectangular regions quite far apart from each other in the picture can be in a single slice). A GOB in H.261 CIF consists of THREE partial rows of macroblocks extending only halfway across a picture. And in H.264/AVC, a slice can be ANY collection of macroblocks scattered around absolutely anywhere in the picture (by use of a feature known as a "slice group map"). In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known as MPEG-2 Video) also supports a freeze picture release within the ITU-T extension. It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC. Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On=20 +> Behalf Of Andrea Basso +> Sent: Monday, July 07, 2003 2:34 PM +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> Cc: casner@acm.org; jo@tzi.uni-bremen.de;=20 +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit=20 +> Levin; Roni Even; nismail@cisco.com +> Subject: [AVT] Requirements draft on video control +>=20 +>=20 +> Attached you will find draft-basso-avt-videoconreq-00.txt +>=20 +> Abstract: +>=20 +> A variety of communication services such as video +> conferencing and video messaging rely on the capability of video +> encoders and decoders to exchange control commands. This document +> outlines this set of commands as well as the requirements for +> their transport. +>=20 +> Comments are more than welcome. +>=20 +>=20 +>=20 +>=20 +>=20 +> Andrea Basso +> NMS Communications +> (732) 936-2118 +> (See attached file: draft-basso-avt-videoconreq-00.zip) +>=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 18:11:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22383 for ; Thu, 10 Jul 2003 17:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001pT-E7 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNBmS007017 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aish-0001p6-9U for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22335 for ; Thu, 10 Jul 2003 17:23:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aisd-0007SP-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisa-0007S2-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisY-0001mU-9F; Thu, 10 Jul 2003 17:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKRe-000559-QQ for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 15:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16623; Wed, 9 Jul 2003 15:17:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKRd-0002Ah-00; Wed, 09 Jul 2003 15:17:37 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19aKRc-0002Ae-00; Wed, 09 Jul 2003 15:17:36 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 9 Jul 2003 14:12:37 UT To: "Gary Sullivan" Cc: "Andrea Basso" , avt@ietf.org, casner@acm.org, csp@csperkins.org, jo@tzi.uni-bremen.de, magnus.westerlund@ericsson.com, mmusic@ietf.org, nismail@cisco.com, "Orit Levin" , "Roni Even" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Wed, 9 Jul 2003 15:17:29 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 07/09/2003 03:13:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RE: [AVT] Requirements draft on video control Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Gary, here are some comments. > Some of it seems like it could use a bit of updating in that regard > (e.g., videofastupdateGOB). > Draft Recommendation H.241 is one good place to look for such > information. H.241 is very focused on H.264 and in very early stages in addressing Commands and Indications applicable to all codecs. If you look at the H.241 draft section 6 says: 6 Commands and Indications 6.1 C&I applicable to all video codecs For further study. We plan to monitor the evolution the H.241 and to update the ID accordingly if needed. >intra frames are also known as inter frames, which is >definitely not the case I do not think the text says this. Here is the sentence: Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 [5], H.264 [6] can encode video pictures as reference frames, also known as intra frames or predicted frames, also known as inter frames. >The terms "picture" and "frame" are also kind of >mixed up. For progressive video, a picture is identical to a frame. The difference appears for interlaced video only. The new text will use the term 'picture' only. >The characterization of a "slice" or "GOB" as being a "stripe" is not >really quite right. The text does not say "image stripe" says "stripe" and in particular it does not imply that such stripe goes border-to-border in the image (i.e. can cover a partial macroblock row) nor that is should only include a single macroblock row (i.e., can cover multiple partial rows as in H.261). Clarifications will be addressed in the new version of the draft. -A Andrea Basso NMS Communications (732) 936-2118 "Gary Sullivan" , , rosoft.com> , cc: , , 07/08/2003 08:03 PM , , "Orit Levin" , "Roni Even" , Subject: RE: [AVT] Requirements draft on video control Much of the content of this ID will look familiar to those with experience with ITU-T systems control specifications (such as H.245). Some of it seems like it could use a bit of updating in that regard (e.g., videofastupdateGOB). Draft Recommendation H.241 is one good place to look for such information. Section 3 is a bit confused in its terminology. For example it seems to say that intra frames are also known as inter frames, which is definitely not the case. It mixes the terms "predictive" and "prediction" and seems to consider a "reference" frame to be synonymous with an intra frame. The terms "picture" and "frame" are also kind of mixed up. A more consistent terminology would be as follows: An intra picture is a picture that can be decoded without first decoding any other picture. A predicted (or non-intra) picture is a picture that may require data from one or more previously-decoded pictures in order to be properly decoded. A reference picture is a picture that is stored in the decoder for use as a reference in the decoding process of some subsequent picture in the bitstream. A non-reference picture is a picture that is not used as a reference for the decoding process of any other picture in the bitstream. The concepts of intra versus non-Intra and reference versus non-reference are independent. A particular picture can (in general) be any one of the four types (intra reference, non-intra reference, intra non-reference, non-intra non-reference). A "fast update", also known as an "instantaneous decoder refresh", involves sending an intra picture and thereafter refraining from using any picture sent prior to that intra picture as a reference for the decoding process of any subsequent picture sent in the stream. In particular it is worth noting that some concepts that applied to some older codecs are not really valid in general and should be avoided (e.g., that a non-reference picture is called a B picture or that an intra picture is the same thing as a fast update or that an intra picture is always a reference picture). The characterization of a "slice" or "GOB" as being a "stripe" is not really quite right. For example, a single slice in MPEG-1, H.263 Annex O, or MPEG-4 can consist of a few macroblocks at the right edge of one row and a few macroblocks at the left edge of the next row (i.e., two distinct rectangular regions quite far apart from each other in the picture can be in a single slice). A GOB in H.261 CIF consists of THREE partial rows of macroblocks extending only halfway across a picture. And in H.264/AVC, a slice can be ANY collection of macroblocks scattered around absolutely anywhere in the picture (by use of a feature known as a "slice group map"). In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known as MPEG-2 Video) also supports a freeze picture release within the ITU-T extension. It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC. Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On +> Behalf Of Andrea Basso +> Sent: Monday, July 07, 2003 2:34 PM +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit +> Levin; Roni Even; nismail@cisco.com +> Subject: [AVT] Requirements draft on video control +> +> +> Attached you will find draft-basso-avt-videoconreq-00.txt +> +> Abstract: +> +> A variety of communication services such as video +> conferencing and video messaging rely on the capability of video +> encoders and decoders to exchange control commands. This document +> outlines this set of commands as well as the requirements for +> their transport. +> +> Comments are more than welcome. +> +> +> +> +> +> Andrea Basso +> NMS Communications +> (732) 936-2118 +> (See attached file: draft-basso-avt-videoconreq-00.zip) +> _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 18:11:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22393 for ; Thu, 10 Jul 2003 17:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisk-0001qp-Hd for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALNELi007109 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 17:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisk-0001qO-Cj for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:23:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22329 for ; Thu, 10 Jul 2003 17:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aisc-0007SL-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aisa-0007S4-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 17:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aisX-0001mH-VK; Thu, 10 Jul 2003 17:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK54-00038r-89 for mmusic@optimus.ietf.org; Wed, 09 Jul 2003 14:54:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14276; Wed, 9 Jul 2003 14:54:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aK51-0001sH-00; Wed, 09 Jul 2003 14:54:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aK4z-0001rJ-00; Wed, 09 Jul 2003 14:54:14 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2003 11:56:34 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h69IrepZ005290; Wed, 9 Jul 2003 11:53:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW13842; Wed, 9 Jul 2003 11:53:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA11010; Wed, 9 Jul 2003 11:53:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16140.25779.138519.619908@thomasm-u1.cisco.com> Date: Wed, 9 Jul 2003 11:53:39 -0700 (PDT) To: "Rosen, Brian" Cc: "'Yutaka Takeda'" , sip@ietf.org, mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hmm. I'd always thought of SIP as a rendezvous protocol so this seems perfectly natural to me. Is the general problem here that the SDP announcement for an RTSP controlled session isn't defined? Or is the issue that people would like to piggyback both the RTSP and RTP session information in the SIP SDP? Or both?=20 Of course if the announcement for RTSP is not specified, it sort of begs the question of why you'd want to just define RTSP semantics... why not HTTP semantics, etc too? (in which case, it seems to me that an over-loaded SIP SDP announcment is probably the wrong thing to do). =09 Mike Rosen, Brian writes: > I've been thinking for a long time about what an appropriate > mechanism to provide a voice/videomail client on a sipphone > would be. It's really clear that you record and play messages > with VCR like functionality. For that, you need start/stop/pause/ > rewind/fast forward, and so I was thinking RTSP. On the other > hand, you surely establish the session to the voicemail server > with a sip call. >=20 > Thus, I like the way Jonathan is thinking, but you also need > message selection/creation/deletion functions, and for those > I was thinking KPML, and then you wonder if you just use that > as the signalling mechanism for the record/play, and I get > confused. >=20 > Brian >=20 > > -----Original Message----- > > From: Yutaka Takeda [mailto:takeday@kmerl.com] > > Sent: Wednesday, July 09, 2003 2:11 PM > > To: sip@ietf.org; mmusic@ietf.org > > Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > > The applications that have need for SIP and RTSP features I > > can imagine are: > >=20 > > - Voice&video mail (similar to 'sipum' but VM server is in=20 > > the SIP phone) > > - Personal broadcast station from my PC at home. > > - Watching video recorded with VCR at home or office from remote..= . > >=20 > > What I am not sure is if RTSP has any solution or a framework for = a > > RTSP server behind a NAT. If not, the solution is likely to=20 > > be a repeat > > of what SIP provides. I thought TURN could be used in order=20 > > for signaling > > message to reach RTSP server behind a NAT, but I noticed that=20 > > it is not=20 > > applicable (purposefully) for a server running behind a NAT becaus= e of > > a security consideration. Lots of issues for RTSP in this area alo= ne? > >=20 > > I believe a lot of people are interested in this discussion. > >=20 > > Best regards, > > Yutaka > >=20 > >=20 > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Wednesday, July 09, 2003 5:53 AM > > > To: Pianigiani, Jacopo (Jacopo) > > > Cc: sip@ietf.org; mmusic@ietf.org > > > Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > > >=20 > > >=20 > > > Hi, > > >=20 > > > When it comes to IMS and 3G terminals, most will already=20 > > > before having=20 > > > an IMS functionality have support for PSS. PSS is=20 > > > Packet-based Streaming=20 > > > Service which is an umbrella kind of standard for streaming serv= ice=20 > > > defined in 3GPP targeted at low bit-rates and mobile networks.=20= > > > Specification available from Rel 4 in TS 26.233 and TS=20 > > > 26.234. Already=20 > > > today there exist GSM/GPRS phones that has a PSS client. > > >=20 > > > So I think that dual stack implementations will not be that=20 > > > impossible=20 > > > to foresee. > > >=20 > > > However I think the main issue in this discussion is to=20 > > look at what=20 > > > applications that has need for SIP-RTSP interactions. Based=20 > > > on this we=20 > > > can see if there is solutions easily available or not. > > >=20 > > > I can agree with Rosenberg that if we where going to design a RT= SP=20 > > > functionality protocol today, looking at SIP for session=20 > > > establishment=20 > > > would be interesting. However that opportunity has passed=20 > > as RTSP has=20 > > > started to be deployed in increasing numbers. I think even=20 > > the latest=20 > > > Windows media player does support RTSP. > > >=20 > > >=20 > > > Best Regards > > >=20 > > > Magnus Westerlund > > >=20 > > >=20 > > > Pianigiani, Jacopo (Jacopo) wrote: > > > > Hello all, > > > > In my undertanding RTSP is suitable for broadcast, unicast=20 > > > or multicast streams distribution. The RTSP protocol was=20 > > > ideated for typical content delivery, and in effect for this=20 > > > application could be more than suitable. But referring to an=20 > > > IMS domain, in my point of view adopting RSTP as media=20 > > > streams control, would imply adopting at least a double=20 > > > protocol stack in the terminal equipment. The IMS concept was=20= > > > mainly driven by the concept - in my understanding - of=20 > > > simplifying the terminal (making it simpler from a protocol=20 > > > stack implementation means lowering costs and increasing=20 > > > penetration on the market) by adopting a single protocol=20 > > > stack in the terminal, and having the RAN and the core=20 > > > evolving toward a unified transport mechanism for which an=20 > > > almost unified level of control on the network resources=20 > > > allocated to a session (whatever session we refer to, voice ,=20= > > > multimedia p-t-t call, web browsing, multimedia session with=20 > > > voice call and dynamic web pages). > > > > So in this sense, my understanding is that the RTSP could=20 > > > be suitable for media content, but it would imply again new=20 > > > complexity on the IMS UMTS/CDMA terminal itself, which is=20 > > > against the idea of IMS of enhancing the services the user=20 > > > can access by having an homogeneous protocol stack on the=20 > > > terminal itself for all types of services. > > > >=20 > > > > After all, the RTSP , apart from content delivery (of=20 > > > streams), could not definitely handle appropriately sessions=20 > > > like Voice calls + Interactive Web Pages.=20 > > > > Regards > > > >=20 > > > > Jacopo Pianigiani > > > > Lucent Technologies - Italy > > > > =E839 335 7350536 > > > >=20 > > > > -----Original Message----- > > > > From: Paolo Asprino [mailto:asprino@coritel.it] > > > > Sent: Wednesday, July 09, 2003 9:40 AM > > > > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > > > Subject: Re: [Sip] Appropriate usage of SIP and RTSP > > > >=20 > > > >=20 > > > > Hi all > > > >=20 > > > > I'm thinking a solution to join SIP and RTSP in the 3G IMS dom= ain. > > > > In particular in the IMS, I think that to provide multilmedia > > > > service (i.e video on demand), one can estabilish a=20 > > > subscription to the service by SIP and then activate the=20 > > > service with RTSP by DIGEST autentication with the=20 > > > > parameters exchanged early during the subscription=20 > > > (username and password)=20 > > > >=20 > > > > What do you think about that? > > > >=20 > > > > Best Regards=20 > > > >=20 > > > > ----- Original Message -----=20 > > > > From: "NAKAMURA, Hidefumi" > > > > To: ; > > > > Cc: > > > > Sent: Monday, July 07, 2003 9:49 AM > > > > Subject: [Sip] Appropriate usage of SIP and RTSP > > > >=20 > > > >=20 > > > >=20 > > > >>Hi, all. > > > >> > > > >>I have a question about the relationship between SIP and RTSP.= =20 > > > >> > > > >>In RFC3261, there is a description that says=20 > > > >> "SIP is not a vertically integrated communications=20 > > > system. SIP is > > > >> rather a component that can be used with other IETF=20 > > protocols to > > > >> build a complete multimedia architecture. Typically, these= > > > >> architectures will include protocols such as the=20 > > > Real-time Transport > > > >> Protocol (RTP) (RFC 1889 [28]) for transporting=20 > > > real-time data and > > > >> providing QoS feedback, the Real-Time streaming protocol=20= > > > (RTSP) (RFC > > > >> 2326 [29]) for controlling delivery of streaming media, ...= " > > > >> (RFC3261 Section 2) > > > >> > > > >>However, my understanding is that both SIP and RTSP have=20 > > > the capability > > > >>for "discovery of UAs or media streams." > > > >>If I use SIP to establish a stream session and use RTSP to con= trol > > > >>the stream, there will be redundant sequences, i.e.=20 > > > INVITE-OK-ACK and > > > >>SETUP-OK. > > > >> > > > >>Was there any discussion on how to use these two protocols=20 > > > appropriately? > > > >> > > > >>With SIP application server, network providers can provide var= ious > > > >>services on contents delivery while we will not be able to=20 > > > do so only > > > >>with RTSP, I think. On the other hand, RTSP has enough=20 > > > capability for > > > >>discovery of media streams and for negotiation of SDPs. > > > >>So, I think, for the simple delivery of contents, RTSP is=20 > > > appropriate to > > > >>use, and for various session control services regarding conten= ts > > > >>delivery, SIP with RTSP is appropriate to use. > > > >> > > > >>Any opinions? > > > >> > > > >>I wonder why no contents delivery server seems to prepare=20 > > > SIP stack now.=20 > > > >>Is it because, up to now, there exists only a simple=20 > > > contents delivery > > > >>service? > > > >> > > > >>best regards, > > > >> > > > >>--=20 > > > >>NAKAMURA, Hidefumi=20 > > > >>NTT ServiceIntegration /NetworkServiceSystems Labs. > > > >>tel: +81(422)59 3904; fax:+81(422)60 4012 > > > >>--- > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >>This list is for NEW development of the core SIP Protocol > > > >>Use sip-implementors@cs.columbia.edu for questions on current = sip > > > >>Use sipping@ietf.org for new developments on the=20 > > application of sip > > > >> > > > >=20 > > > >=20 > > > >=20 > > > > --- > > > > Outgoing mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.495 / Virus Database: 294 - Release Date:=20 > > > 30/06/2003J*fj)bz=09b=B2=D8m=B6>?=FF=0C> > 0=D6'=AD~S=E0=FEf=A2-= f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY=D7=AF > > > zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h= =AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > > > =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6= =CA'=B6=17s=A6(tm)bq=ABb=A2z=1F > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current = sip > > > > Use sipping@ietf.org for new developments on the=20 > > application of sip > > > >=20 > > >=20 > > >=20 > > > --=20 > > >=20 > > > Magnus Westerlund > > >=20 > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > >=20 > > ------------------------------------------------------------------= ---- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.= com > > >=20 > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 10 23:28:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02115 for ; Thu, 10 Jul 2003 23:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aoZp-0004UY-U4 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 23:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B3S5Pf017254 for mmusic-archive@odin.ietf.org; Thu, 10 Jul 2003 23:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aoZo-0004U8-EG for mmusic-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 23:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02103 for ; Thu, 10 Jul 2003 23:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aoZm-0001nO-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 23:28:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aoZl-0001nL-00 for mmusic-web-archive@ietf.org; Thu, 10 Jul 2003 23:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aoZl-0004TC-OJ; Thu, 10 Jul 2003 23:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aoZC-0004SG-9O for mmusic@optimus.ietf.org; Thu, 10 Jul 2003 23:27:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02092 for ; Thu, 10 Jul 2003 23:27:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aoZA-0001n9-00 for mmusic@ietf.org; Thu, 10 Jul 2003 23:27:24 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19aoZ9-0001n6-00 for mmusic@ietf.org; Thu, 10 Jul 2003 23:27:23 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 10 Jul 2003 20:15:29 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Thu, 10 Jul 2003 20:15:29 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Thu, 10 Jul 2003 20:26:07 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19aoYR-0000Lg-00 for ; Thu, 10 Jul 2003 20:26:39 -0700 Date: Thu, 10 Jul 2003 20:25:20 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_20,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #81 - 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-678107 ] Change of Proxy-Require header (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 10 Jul 2003 02:42:58 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-678107 ] Change of Proxy-Require header Bugs item #678107, was opened at 2003-01-31 13:43 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194 Category: General >Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Change of Proxy-Require header Initial Comment: Current text: Says that proxy-require applies to both proxy and server. New Proposal: The feature tags in a "Proxy-require" header will only apply to the proxies, and not the server. For feature that the server must support the "Require" header shall be used. If required feature support from both proxy and server both "Proxy-Require" and "Require" must be used. Pro: - Align with SIP's usage of header - Makes it possible to create features tags for proxy only functionality. Otherwise all servers will be mandated to also know about proxy only features. Cons: - Backwards compatibility. (Actually this does not matter much as: A old server implementing the old way would also not work with any new feature tags for proxies. So it will block operation independent of changed semantics or not.) ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=302620 Whas resolved at the telecon january 22 2003. Resolution: Proxy-require shall only apply to proxies not servers. Needs to be changed in the specification. Should also clarify that a feature tag can be of type, proxy, server or both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 03:13:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19005 for ; Fri, 11 Jul 2003 03:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19as5Y-0005WT-B6 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 03:13:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B7D40h021230 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 03:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19as5Y-0005WL-3Y for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 03:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18986 for ; Fri, 11 Jul 2003 03:13:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19as5W-00032N-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 03:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19as5V-00032K-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 03:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19as5T-0005Vq-HY; Fri, 11 Jul 2003 03:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19as4o-0005V1-Us for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 03:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18976 for ; Fri, 11 Jul 2003 03:12:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19as4m-00032D-00 for mmusic@ietf.org; Fri, 11 Jul 2003 03:12:16 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19as4l-000328-00 for mmusic@ietf.org; Fri, 11 Jul 2003 03:12:16 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6B7CCGJ022025; Fri, 11 Jul 2003 09:12:12 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6BWX0F; Fri, 11 Jul 2003 09:13:09 +0200 Message-ID: <3F0E634A.8050606@ericsson.com> Date: Fri, 11 Jul 2003 09:12:10 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill May CC: Aravind Narasimhan , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <20030630174155.GC25404@real.com> <3F042CF2.5050307@ericsson.com> <3F0DDBB0.2040001@sun.com> <3F0DE007.2020505@cisco.com> In-Reply-To: <3F0DE007.2020505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aravind and Bill, My view on aggregated control has been that this is a media session which has at least 2 media. That forces a server to run these under aggregated control according to the new spec. Non-aggregated control is when a session has only 1 media. However I agree that this is not a watertight definition as a client could potentially use the aggregated control URL to control a session with only a single media. However there is some clear differences in behaviour between a session with 1 media and another with 2 media. I do agree that we need to resolve this and use it consistently through the draft. What we need to express in the draft, I believe is the differences between a 1 media session and a 2 or more media session. Then we can of course better explain that using multiple 1 media sessions allow the client maximal control of how to handle the media. Then we must also clarify how the aggregated and non-aggregated control URI fit. Best Regards Magnus Bill May wrote: > > > Aravind Narasimhan wrote: > > Specifically aggregate control > >> should be anything that happens within a session, whether a session >> has 0, 1 or more media. "Non-aggregate control" should be anything >> that happens between multiple sessions, regardless of how many media >> resources each session has. What we need to clearly state is that >> RTSP only deals with specifying aggregate control of media through a >> RTSP session, and not with other problem of non-aggregate control of >> multiple sessions. >> >> Do people agree with this interpretation? > > > No, not really. Aggregate control to me has meant a method of > controlling all > streams in a session simultaneously. This can happen only if there is an > a=control statement before any media. > > Non aggregate control has meant individual control of streams within a > session. > These use the a=control statement required by the media. > > I guess I do not understand where multiple sessions come in. > > Can you enlighten me as to where I'm wrong ? > > Bill May > Cisco Systems > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 06:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24381 for ; Fri, 11 Jul 2003 06:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avWQ-00060Q-VG for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 06:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BAr2ZA023082 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 06:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avWQ-00060D-S6 for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 06:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24371 for ; Fri, 11 Jul 2003 06:52:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19avWM-0004YQ-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 06:52:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19avWM-0004YN-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 06:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avWO-0005zn-Rf; Fri, 11 Jul 2003 06:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avVd-0005zS-7b for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 06:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24363 for ; Fri, 11 Jul 2003 06:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19avVY-0004YG-00 for mmusic@ietf.org; Fri, 11 Jul 2003 06:52:09 -0400 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]) by ietf-mx with esmtp (Exim 4.12) id 19avVX-0004YD-00 for mmusic@ietf.org; Fri, 11 Jul 2003 06:52:08 -0400 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail7.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h6BApbM2020240 for ; Fri, 11 Jul 2003 19:51:37 +0900 (envelope-from nomura@swan.png.flab.fujitsu.co.jp) Received: from s3.gw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h6BApaKE000931 for ; Fri, 11 Jul 2003 19:51:36 +0900 (envelope-from nomura@swan.png.flab.fujitsu.co.jp) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.4]) by s3.gw.fujitsu.co.jp (8.12.9) id h6BApYIJ008070 for ; Fri, 11 Jul 2003 19:51:35 +0900 (envelope-from nomura@swan.png.flab.fujitsu.co.jp) Received: from flabmail.flab.fujitsu.co.jp by flabmail.flab.fujitsu.co.jp (8.9.3p2/3.7W-030703-Fujitsu Labs. Domain Mail Master (NAVGW)) id TAA28625; Fri, 11 Jul 2003 19:51:34 +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 M2003071119513420449 ; Fri, 11 Jul 2003 19:51:34 +0900 Received: from robin (localhost [127.0.0.1]) by swan.png.flab.fujitsu.co.jp (8.9.1/3.7W) with ESMTP id TAA05002; Fri, 11 Jul 2003 19:51:34 +0900 (JST) Message-Id: <200307111051.TAA05002@swan.png.flab.fujitsu.co.jp> To: jo@informatik.uni-bremen.de, csp@csperkins.org, 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, 11 Jul 2003 19:51:33 +0900 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-nomura-mmusic-img-requirements-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I submitted following I-D in June, and it is now available at the official web site. Please update the MMUSIC Agenda for the 57th IETF. http://www.ietf.org/internet-drafts/draft-nomura-mmusic-img-requirements-01.txt Title: Protocol Requirements for Internet Media Guides Filename: draft-nomura-mmusic-img-requirements-01.txt Abstract: This memo specifies requirements for a protocol for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide development of an IMG protocol for efficient and scalable delivery. Comments are appreciated. ---------- Yuji Nomura _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 10:17:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01001 for ; Fri, 11 Jul 2003 10:17:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayht-0005CG-31 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 10:17:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BEH5Cv019972 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 10:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayhs-0005C3-Ux for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 10:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00964 for ; Fri, 11 Jul 2003 10:17:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayhq-0005vV-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 10:17:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ayhp-0005vS-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 10:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayhp-0005B9-5q; Fri, 11 Jul 2003 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayhl-0005Au-Gj for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 10:16:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00946; Fri, 11 Jul 2003 10:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayhi-0005vP-00; Fri, 11 Jul 2003 10:16:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ayhh-0005vL-00; Fri, 11 Jul 2003 10:16:53 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6BEGL7F003667; Fri, 11 Jul 2003 07:16:21 -0700 (PDT) Received: from [10.0.1.6] (sjc-vpn2-563.cisco.com [10.21.114.51]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY09875; Fri, 11 Jul 2003 07:16:19 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 11 Jul 2003 07:16:17 -0700 Subject: Re: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP From: Cullen Jennings To: Brian Rosen , "'Yutaka Takeda'" , , Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In many ways, this problem is similar to the far end camera control issues. Real time responses is needed, It is a 1:1 relationship between the controller and controlee, the control protocol needs to be extensible. On 7/9/03 11:40, "Rosen, Brian" wrote: > I've been thinking for a long time about what an appropriate > mechanism to provide a voice/videomail client on a sipphone > would be. It's really clear that you record and play messages > with VCR like functionality. For that, you need start/stop/pause/ > rewind/fast forward, and so I was thinking RTSP. On the other > hand, you surely establish the session to the voicemail server > with a sip call. >=20 > Thus, I like the way Jonathan is thinking, but you also need > message selection/creation/deletion functions, and for those > I was thinking KPML, and then you wonder if you just use that > as the signalling mechanism for the record/play, and I get > confused. >=20 > Brian >=20 >> -----Original Message----- >> From: Yutaka Takeda [mailto:takeday@kmerl.com] >> Sent: Wednesday, July 09, 2003 2:11 PM >> To: sip@ietf.org; mmusic@ietf.org >> Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >>=20 >>=20 >> The applications that have need for SIP and RTSP features I >> can imagine are: >>=20 >> - Voice&video mail (similar to 'sipum' but VM server is in >> the SIP phone) >> - Personal broadcast station from my PC at home. >> - Watching video recorded with VCR at home or office from remote... >>=20 >> What I am not sure is if RTSP has any solution or a framework for a >> RTSP server behind a NAT. If not, the solution is likely to >> be a repeat >> of what SIP provides. I thought TURN could be used in order >> for signaling >> message to reach RTSP server behind a NAT, but I noticed that >> it is not=20 >> applicable (purposefully) for a server running behind a NAT because of >> a security consideration. Lots of issues for RTSP in this area alone? >>=20 >> I believe a lot of people are interested in this discussion. >>=20 >> Best regards, >> Yutaka >>=20 >>=20 >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Wednesday, July 09, 2003 5:53 AM >>> To: Pianigiani, Jacopo (Jacopo) >>> Cc: sip@ietf.org; mmusic@ietf.org >>> Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >>>=20 >>>=20 >>> Hi, >>>=20 >>> When it comes to IMS and 3G terminals, most will already >>> before having=20 >>> an IMS functionality have support for PSS. PSS is >>> Packet-based Streaming >>> Service which is an umbrella kind of standard for streaming service >>> defined in 3GPP targeted at low bit-rates and mobile networks. >>> Specification available from Rel 4 in TS 26.233 and TS >>> 26.234. Already >>> today there exist GSM/GPRS phones that has a PSS client. >>>=20 >>> So I think that dual stack implementations will not be that >>> impossible=20 >>> to foresee. >>>=20 >>> However I think the main issue in this discussion is to >> look at what=20 >>> applications that has need for SIP-RTSP interactions. Based >>> on this we=20 >>> can see if there is solutions easily available or not. >>>=20 >>> I can agree with Rosenberg that if we where going to design a RTSP >>> functionality protocol today, looking at SIP for session >>> establishment=20 >>> would be interesting. However that opportunity has passed >> as RTSP has=20 >>> started to be deployed in increasing numbers. I think even >> the latest=20 >>> Windows media player does support RTSP. >>>=20 >>>=20 >>> Best Regards >>>=20 >>> Magnus Westerlund >>>=20 >>>=20 >>> Pianigiani, Jacopo (Jacopo) wrote: >>>> Hello all, >>>> In my undertanding RTSP is suitable for broadcast, unicast >>> or multicast streams distribution. The RTSP protocol was >>> ideated for typical content delivery, and in effect for this >>> application could be more than suitable. But referring to an >>> IMS domain, in my point of view adopting RSTP as media >>> streams control, would imply adopting at least a double >>> protocol stack in the terminal equipment. The IMS concept was >>> mainly driven by the concept - in my understanding - of >>> simplifying the terminal (making it simpler from a protocol >>> stack implementation means lowering costs and increasing >>> penetration on the market) by adopting a single protocol >>> stack in the terminal, and having the RAN and the core >>> evolving toward a unified transport mechanism for which an >>> almost unified level of control on the network resources >>> allocated to a session (whatever session we refer to, voice , >>> multimedia p-t-t call, web browsing, multimedia session with >>> voice call and dynamic web pages). >>>> So in this sense, my understanding is that the RTSP could >>> be suitable for media content, but it would imply again new >>> complexity on the IMS UMTS/CDMA terminal itself, which is >>> against the idea of IMS of enhancing the services the user >>> can access by having an homogeneous protocol stack on the >>> terminal itself for all types of services. >>>>=20 >>>> After all, the RTSP , apart from content delivery (of >>> streams), could not definitely handle appropriately sessions >>> like Voice calls + Interactive Web Pages. >>>> Regards >>>>=20 >>>> Jacopo Pianigiani >>>> Lucent Technologies - Italy >>>> =E839 335 7350536 >>>>=20 >>>> -----Original Message----- >>>> From: Paolo Asprino [mailto:asprino@coritel.it] >>>> Sent: Wednesday, July 09, 2003 9:40 AM >>>> To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org >>>> Subject: Re: [Sip] Appropriate usage of SIP and RTSP >>>>=20 >>>>=20 >>>> Hi all >>>>=20 >>>> I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. >>>> In particular in the IMS, I think that to provide multilmedia >>>> service (i.e video on demand), one can estabilish a >>> subscription to the service by SIP and then activate the >>> service with RTSP by DIGEST autentication with the >>>> parameters exchanged early during the subscription >>> (username and password) >>>>=20 >>>> What do you think about that? >>>>=20 >>>> Best Regards=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: "NAKAMURA, Hidefumi" >>>> To: ; >>>> Cc: >>>> Sent: Monday, July 07, 2003 9:49 AM >>>> Subject: [Sip] Appropriate usage of SIP and RTSP >>>>=20 >>>>=20 >>>>=20 >>>>> Hi, all. >>>>>=20 >>>>> I have a question about the relationship between SIP and RTSP. >>>>>=20 >>>>> In RFC3261, there is a description that says >>>>> "SIP is not a vertically integrated communications >>> system. SIP is >>>>> rather a component that can be used with other IETF >> protocols to >>>>> build a complete multimedia architecture. Typically, these >>>>> architectures will include protocols such as the >>> Real-time Transport >>>>> Protocol (RTP) (RFC 1889 [28]) for transporting >>> real-time data and >>>>> providing QoS feedback, the Real-Time streaming protocol >>> (RTSP) (RFC >>>>> 2326 [29]) for controlling delivery of streaming media, ..." >>>>> (RFC3261 Section 2) >>>>>=20 >>>>> However, my understanding is that both SIP and RTSP have >>> the capability >>>>> for "discovery of UAs or media streams." >>>>> If I use SIP to establish a stream session and use RTSP to control >>>>> the stream, there will be redundant sequences, i.e. >>> INVITE-OK-ACK and >>>>> SETUP-OK. >>>>>=20 >>>>> Was there any discussion on how to use these two protocols >>> appropriately? >>>>>=20 >>>>> With SIP application server, network providers can provide various >>>>> services on contents delivery while we will not be able to >>> do so only >>>>> with RTSP, I think. On the other hand, RTSP has enough >>> capability for >>>>> discovery of media streams and for negotiation of SDPs. >>>>> So, I think, for the simple delivery of contents, RTSP is >>> appropriate to >>>>> use, and for various session control services regarding contents >>>>> delivery, SIP with RTSP is appropriate to use. >>>>>=20 >>>>> Any opinions? >>>>>=20 >>>>> I wonder why no contents delivery server seems to prepare >>> SIP stack now.=20 >>>>> Is it because, up to now, there exists only a simple >>> contents delivery >>>>> service? >>>>>=20 >>>>> best regards, >>>>>=20 >>>>> --=20 >>>>> NAKAMURA, Hidefumi >>>>> NTT ServiceIntegration /NetworkServiceSystems Labs. >>>>> tel: +81(422)59 3904; fax:+81(422)60 4012 >>>>> --- >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the >> application of sip >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --- >>>> Outgoing mail is certified Virus Free. >>>> Checked by AVG anti-virus system (http://www.grisoft.com). >>>> Version: 6.0.495 / Virus Database: 294 - Release Date: >>> 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> > 0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY=D7=AF >>> zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB >>> =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17s=A6(tm)bq=ABb=A2z=1F >>>>=20 >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the >> application of sip >>>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Magnus Westerlund >>>=20 >>> Multimedia Technologies, Ericsson Research EAB/TVA/A >>>=20 >> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 10:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01961 for ; Fri, 11 Jul 2003 10:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19az71-0007nQ-7s for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 10:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BEh37V029962 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 10:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19az71-0007nB-4H for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 10:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01933 for ; Fri, 11 Jul 2003 10:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19az6y-00065x-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 10:43:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19az6x-00065u-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 10:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19az6z-0007mk-D6; Fri, 11 Jul 2003 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19az6J-0007jh-CO for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 10:42:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01922 for ; Fri, 11 Jul 2003 10:42:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19az6H-00065U-00 for mmusic@ietf.org; Fri, 11 Jul 2003 10:42:17 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19az6G-00064y-00 for mmusic@ietf.org; Fri, 11 Jul 2003 10:42:16 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6BEfYpi013989; Fri, 11 Jul 2003 07:41:34 -0700 (PDT) Received: from sun.com (vpn-129-150-17-173.SFBay.Sun.COM [129.150.17.173]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id HAA16381; Fri, 11 Jul 2003 07:41:33 -0700 (PDT) Message-ID: <3F0ECC63.6020900@sun.com> Date: Fri, 11 Jul 2003 10:40:35 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill May CC: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <20030630174155.GC25404@real.com> <3F042CF2.5050307@ericsson.com> <3F0DDBB0.2040001@sun.com> <3F0DE007.2020505@cisco.com> In-Reply-To: <3F0DE007.2020505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Bill, comments inline: Bill May wrote: > > > Aravind Narasimhan wrote: > > Specifically aggregate control > >> should be anything that happens within a session, whether a session >> has 0, 1 or more media. "Non-aggregate control" should be anything >> that happens between multiple sessions, regardless of how many media >> resources each session has. What we need to clearly state is that >> RTSP only deals with specifying aggregate control of media through a >> RTSP session, and not with other problem of non-aggregate control of >> multiple sessions. >> >> Do people agree with this interpretation? > > > No, not really. Aggregate control to me has meant a method of > controlling all > streams in a session simultaneously. This can happen only if there is an > a=control statement before any media. The a=control attribute at the session level of an SDP description indicates that URL that should be used for aggregate control of the presentation that is being described. While this is what the client should use for aggregate control of the presentation, this is not a normative requirement from the RTSP spec. For one thing RTSP and SDP are not tied together. You could potentially use a different standard for describing a session. Secondly, as Tom and Magnus have mentioned, a user may try to aggregate multiple streams in one RTSP session, where there isnt a unified presentaiton description, or where someone has ignored to put a session level aggregate control URL in the SDP. Now the server has the right to say that it cannot aggregate the given media URLs in a session, but it does not make sense for the server to allow two or more streams to be part of a session where each stream within the session is going ot be controlled separately in a non-aggregate fashion. In the RTSP concalls of late, there was a general trend towards a consensus that within a RTSP session, all streams should be "aggregately controlled." In other words, once part of a session, an individual media stream will be tied to the timeline of the session and will be controlled in conjunction with the rest of the streams in the session. So control methods such as PAUSE, PLAY would apply collectively to all streams within the session. The upshot of this is that you cannot just PLAY or PAUSE a single media stream within a session. > > Non aggregate control has meant individual control of streams within a > session. > These use the a=control statement required by the media. > > I guess I do not understand where multiple sessions come in. To achieve the notion of "non-aggregate control", or may be the more appropriate term is "independent control" the consensus was that the onus should be on the client to set up multiple RTSP sessions, each with one or more media streams and manage them in a non-aggregate fashion. To try to clearly specify the mechanisms of "non-aggregate" control of individual media streams within a single session would probably cloud and confuse the spec unnecessarily, since the functionality is easily achievable by having multiple RTSP sessions that are controlled independently. If this becomes a very serious requirement, someone can write an extension to RTSP that describes how two independent RTSP sessions can be controlled in a coordinated, yet non-aggregate fashion. > Can you enlighten me as to where I'm wrong ? Now there is an effort underway to establish the MUTE/UNMUTE methods to temporarily "silence/unsilence" individual streams within a RTSP session as a extension to RTSP. In this case, however, the streams would still be tied to the timeline of the RTSP Session, where PLAY and PAUSE on the session would supercede the MUTE/UNMUTE methods. But I can see where my definitions for aggregate control and non-aggregate control could be a bit ambiguous, since obviously, there are methods such as SETUP and TEARDOWN, and even MUTE and UNMUTE that can work on individual media streams within a session. I'll see if I can clean it up to take these methods into account. We may just have to come up with more appropriate terminology. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 12:12:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04679 for ; Fri, 11 Jul 2003 12:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0V9-0006WV-R8 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 12:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BGC35c025069 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 12:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0V9-0006WG-Mt for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 12:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04667 for ; Fri, 11 Jul 2003 12:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0V8-0006oB-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 12:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b0V7-0006o8-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 12:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0V7-0006Vn-NF; Fri, 11 Jul 2003 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0UK-0006VD-GI for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 12:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04655 for ; Fri, 11 Jul 2003 12:11:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0UE-0006nt-00 for mmusic@ietf.org; Fri, 11 Jul 2003 12:11:06 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19b0UD-0006nq-00 for mmusic@ietf.org; Fri, 11 Jul 2003 12:11:05 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6BGB4Ii004075; Fri, 11 Jul 2003 18:11:04 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJ4BLA; Fri, 11 Jul 2003 18:11:03 +0200 Message-ID: <3F0EE198.2030106@ericsson.com> Date: Fri, 11 Jul 2003 18:11:04 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] stream switching References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, I have now had time to read your requirements draft and has some comments about this. I also have been rather heavily involved in the work within 3GPP to define bit-rate and content-rate adaptation so I have some comments based on this work. First, the goal of the stream switching work is in my opinion to: - Enable the receiver to receive interrupt free media at highest possible quality. To enable this the complete system must ensure the following things: - Congestion Control or rather adapting transmission rates to available network rate => avoiding high packet loss rates that severely effect quality. - Avoid that the receivers buffers either under flow (causes interrupt) or overflow (show up as packet loss). Based on this one can arrive at the conclusion that the media or content rate must be adapted, otherwise the underflow condition will be impossible to avoid. If one performs content adaptation towards lower bit-rates one must also perform adaptation towards higher rates. This I think is the basic requirement and assumptions that apply to your requirements draft. Based on this any solution can be divided up into different functionality blocks: - Transmission rate control, this functionality ensures that a sender does not send more data then the network can transport without being to unfair, or overflow network buffers. - Receiver buffer control, this functionality ensure that one does not overflow the client's receiver buffers. - Content rate control, functionality to ensure that the transmitted date fits the available network rate, while at the same time ensure that the receiver buffer does not underflow. Based on this functionality blocks one can use one or several protocols/solutions to realize them. They do not need to be separate and can utilize information enabled by any of the other functionality blocks. However I believe that all parts must be present to have a complete solution. Also how to realize the solutions is a not fixed by this. I would suggest that one tries to group the requirements regarding which of the functionalities they address. When one comes to solution one must start discussing what control paradigm one desires, as it will heavily influence the solution. Three different ones are: - Server controlled: In this the server is the responsible for all decisions regarding the adaptation. The client simply reports certain measurements that the server interprets. - Client controlled: The client makes the decisions and interpretations of what it see. Then it issues commands to the server that it must follow. The server is a simple slave. - Hybrid control: In a hybrid control scenario both client and servers makes decisions and interpretations of the data. I will not try to compare these solutions this if for future discussions. If one is interested in a server controlled solution one can look at the latest proposal in 3GPP SA4: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_27/Docs/S4-030501.zip Look at the buffer reporting mode variant. This proposal provides receiver buffer control and content rate control. The transmission rate control is handled through RTCP reports with enabled extended reports of packet loss vectors. Some more direct comments on the draft: 1. Introduction: The encoding could be done in real time allowing maximum flexibility in the produced content rate. However this is may not result in optimal encodings and are also very resource demanding for a server. 2. Section 2.1.1 and 2.1.2: I think the behaviour in this case should really be depending on the operators policies. I would not like to have my expensively paid on demand video reduced in quality if this network is of the type you describe. However I can see that we should enable this. 3. Section 2.2: I think you need to be a bit more clear that this is one example of a service. Also the AMR rate of 5 kbps is a bit to low. The 4.75 kbps mode has a quality that is not the best. However to achieve this bit-rate you must only send one AMR packet every 1.28 seconds, which means 64 amr frames per packet. This is not realistic as every packet will be required to reach the receiver to achieve acceptable quality. I would think that reasonable AMR qualities are using at least 10 packet every second, meaning that a header overhead of 3 kbps. 4. Section 2.5: I think this section assumes something that are not quite true. First the impossibility to signal this rate switch using current protocols. I claim it is possible but most likely not supported by any available client. To signal the rate switch in SDP you present one different RTP payload types for each codec and configuration, most likely at least 4 maybe 5. The 40 and 50 kbps AAC stereo may be possible to encode using the same AAC configuration. The declared payload types are present in a SDP. A client shall not accept the session and setup the media stream unless it can handle all these codecs. If it has setup this media stream it has in fact accepted that any of the codec may be used in the media stream. The server can here use different strategies when switching. The most likely one is to use a single SSRC and in the same RTP sequence number and timestamp space send the selected media quality. When the server switched this will be indicated by the new RTP PT. This has a slight problem as RTP/RTCP does not handle switched RTP TS rate perfectly. The client may in fact lose synchronization until it receives a RTCP packet after the switch has taken place. This happens if the packet where the RTP TS rate switches is lost. This is not a problem as long as the RTP TS rate before and after the payload type switch has the same TS rate. In other words not a problem for any video codec which all runs at 90000. This is more a problem for audio codecs. I would in fact try to address this problem with audio codecs by ensuring that any audio codec is allowed to select a RTP TS rate that is a even rate multiple of its native value. This would allow audio codecs to run at a the smallest common denominator rate. The other strategy at points of switching would be to use different SSRCs. This would violate the semantics that a SSRC represents a certain source. This also has some problems with the synchronization of the different SSRCs. This can't be done in RTSP as RTSP due to an erroneous definition of RTP-Info did not map each synchronization information to the SSRC. This can only be fixed through a new header due to backwards compatibility problems. Otherwise RTCP could be used. By sending SR for all SSRC one could in fact ensure that the synchronization is available. It will utilize more RTCP bandwidth. 5. Section 3.1.2: I don't think you should mix congestion control with adaptation control that hard. In my opinion, how drastic a content rate change is needed and how much depends on the clients buffer status. 6. Section 3.2.1: I think this directly falls under Transmission rate control and is a function of the congestion control mechanism. 7. Section 3.2.2.1: I don't think that this is a valid requirement. This is clearly an option that must be available. The controlling entity can trade off sending new data against retransmitting lost data. This trade off needs to be available to maximize quality. Further this can be done without causing congestion as long as the sender keeps to the available network rate. This is why splitting the functionality into different functionality blocks are so important. By having this model one can see that a server can have network rate N(t), content rate C(t) and retransmission rate R(t). The controlling entity must ensure that C(t)+R(t) <= N(t). Further the clients buffer allows that on short time scales R(t) can be equal to N(t) as long as enough data are available in the clients buffer. 8. Section 3.7: I don't think we can deploy a solution for switching that gives full functionality and at the same time is backwards compatible. However think on how one can maintain some of the functionality and being backwards compatible may be a worth the effort. However this is rather a design evaluation criteria than a requirement. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 13:19:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06733 for ; Fri, 11 Jul 2003 13:19:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1Y0-0004Ar-SZ for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 13:19:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BHJ49w016039 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 13:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1Y0-0004Ac-OS for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 13:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06713 for ; Fri, 11 Jul 2003 13:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1Xy-0007SN-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 13:19:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b1Xy-0007SK-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 13:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1Xx-0004AE-5x; Fri, 11 Jul 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1Wz-00049P-7G for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 13:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06700 for ; Fri, 11 Jul 2003 13:17:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1Wv-0007Rt-00 for mmusic@ietf.org; Fri, 11 Jul 2003 13:17:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19b1Wv-0007Rf-00 for mmusic@ietf.org; Fri, 11 Jul 2003 13:17:57 -0400 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.9/8.12.6) with ESMTP id h6BHHMro021819; Fri, 11 Jul 2003 10:17:24 -0700 (PDT) Received: from cisco.com (dhcp-171-71-97-84.cisco.com [171.71.97.84]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJA82233; Fri, 11 Jul 2003 10:15:02 -0700 (PDT) Message-ID: <3F0EF120.1070405@cisco.com> Date: Fri, 11 Jul 2003 10:17:20 -0700 From: Bill May User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aravind Narasimhan CC: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <20030630174155.GC25404@real.com> <3F042CF2.5050307@ericsson.com> <3F0DDBB0.2040001@sun.com> <3F0DE007.2020505@cisco.com> <3F0ECC63.6020900@sun.com> In-Reply-To: <3F0ECC63.6020900@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 Aravind Narasimhan wrote: > Secondly, as Tom and Magnus have mentioned, a > user may try to aggregate multiple streams in one RTSP session, where > there isnt a unified presentaiton description, or where someone has > ignored to put a session level aggregate control URL in the SDP. Now > the server has the right to say that it cannot aggregate the given media > URLs in a session, I will agree with this; however, it does not make sense for the client to create it's own aggregate URLS where the server does not specify one (given the SDP case). > but it does not make sense for the server to allow > two or more streams to be part of a session where each stream within the > session is going ot be controlled separately in a non-aggregate fashion. I'm sorry, but I do not understand. I can see a scenario where you might want to stop the video, but still maintain the audio. In this case, you have 2 or more streams running, and the client wishes to stop 1 of them. This is a perfectly legal scenario. Another would be a fast forward application, where you pause 1 or more streams while changing speeds on another. Can you please expand on why it doesn't make sense to allow streams to be controlled seperately ? I've done most of my work on the player side with the idea that the streams could be seperate, so most likely I'm missing something. > In the RTSP concalls of late, there was a general trend towards a > consensus that within a RTSP session, all streams should be "aggregately > controlled." In other words, once part of a session, an individual > media stream will be tied to the timeline of the session and will be > controlled in conjunction with the rest of the streams in the session. > So control methods such as PAUSE, PLAY would apply collectively to all > streams within the session. The upshot of this is that you cannot just > PLAY or PAUSE a single media stream within a session. Why ? To me, aggregate (or control of the entire session) control and non-aggregate control (or control based on each stream) can be used at the same time, and should be allowed. Perhaps I do not understand the argument why control over streams in a session is so difficult. Can you point me to some information about this ? The only thing I could see is that you might want to discourage changes to the overall timeline, ie:one stream going back 10 seconds from the rest of the presentation. But it would seem to me that would be an easy thing to prevent. > To achieve the notion of "non-aggregate control", or may be the more > appropriate term is "independent control" the consensus was that the > onus should be on the client to set up multiple RTSP sessions, each with > one or more media streams and manage them in a non-aggregate fashion. That seems non-intuitive to me -keeping twice as much information as needed. > To try to clearly specify the mechanisms of "non-aggregate" control of > individual media streams within a single session would probably cloud > and confuse the spec unnecessarily, since the functionality is easily > achievable by having multiple RTSP sessions that are controlled > independently. If this becomes a very serious requirement, someone can > write an extension to RTSP that describes how two independent RTSP > sessions can be controlled in a coordinated, yet non-aggregate fashion. I guess I'm not understanding why this would be difficult. The only limitation would be that the timeline must be consistent across all streams. Otherwise, control the streams to your heart's content. I apologize for being so dense. > Now there is an effort underway to establish the MUTE/UNMUTE methods to > temporarily "silence/unsilence" individual streams within a RTSP session > as a extension to RTSP. In this case, however, the streams would still > be tied to the timeline of the RTSP Session, where PLAY and PAUSE on the > session would supercede the MUTE/UNMUTE methods. I'm not sure that this buys you anything, if all a MUTE is is a PAUSE to an individual streams. It does sound like over-complicating (adding more states and breaking backward compatibility) to avoid a couple of sentences. > But I can see where my definitions for aggregate control and > non-aggregate control could be a bit ambiguous, since obviously, there > are methods such as SETUP and TEARDOWN, and even MUTE and UNMUTE that > can work on individual media streams within a session. I'll see if I > can clean it up to take these methods into account. We may just have to > come up with more appropriate terminology. Most likely that is why I do not understand. Bill _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 14:26:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09319 for ; Fri, 11 Jul 2003 14:26:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2av-0000Bd-Ii for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 14:26:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BIQ9X6000716 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 14:26:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2av-0000BT-Fz for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 14:26:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09305 for ; Fri, 11 Jul 2003 14:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b2as-0000SU-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 14:26:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b2as-0000SR-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 14:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2am-0000B1-VL; Fri, 11 Jul 2003 14:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2a5-00009r-24 for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 14:25:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09287 for ; Fri, 11 Jul 2003 14:25:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b2a2-0000Rq-00 for mmusic@ietf.org; Fri, 11 Jul 2003 14:25:14 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19b2a1-0000RA-00 for mmusic@ietf.org; Fri, 11 Jul 2003 14:25:13 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h6BIOC2B027038; Fri, 11 Jul 2003 11:24:13 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 11:24:12 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7C56@misty.packetvideo.com> From: Thomas Zeng To: "'Jonathan Rosenberg'" , mmusic@ietf.org Subject: RE: [MMUSIC] RTP denial of service Date: Fri, 11 Jul 2003 11:24:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Jonathan: Thanks for this timely work. I finally got a chance to review it, along with the email trail. Magnus asked a good question: doesn't STUN (RFC3489) require TLS ? See section 9.2: In order to ensure interoperability, this specification describes a TLS-based mechanism. This mechanism, described in this section, MUST be implemented by clients and servers. I suspect that some RTSP thin clients (those embedded in low-power devices) may not have enough resources (CPU and/or bandwidth) to run TLS... at the minimal, it adds more work to implementors of RTSP. Now, in section 5 of: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservi ce-00.txt You seem to imply that RTSP already follows Offer/Answer exchanges? I'd like to hear more on this subject... Thanks, - thomas -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 01, 2003 10:16 PM To: mmusic@ietf.org Subject: [MMUSIC] RTP denial of service Folks, I'd like to draw your attention to the following I-D that I submitted recently: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservi ce-00.txt This draft describes a denial-of-service attack using RTP. This attack can be launched using any protocol that uses an offer/answer-like SDP exchange, including SIP and RTSP. The draft also discusses ICE as a solution to the problem. Comments welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 11 16:29:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15476 for ; Fri, 11 Jul 2003 16:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4Vr-0000fL-GF for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 16:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BKT35X002555 for mmusic-archive@odin.ietf.org; Fri, 11 Jul 2003 16:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4Vr-0000f8-DD for mmusic-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 16:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15469 for ; Fri, 11 Jul 2003 16:28:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4Vp-0001tG-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 16:29:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b4Vp-0001tD-00 for mmusic-web-archive@ietf.org; Fri, 11 Jul 2003 16:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4Vp-0000ek-Hp; Fri, 11 Jul 2003 16:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4VZ-0000cg-At for mmusic@optimus.ietf.org; Fri, 11 Jul 2003 16:28:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15454 for ; Fri, 11 Jul 2003 16:28:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4VX-0001so-00 for mmusic@ietf.org; Fri, 11 Jul 2003 16:28:43 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19b4VV-0001sJ-00 for mmusic@ietf.org; Fri, 11 Jul 2003 16:28:42 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h6BKRt2C029514; Fri, 11 Jul 2003 13:27:55 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 13:27:55 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.com> From: Thomas Zeng To: "'Bill May'" , Aravind Narasimhan Cc: Magnus Westerlund , mmusic@ietf.org Subject: RE: [MMUSIC] Aggregate Control URI Date: Fri, 11 Jul 2003 13:27:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Bill: Based on my understanding of the discussions during the past RTSP tele conferences, I'd like to make a couple of comments. See below. - thomas > -----Original Message----- > From: Bill May [mailto:wmay@cisco.com] > Sent: Friday, July 11, 2003 10:17 AM > To: Aravind Narasimhan > Cc: Magnus Westerlund; mmusic@ietf.org > Subject: Re: [MMUSIC] Aggregate Control URI > > > > Aravind Narasimhan wrote: > > Secondly, as Tom and Magnus have mentioned, a > > user may try to aggregate multiple streams in one RTSP session, where > > there isnt a unified presentaiton description, or where someone has > > ignored to put a session level aggregate control URL in the SDP. Now > > the server has the right to say that it cannot aggregate the given media > > > URLs in a session, > > I will agree with this; however, it does not make sense for the client > to create it's own aggregate URLS where the server does not specify one > (given the SDP case). [Thomas Zeng] The bottom line is that PLAY is always an "aggregate" operation. Regardless of the control URI in the PLAY request, the sessionID will uniquely identify the media streams affected by the PLAY request. That is the spirit of draft-ietf-mmusic-rfc2326bis-04 (see section 11.4). In your case, if the SDP does not intend to support aggregate control (assume that the SDP does have more than one media tracks), it should NOT have used RTSP in the media level control URL. > > but it does not make sense for the server to allow > > two or more streams to be part of a session where each stream within the > > > session is going ot be controlled separately in a non-aggregate fashion. > > I'm sorry, but I do not understand. > > > I can see a scenario where you might want to stop the video, but still > maintain > the audio. In this case, you have 2 or more streams running, and the > client > wishes to stop 1 of them. This is a perfectly legal scenario. [Thomas Zeng] There are two ways to do what you want here: 1) issue teardown on the audio track. 2) perform a MUTE on the audio track. > Another would be a fast forward application, where you pause 1 or more > streams > while changing speeds on another. [Thomas Zeng] Again, you would use MUTE to pause 1 or more streams, then use PLAY with range to seek. > Can you please expand on why it doesn't make sense to allow streams to > be controlled seperately ? I've done most of my work on the player side > with > the idea that the streams could be seperate, so most likely I'm missing > something. [Thomas Zeng] If two streams belong to same RTSP session, and you issue PLAY on one stream, what would be the state of the overall session ? what would be the NPT (Normal Play Time) of the session? If I recall correctly, if PLAY/PAUSE were allowed on each track in a mutli-tracked RTSP session, the RTSP state machine would break. > > In the RTSP concalls of late, there was a general trend towards a > > consensus that within a RTSP session, all streams should be "aggregately > > > controlled." In other words, once part of a session, an individual > > media stream will be tied to the timeline of the session and will be > > controlled in conjunction with the rest of the streams in the session. > > So control methods such as PAUSE, PLAY would apply collectively to all > > streams within the session. The upshot of this is that you cannot just > > PLAY or PAUSE a single media stream within a session. > > Why ? To me, aggregate (or control of the entire session) control and > non-aggregate control (or control based on each stream) can be used > at the same time, and should be allowed. [Thomas Zeng] Yes, you are right here. The decision by the RTSP task force was to let PLAY/PAUSE be aggregate, while SETUP/TEARDOWN and MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an extension to RTSP core spec). > Perhaps I do not understand the argument why control over streams > in a session is so difficult. Can you point me to some information about > this ? > > The only thing I could see is that you might want to discourage changes > to the overall timeline, ie:one stream going back 10 seconds from the > rest of the presentation. > > But it would seem to me that would be an easy thing to prevent. > > > To achieve the notion of "non-aggregate control", or may be the more > > appropriate term is "independent control" the consensus was that the > > onus should be on the client to set up multiple RTSP sessions, each with > > > one or more media streams and manage them in a non-aggregate fashion. > > That seems non-intuitive to me -keeping twice as much information as > needed. > > > To try to clearly specify the mechanisms of "non-aggregate" control of > > individual media streams within a single session would probably cloud > > and confuse the spec unnecessarily, since the functionality is easily > > achievable by having multiple RTSP sessions that are controlled > > independently. If this becomes a very serious requirement, someone can > > write an extension to RTSP that describes how two independent RTSP > > sessions can be controlled in a coordinated, yet non-aggregate fashion. > > I guess I'm not understanding why this would be difficult. The only > limitation would be that the timeline must be consistent across all > streams. Otherwise, control the streams to your heart's content. [Thomas Zeng] Here the concern is on RTSP state machine. > I apologize for being so dense. > > > Now there is an effort underway to establish the MUTE/UNMUTE methods to > > temporarily "silence/unsilence" individual streams within a RTSP session > > > as a extension to RTSP. In this case, however, the streams would still > > be tied to the timeline of the RTSP Session, where PLAY and PAUSE on the > > > session would supercede the MUTE/UNMUTE methods. > > I'm not sure that this buys you anything, if all a MUTE is is a PAUSE to > an individual streams. It does sound like over-complicating (adding more > states and breaking backward compatibility) to avoid a couple of > sentences. > > > But I can see where my definitions for aggregate control and > > non-aggregate control could be a bit ambiguous, since obviously, there > > are methods such as SETUP and TEARDOWN, and even MUTE and UNMUTE that > > can work on individual media streams within a session. I'll see if I > > can clean it up to take these methods into account. We may just have to > > > come up with more appropriate terminology. > > Most likely that is why I do not understand. > > Bill > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 13 09:21:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19918 for ; Sun, 13 Jul 2003 09:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmp-0006wr-KZ for mmusic-archive@odin.ietf.org; Sun, 13 Jul 2003 09:21:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDL7bq026705 for mmusic-archive@odin.ietf.org; Sun, 13 Jul 2003 09:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmp-0006we-H7 for mmusic-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 09:21:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19880 for ; Sun, 13 Jul 2003 09:21:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bgmn-00049y-00 for mmusic-web-archive@ietf.org; Sun, 13 Jul 2003 09:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bgmn-00049s-00 for mmusic-web-archive@ietf.org; Sun, 13 Jul 2003 09:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmj-0006uS-MV; Sun, 13 Jul 2003 09:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmE-0006tt-Mk for mmusic@optimus.ietf.org; Sun, 13 Jul 2003 09:20:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19837 for ; Sun, 13 Jul 2003 09:20:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bgmC-000494-00 for mmusic@ietf.org; Sun, 13 Jul 2003 09:20:28 -0400 Received: from [81.160.147.212] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19bgmB-000491-00 for mmusic@ietf.org; Sun, 13 Jul 2003 09:20:27 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6DDKUA6023887 for ; Sun, 13 Jul 2003 14:20:30 +0100 (BST) (envelope-from csp@csperkins.org) Date: Sun, 13 Jul 2003 15:20:30 +0200 From: Colin Perkins To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-04.txt Message-Id: <20030713152030.5843347a.csp@csperkins.org> In-Reply-To: <200306261510.LAA00582@ietf.org> References: <200306261510.LAA00582@ietf.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A number of people raised concerns with the previous version of this draft. Does this revision address those concerns? Colin --> Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiparty Multimedia > Session Control Working Group of the IETF. > > Title : A Transport Independent Bandwidth Modifier for the > Session Description Protocol (SDP) > Author(s) : M. Westerlund > Filename : draft-ietf-mmusic-sdp-bwparam-04.txt > Pages : 18 > Date : 2003-6-26 > > The existing Session Description Protocol (SDP) bandwidth modifiers > and their values include the bandwidth needed also for the transport > and IP layers. When using SDP with protocols like the Session > Announcement Protocol (SAP), the Session Initiation Protocol (SIP) > and the Real-Time Streaming Protocol (RTSP) and when the involved > hosts reside in networks running different IP versions, the > interpretation of what lower layer bandwidths are included is not > clear. This document defines a bandwidth modifier that does not > include transport overhead; instead an additional packet rate > attribute is defined. The transport independent bit-rate value > together with the maximum packet rate can then be used to calculate > the real bit-rate over the transport actually used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username"anonymous" and a password of your e-mail address. After logging > in, type "cd internet-drafts" and then > "get draft-ietf-mmusic-sdp-bwparam-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 13 23:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12706 for ; Sun, 13 Jul 2003 23:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bu6H-00082X-Gn for mmusic-archive@odin.ietf.org; Sun, 13 Jul 2003 23:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E3Y5Or030901 for mmusic-archive@odin.ietf.org; Sun, 13 Jul 2003 23:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bu6H-00082K-DO for mmusic-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 23:34:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12697 for ; Sun, 13 Jul 2003 23:34:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bu6F-00011K-00 for mmusic-web-archive@ietf.org; Sun, 13 Jul 2003 23:34:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bu6E-00011H-00 for mmusic-web-archive@ietf.org; Sun, 13 Jul 2003 23:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bu6D-00081f-2F; Sun, 13 Jul 2003 23:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bu5y-00081J-1S for mmusic@optimus.ietf.org; Sun, 13 Jul 2003 23:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12684 for ; Sun, 13 Jul 2003 23:33:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bu5v-00010s-00 for mmusic@ietf.org; Sun, 13 Jul 2003 23:33:44 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19bu5u-00010p-00 for mmusic@ietf.org; Sun, 13 Jul 2003 23:33:43 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sun, 13 Jul 2003 20:21:46 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.218] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Sun, 13 Jul 2003 20:21:46 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Sun, 13 Jul 2003 20:28:19 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19bu1A-00020w-00 for ; Sun, 13 Jul 2003 20:28:48 -0700 Date: Sun, 13 Jul 2003 20:27:39 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_10,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #82 - 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-770522 ] Request to response time is not limited. (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Sun, 13 Jul 2003 07:00:04 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-770522 ] Request to response time is not limited. Bugs item #770522, was opened at 2003-07-13 16:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Request to response time is not limited. Initial Comment: The time a server is expected to respond to a request in is not defined. This may create interoperability issues that a certain client timesout while another will wait. We should define some time limits for this. Then a server can know that a request needs to be adressed in a certain time. If the server processing takes to long time the server can send a 1xx code to indicate the request as being under processing. The SIP spec can provide hints on how to solve this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 06:13:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05047 for ; Mon, 14 Jul 2003 06:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0KN-0008Kw-Fv for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 06:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EAD3WL032042 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 06:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0KN-0008Kj-Cg for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:13:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05024 for ; Mon, 14 Jul 2003 06:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0KJ-0003hj-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 06:12:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0KJ-0003hg-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 06:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0KL-0008KL-Bn; Mon, 14 Jul 2003 06:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0JO-0008IN-8M for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 06:12:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05011 for ; Mon, 14 Jul 2003 06:11:57 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0JK-0003hU-00 for mmusic@ietf.org; Mon, 14 Jul 2003 06:11:58 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19c0JJ-0003hR-00 for mmusic@ietf.org; Mon, 14 Jul 2003 06:11:57 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 3A99B54AEF; Mon, 14 Jul 2003 12:11:57 +0200 (MET DST) Received: from smtprelay-nl2.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 MAA27474; Mon, 14 Jul 2003 12:11:56 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id MAA23804; Mon, 14 Jul 2003 12:11:55 +0200 (MEST) Subject: Re: [MMUSIC] stream switching To: Magnus Westerlund Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 14 Jul 2003 12:02:36 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 14/07/2003 12:13:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, you wrote: >Hi Philippe, > Hi Magnus, thank you for the feedback! It will definetely help me in the job of improving this draft. > >I have now had time to read your requirements draft and has some >comments about this. I also have been rather heavily involved in the >work within 3GPP to define bit-rate and content-rate adaptation so I >have some comments based on this work. > >First, the goal of the stream switching work is in my opinion to: >- Enable the receiver to receive interrupt free media at highest >possible quality. > sure, if this is not obvious from the "requirement" draft then I need to reword the introduction! >To enable this the complete system must ensure the following things: >- Congestion Control or rather adapting transmission rates to available >network rate => avoiding high packet loss rates that severely effect >quality. yes >- Avoid that the receivers buffers either under flow (causes interrupt) >or overflow (show up as packet loss). > yes, this is fundamental for seamless-ness >Based on this one can arrive at the conclusion that the media or content >rate must be adapted, otherwise the underflow condition will be >impossible to avoid. If one performs content adaptation towards lower >bit-rates one must also perform adaptation towards higher rates. > I am not sure about this "must", could it be that your are considering differently media rate and transmission rate ? because I am not considering changing the transmission rate (as a end-to-end application issue) => stream switching is only about changing the *media* rate. what I want to mean is you dont *need* to increase the media rate to avoid undeflows but instead you may *want* to increase the media rate in order to improve the user experience in terms of image quality... >This I think is the basic requirement and assumptions that apply to your >requirements draft. > >Based on this any solution can be divided up into different >functionality blocks: > >- Transmission rate control, this functionality ensures that a sender >does not send more data then the network can transport without being to >unfair, or overflow network buffers. > hum, again i prefer the term "media rate control" if you dont mind? >- Receiver buffer control, this functionality ensure that one does not >overflow the client's receiver buffers. > yes, not sure there is much to "do" there in terms of IETF spec? >- Content rate control, functionality to ensure that the transmitted >date fits the available network rate, while at the same time ensure that >the receiver buffer does not underflow. > yes! this is stream switching principle, but again it is about "media rate", not changing the transmission rate. >Based on this functionality blocks one can use one or several >protocols/solutions to realize them. They do not need to be separate and >can utilize information enabled by any of the other functionality >blocks. However I believe that all parts must be present to have a >complete solution. Also how to realize the solutions is a not fixed by >this. > >I would suggest that one tries to group the requirements regarding which >of the functionalities they address. > Which groups would you suggest ? >When one comes to solution one must start discussing what control >paradigm one desires, as it will heavily influence the solution. Three >different ones are: >- Server controlled: In this the server is the responsible for all >decisions regarding the adaptation. The client simply reports certain >measurements that the server interprets. > >- Client controlled: The client makes the decisions and interpretations >of what it see. Then it issues commands to the server that it must >follow. The server is a simple slave. > slave, yes, but a slave that *could* refuse to obey ;-) e.g. as discussed in my draft for rate control a server must be allowed to deny a request for a higher data rate... >- Hybrid control: In a hybrid control scenario both client and servers >makes decisions and interpretations of the data. > >I will not try to compare these solutions this if for future >discussions. If one is interested in a server controlled solution one >can look at the latest proposal in 3GPP SA4: >http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_27/Docs/S4-030501.zip >Look at the buffer reporting mode variant. This proposal provides >receiver buffer control and content rate control. The transmission rate >control is handled through RTCP reports with enabled extended reports of >packet loss vectors. > I have to say that using such RTCP extensions looks very much like "client control" to me ;-) but I dont really care about the terminology ;-) > >Some more direct comments on the draft: > >1. Introduction: The encoding could be done in real time allowing >maximum flexibility in the produced content rate. However this is may >not result in optimal encodings and are also very resource demanding for >a server. > yes, I did not mention this possibility because in large scale media distribution this would effectively require one "production" encoder per client, which is -even in several years from now- way beyond the cost points for this type of products. >2. Section 2.1.1 and 2.1.2: I think the behaviour in this case should >really be depending on the operators policies. I would not like to have >my expensively paid on demand video reduced in quality if this network >is of the type you describe. However I can see that we should enable this. Yes, you are right, all this assumes the correct commercial agreements are in place. Our experience is however that a end user always prefers a continuous playback, even a degraded one, providing that the degradation is "resonable", all other solutions including "freezes" for rebuffereing are not acceptable for the wide public who is accustomed to TV ;-( From an IETF point of view (hey, just giving my own opinion ;-) I think it would be a good idea that implementations *by default* would "behave a la TFRC" rather than what we have today, because otherwise -as sally floyd pointed out this morning- we would run into rather nasty trouble. > >3. Section 2.2: I think you need to be a bit more clear that this is one >example of a service. Also the AMR rate of 5 kbps is a bit to low. The >4.75 kbps mode has a quality that is not the best. However to achieve >this bit-rate you must only send one AMR packet every 1.28 seconds, >which means 64 amr frames per packet. This is not realistic as every >packet will be required to reach the receiver to achieve acceptable >quality. I would think that reasonable AMR qualities are using at least >10 packet every second, meaning that a header overhead of 3 kbps. > right. >4. Section 2.5: I think this section assumes something that are not >quite true. First the impossibility to signal this rate switch using >current protocols. What *is* impossible is to find a comprehensive spec for stream switching !-) and it is my intention to provide one, i would love to "use the current protocols"! >I claim it is possible but most likely not supported >by any available client. And that would be the point in writing that spec... >To signal the rate switch in SDP you present >one different RTP payload types for each codec and configuration, most >likely at least 4 maybe 5. The 40 and 50 kbps AAC stereo may be possible >to encode using the same AAC configuration. The declared payload types >are present in a SDP. A client shall not accept the session and setup >the media stream unless it can handle all these codecs. If it has setup >this media stream it has in fact accepted that any of the codec may be >used in the media stream. > well, I completely agree that *that* may be a solution to stream switching, the point then would be to document it!-) >The server can here use different strategies when switching. The most >likely one is to use a single SSRC and in the same RTP sequence number >and timestamp space send the selected media quality. agreed, this is a very nice possibility...that obvioulsy we would need to *seriouly* document ... because this is not the "default" thing at all from existing specs, right? >When the server >switched this will be indicated by the new RTP PT. This has a slight >problem as RTP/RTCP does not handle switched RTP TS rate perfectly. The >client may in fact lose synchronization until it receives a RTCP packet >after the switch has taken place. right! that is a key issue! >This happens if the packet where the >RTP TS rate switches is lost. This is not a problem as long as the RTP >TS rate before and after the payload type switch has the same TS rate. >In other words not a problem for any video codec which all runs at >90000. yes, not a problem *if* (as mentionned above) you mandate the same RTPTS space for all streams ... >This is more a problem for audio codecs. I would in fact try to >address this problem with audio codecs by ensuring that any audio codec >is allowed to select a RTP TS rate that is a even rate multiple of its >native value. This would allow audio codecs to run at a the smallest >common denominator rate. > Is it always possible/efficient? >The other strategy at points of switching would be to use different >SSRCs. This would violate the semantics that a SSRC represents a certain >source. This also has some problems with the synchronization of the >different SSRCs. This can't be done in RTSP as RTSP due to an erroneous >definition of RTP-Info did not map each synchronization information to >the SSRC. This can only be fixed through a new header due to backwards >compatibility problems. Otherwise RTCP could be used. By sending SR for >all SSRC one could in fact ensure that the synchronization is available. >It will utilize more RTCP bandwidth. > Hum, so we should disregard this option? >5. Section 3.1.2: I don't think you should mix congestion control with >adaptation control that hard. In my opinion, how drastic a content rate >change is needed and how much depends on the clients buffer status. > sorry, I do not understand that one? >6. Section 3.2.1: I think this directly falls under Transmission rate >control and is a function of the congestion control mechanism. > >7. Section 3.2.2.1: I don't think that this is a valid requirement. This >is clearly an option that must be available. The controlling entity can >trade off sending new data against retransmitting lost data. This trade >off needs to be available to maximize quality. Further this can be done >without causing congestion as long as the sender keeps to the available >network rate. This is why splitting the functionality into different >functionality blocks are so important. By having this model one can see >that a server can have network rate N(t), content rate C(t) and >retransmission rate R(t). The controlling entity must ensure that >C(t)+R(t) <= N(t). Further the clients buffer allows that on short time >scales R(t) can be equal to N(t) as long as enough data are available in >the clients buffer. fully aggreed, the point was to explain that FEC increases the data rate (which a lot of people seem not to be aware of !-) but I agree recommending "not using FEC" is too blunt > >8. Section 3.7: I don't think we can deploy a solution for switching >that gives full functionality and at the same time is backwards >compatible. However think on how one can maintain some of the >functionality and being backwards compatible may be a worth the effort. >However this is rather a design evaluation criteria than a requirement. > do you mean it is not appropriate to have backward compatibility as a requirement? Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 08:41:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15690 for ; Mon, 14 Jul 2003 08:41:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2dj-0002cc-Rt for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 08:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ECfBtw010079 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 08:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2di-0002cR-JY for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 08:41:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15642 for ; Mon, 14 Jul 2003 08:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2df-0006Xp-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 08:41:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c2de-0006Xm-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 08:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2da-0002bn-SN; Mon, 14 Jul 2003 08:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2d1-0002aw-1s for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 08:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15553 for ; Mon, 14 Jul 2003 08:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2cz-0006WR-00 for mmusic@ietf.org; Mon, 14 Jul 2003 08:40:25 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19c2cy-0006WK-00 for mmusic@ietf.org; Mon, 14 Jul 2003 08:40:24 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6ECeNGJ021103; Mon, 14 Jul 2003 14:40:23 +0200 (MEST) Received: from ericsson.com (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366BW3R0; Mon, 14 Jul 2003 14:40:25 +0200 Message-ID: <3F12A4B4.9060900@ericsson.com> Date: Mon, 14 Jul 2003 14:40:20 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] stream switching References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Phillipe, I hope that I can clarify anything that was unclear. I also has some further comments, see below. philippe.gentric@philips.com wrote: >Magnus, you wrote: > > >>To enable this the complete system must ensure the following things: >>- Congestion Control or rather adapting transmission rates to available >>network rate => avoiding high packet loss rates that severely effect >>quality. >> >> > > yes > > > >>- Avoid that the receivers buffers either under flow (causes interrupt) >>or overflow (show up as packet loss). >> >> >> > > yes, this is fundamental for seamless-ness > > > >>Based on this one can arrive at the conclusion that the media or content >>rate must be adapted, otherwise the underflow condition will be >>impossible to avoid. If one performs content adaptation towards lower >>bit-rates one must also perform adaptation towards higher rates. >> >> >> > > I am not sure about this "must", could it be that your are > considering differently media rate and transmission rate ? > > What I mean is that if the available transmission rate is less the media rate then you on some time scale if nothing changes you will empty your buffer. Therefore you "must" change the media rate to avoid this or have interrupts. I don't know about any other solution. > because I am not considering changing the transmission rate (as a > end-to-end application issue) => stream switching is only about > changing the *media* rate. > I don't think you can exclude the transmission rate from the equation. In my opinion you need to consider transmission rate, receiver buffers, and the media rate all together. > > what I want to mean is you dont *need* to increase the media rate > to avoid undeflows but instead you may *want* to increase the > media rate in order to improve the user experience in terms of > image quality... > I am not sure what you mean, but I guess the following. In cases you are not transmission rate limited one is not required to increase the media rate, however it is commonly desired. I can agree that there are some need to allow the receiver to specify what is allowed in respect to media rate modifications. > > > >>This I think is the basic requirement and assumptions that apply to your >>requirements draft. >> >>Based on this any solution can be divided up into different >>functionality blocks: >> >>- Transmission rate control, this functionality ensures that a sender >>does not send more data then the network can transport without being to >>unfair, or overflow network buffers. >> >> >> > > hum, again i prefer the term "media rate control" if you dont mind? > No, I don't think you completely understand. In a system where the buffer space is known you don't have to transmit the data in the same rate as the media rate. Due to the buffer one can during some parts of the session transmit data at rates that are both higher and lower than the media rate. However when doing this you need to ensure that you are not under or overflowing the receiver buffer. What you try to do is to simplify this system to basically say that the transmission rate is equal to media rate which I think prevents better performance. If any one does not understand this, please prod me and I will try to provide a better explanation of the complete system. > > > >>- Receiver buffer control, this functionality ensure that one does not >>overflow the client's receiver buffers. >> >> >> > > yes, not sure there is much to "do" there in terms of IETF spec? > There is nothing in IETF that allows feedback or even specification about the receiver buffers to or by the sending side. This is analogous to TCP's receiver window that allow to control the flow of media. > > > > >>- Content rate control, functionality to ensure that the transmitted >>date fits the available network rate, while at the same time ensure that >>the receiver buffer does not underflow. >> >> >> > > yes! this is stream switching principle, but again it is about > "media rate", not changing the transmission rate. > This I can agree is what you describe as media rate control. By selecting or controlling the media rate one can meet the requirements of transmission rate and receiver buffers. > > > >>Based on this functionality blocks one can use one or several >>protocols/solutions to realize them. They do not need to be separate and >>can utilize information enabled by any of the other functionality >>blocks. However I believe that all parts must be present to have a >>complete solution. Also how to realize the solutions is a not fixed by >>this. >> >>I would suggest that one tries to group the requirements regarding which >>of the functionality's they address. >> >> >> > > Which groups would you suggest ? > Some suggestions would be: Media requirements: Requirements to prevent the media from being corrupted or worsen quality, like limited packet losses, gap free switching, RAP,etc. Signalling requirements: Requirements that are a related to what the signalling mechanism needs to achieve. System requirements: Requirements that have more general feeling, like backwards compatibility, etc. > > > > >>When one comes to solution one must start discussing what control >>paradigm one desires, as it will heavily influence the solution. Three >>different ones are: >>- Server controlled: In this the server is the responsible for all >>decisions regarding the adaptation. The client simply reports certain >>measurements that the server interprets. >> >>- Client controlled: The client makes the decisions and interpretations >>of what it see. Then it issues commands to the server that it must >>follow. The server is a simple slave. >> >> >> > > slave, yes, but a slave that *could* refuse to obey ;-) e.g. as > discussed in my draft for rate control a server must be allowed to > deny a request for a higher data rate... > > > In a true client control paradigm, this may not even be true. But the basic point is that the requirements may motivate the choice, but we should not choice a a paradigm and then write the requirements to fulfil them. I have a rather long list of comments to when this discussion needs to be started. > > >>- Hybrid control: In a hybrid control scenario both client and servers >>makes decisions and interpretations of the data. >> >>I will not try to compare these solutions this if for future >>discussions. If one is interested in a server controlled solution one >>can look at the latest proposal in 3GPP SA4: >>http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_27/Docs/S4-030501.zip >>Look at the buffer reporting mode variant. This proposal provides >>receiver buffer control and content rate control. The transmission rate >>control is handled through RTCP reports with enabled extended reports of >>packet loss vectors. >> >> >> > > I have to say that using such RTCP extensions looks very much like > "client control" to me ;-) but I dont really care about the > terminology ;-) > Actually the mechanism in my opinion is very server controlled. The client provides the server side with some parameters telling it what to achieve. Then the client provides regular feedback to allow the server to run the algorithms and control the whole system. > > > > >>Some more direct comments on the draft: >> >>1. Introduction: The encoding could be done in real time allowing >>maximum flexibility in the produced content rate. However this is may >>not result in optimal encodings and are also very resource demanding for >>a server. >> >> >> > > > yes, I did not mention this possibility because in large scale > media distribution this would effectively require one "production" > encoder per client, which is -even in several years from now- way > beyond the cost points for this type of products. > > I think that spending two sentences on this is useful, just to make it clear that it has been considered but has significant problems. > > > >>2. Section 2.1.1 and 2.1.2: I think the behaviour in this case should >>really be depending on the operators policies. I would not like to have >>my expensively paid on demand video reduced in quality if this network >>is of the type you describe. However I can see that we should enable this. >> >> > > > Yes, you are right, all this assumes the correct commercial > agreements are in place. Our experience is however that a end user > always prefers a continuous playback, even a degraded one, > providing that the degradation is "resonable", all other solutions > including "freezes" for rebuffereing are not acceptable for the > wide public who is accustomed to TV ;-( > >From an IETF point of view (hey, just giving my own opinion ;-) >I think it would be a good idea that implementations *by default* >would "behave a la TFRC" rather than what we have today, >because otherwise -as sally floyd pointed out this morning- >we would run into rather nasty trouble. > Yes, I agree that over any best effort network you need some type of congestion avoidance. So default behaviour is good, however we must also allow for systems that has QoS agreements. > > > > >>3. Section 2.2: I think you need to be a bit more clear that this is one >>example of a service. Also the AMR rate of 5 kbps is a bit to low. The >>4.75 kbps mode has a quality that is not the best. However to achieve >>this bit-rate you must only send one AMR packet every 1.28 seconds, >>which means 64 amr frames per packet. This is not realistic as every >>packet will be required to reach the receiver to achieve acceptable >>quality. I would think that reasonable AMR qualities are using at least >>10 packet every second, meaning that a header overhead of 3 kbps. >> >> >> > > right. > > > >>4. Section 2.5: I think this section assumes something that are not >>quite true. First the impossibility to signal this rate switch using >>current protocols. >> >> > > What *is* impossible is to find a comprehensive spec for stream > switching !-) and it is my intention to provide one, i would love to > "use the current protocols"! > > > >>I claim it is possible but most likely not supported >>by any available client. >> >> > > And that would be the point in writing that spec... > > > >>To signal the rate switch in SDP you present >>one different RTP payload types for each codec and configuration, most >>likely at least 4 maybe 5. The 40 and 50 kbps AAC stereo may be possible >>to encode using the same AAC configuration. The declared payload types >>are present in a SDP. A client shall not accept the session and setup >>the media stream unless it can handle all these codecs. If it has setup >>this media stream it has in fact accepted that any of the codec may be >>used in the media stream. >> >> >> > > well, I completely agree that *that* may be a solution to stream > switching, the point then would be to document it!-) > > Good, then you should rather document this deficiency rather than claiming that it is possible. > > > >>The server can here use different strategies when switching. The most >>likely one is to use a single SSRC and in the same RTP sequence number >>and timestamp space send the selected media quality. >> >> > > agreed, this is a very nice possibility...that obvioulsy we would > need to *seriouly* document ... because this is not the "default" > thing at all from existing specs, right? > > > I have seen it as being the default behaviour, however this is nothing that has been thoroughly discussed in AVT and the RTP spec not be that clear on this point. Documenting this would be a good thing. > > >>When the server >>switched this will be indicated by the new RTP PT. This has a slight >>problem as RTP/RTCP does not handle switched RTP TS rate perfectly. The >>client may in fact lose synchronization until it receives a RTCP packet >>after the switch has taken place. >> >> > > right! that is a key issue! > > > >>This happens if the packet where the >>RTP TS rate switches is lost. This is not a problem as long as the RTP >>TS rate before and after the payload type switch has the same TS rate. >>In other words not a problem for any video codec which all runs at >>90000. >> >> > > yes, not a problem *if* (as mentioned above) you mandate the same > RTPTS space for all streams ... > > > >>This is more a problem for audio codecs. I would in fact try to >>address this problem with audio codecs by ensuring that any audio codec >>is allowed to select a RTP TS rate that is a even rate multiple of its >>native value. This would allow audio codecs to run at a the smallest >>common denominator rate. >> >> >> > > Is it always possible/efficient? > No, not for the currently specified RTP payload formats. It is something I will recommend in future payload formats to allow for this functionality. > > > >>The other strategy at points of switching would be to use different >>SSRCs. This would violate the semantics that a SSRC represents a certain >>source. This also has some problems with the synchronization of the >>different SSRCs. This can't be done in RTSP as RTSP due to an erroneous >>definition of RTP-Info did not map each synchronization information to >>the SSRC. This can only be fixed through a new header due to backwards >>compatibility problems. Otherwise RTCP could be used. By sending SR for >>all SSRC one could in fact ensure that the synchronization is available. >>It will utilize more RTCP bandwidth. >> >> >> > >Hum, so we should disregard this option? > I think so. > > > >>5. Section 3.1.2: I don't think you should mix congestion control with >>adaptation control that hard. In my opinion, how drastic a content rate >>change is needed and how much depends on the clients buffer status. >> >> >> > >sorry, I do not understand that one? > This has to do with the complete system that a sender can transmit at one rate, while the media rate has another rate. The discrepancy is handled by the receiver buffer. Therefore the control of the media rate can be performed more drastic or not depending on what the buffer status is. An almost empty receiver buffer needs to be handled quickly and drastically, probably be reducing the media rate significantly. If the buffer are rather full the handling of this can be much less drastic, a small discrepancy can simply be tried to waited out. Or the quality change can be minimal. > > > > > >>8. Section 3.7: I don't think we can deploy a solution for switching >>that gives full functionality and at the same time is backwards >>compatible. However think on how one can maintain some of the >>functionality and being backwards compatible may be a worth the effort. >>However this is rather a design evaluation criteria than a requirement. >> >> >> > > do you mean it is not appropriate to have backward compatibility as > a requirement? > > > It might, however I think it should be further considered. I think listing the level as critical is to high level. Cheers Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 11:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27763 for ; Mon, 14 Jul 2003 11:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c54a-0003LI-2J for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 11:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFH4al012842 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 11:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c54Z-0003L3-UQ for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:17:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27749 for ; Mon, 14 Jul 2003 11:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c54Y-0001LZ-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 11:17:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c54Y-0001LV-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 11:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c54X-0003Ka-Op; Mon, 14 Jul 2003 11:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4ub-00027d-FQ for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 11:06:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27294 for ; Mon, 14 Jul 2003 11:06:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4uY-0001EZ-00 for mmusic@ietf.org; Mon, 14 Jul 2003 11:06:42 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19c4uX-0001EK-00 for mmusic@ietf.org; Mon, 14 Jul 2003 11:06:42 -0400 Received: from localhost.localdomain ([81.160.186.131]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6EF6Ak10047; Mon, 14 Jul 2003 17:06:10 +0200 (MEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6EF5gcJ002307; Mon, 14 Jul 2003 18:05:42 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h6EF5f4w002306; Mon, 14 Jul 2003 18:05:41 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: mmusic@ietf.org Cc: csp@csperkins.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Reply-To: pessi@iki.fi In-Reply-To: <200305231412.KAA06476@ietf.org> ("Internet-Drafts@ietf.org"'s message of "Fri, 23 May 2003 10:12:53 -0400") References: <200305231412.KAA06476@ietf.org> Date: Mon, 14 Jul 2003 18:05:41 +0300 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MMUSIC] Inconsistency in draft-ietf-mmusic-sdp-new-13.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hello all, In the sdp-new, there seems to be a contradiction between the ABNF definition of "token-char" and comments after the definition: token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E ; definition from RFC 2045 - ; "any (US-ASCII) CHAR except SPACE, CTLs, ; or tspecials". ; the tspecials are ()<>@,;: According to the ABNF, the tspecials include quote (%22, "), slash (%2F, /), equal (%3D, =), question mark (%3f, ?), square brackets (%5B, [ and %5D, ]), and backslash (%5C, \), too: ; the tspecials are ()/<>@,;:"=?[\] As it looks like that the sdp-new-14 is recycled once more, so it is possible to fix the comment there (or ABNF, if that is more appropriate). --Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 13:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06076 for ; Mon, 14 Jul 2003 13:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6uq-0002S8-2W for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 13:15:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHF8Vu009424 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 13:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6up-0002Rv-Ts for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06055 for ; Mon, 14 Jul 2003 13:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c6uo-0003Op-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 13:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c6un-0003Om-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 13:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6uk-0002RW-80; Mon, 14 Jul 2003 13:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6uF-0002Qr-5I for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 13:14:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06047 for ; Mon, 14 Jul 2003 13:14:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c6uD-0003Oe-00 for mmusic@ietf.org; Mon, 14 Jul 2003 13:14:29 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19c6uC-0003OU-00 for mmusic@ietf.org; Mon, 14 Jul 2003 13:14:28 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6EHEMGJ000900 for ; Mon, 14 Jul 2003 19:14:22 +0200 (MEST) Received: from ericsson.com (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 3S627LCZ; Mon, 14 Jul 2003 19:17:09 +0200 Message-ID: <3F12E4EB.4050404@ericsson.com> Date: Mon, 14 Jul 2003 19:14:19 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, On wednesday at dinner time there will be a as proposed in the MMUSIC agenda an RTSP discussion meeting. The preliminary meeting place is in the main foyer near the registration counter at 17.30-17.40. We will try to put together an agenda for this meeting during tomorrow. However this mail is about something else, namely the RTSP and NAT traversal document. This is a preparation for what will be further discussed during wednesday and thursday and concerns open issues. Issue number one: What is the goal of the RTSP & NAT document. This has previous been communicated as documenting solutions that do not require further standardization and to give guidelines for RTSP ALGs and how to handle firewalls. However it is evident that we need a solution for traversal of symmetric NATs for RTSP. As all known possible solutions requires server side extensions to work, further requirements for this work should be considered. Possible other considerations for this work is: - Enable RTSP servers to be placed behind a NAT. Will allow for implementing RTSP server for other purposes than on-demand content and provide a richer usage of RTSP. - Provide mitigation of the RTP DoS attack threat. It can't be completely solved, however it can be severely limited to only be possible to perform by attackers that can hijack traffic inside a network. And as a an attacker having this possibilities can do many other really bad stuff, this is probably enough. - Do not worsen security. We should do anything to avoid worsening security for RTSP. - Have only a single solution to provide interoperability and incentive to implement this solution. - Consider complexity of operations and implementation for any proposal. - Time to availability of solution. So please consider if you have any further requirements that should be consider for this work. We should in the next weeks have some consensus on what work we should perform regarding the solution for symmetric NATs and RTSP. The result of this discussion will be used to decide on what solution to select. The current proposals to a solution for the symmetric NAT traversal are: - Symmetric RTP - Co-located STUN - ICE for RTSP They are documented in the draft-ietf-mmusic-rtsp-nat-01.txt. Please read and comment so that we can start putting an analysis together. Best Regards Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 13:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07815 for ; Mon, 14 Jul 2003 13:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Lp-0004Sj-Or for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 13:43:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHh1PB017147 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Lp-0004SU-LT for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:43:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07761 for ; Mon, 14 Jul 2003 13:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Ln-0003pV-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 13:42:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7Lm-0003pS-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 13:42:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Lo-0004S5-Bb; Mon, 14 Jul 2003 13:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7L1-0004Pa-KQ for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 13:42:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07705 for ; Mon, 14 Jul 2003 13:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Kz-0003og-00 for mmusic@ietf.org; Mon, 14 Jul 2003 13:42:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19c7Ky-0003oC-00 for mmusic@ietf.org; Mon, 14 Jul 2003 13:42:08 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2003 10:40:41 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6EHfXuF019372; Mon, 14 Jul 2003 10:41:35 -0700 (PDT) Received: from cisco.com (dhcp-171-71-97-84.cisco.com [171.71.97.84]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJC96499; Mon, 14 Jul 2003 10:38:41 -0700 (PDT) Message-ID: <3F12EB45.7080003@cisco.com> Date: Mon, 14 Jul 2003 10:41:25 -0700 From: Bill May User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: Aravind Narasimhan , Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.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 Thomas, I think that we can agree that this new specification would not be backward compatible with existing RTSP session. To me, it does not seem like for good reason. Not enough bang for the buck, but perhaps I am still missing something. As long as you are aware of this and have done so intentionally, that's cool. But IMO, I would not not be making these changes (adding MUTE, requiring PLAY/PAUSE to be aggregate as opposed to stream based) in order to make wording or a state machine clearer. In fact, the MUTE complicates the state machine in the exact same way that a non-aggregate PAUSE does. More below: Thomas Zeng wrote: >>I can see a scenario where you might want to stop the video, but still >>maintain >>the audio. In this case, you have 2 or more streams running, and the >>client >>wishes to stop 1 of them. This is a perfectly legal scenario. > > [Thomas Zeng] There are two ways to do what you want here: 1) issue > teardown on the audio track. 2) perform a MUTE on the audio track. Doesn't teardown now need to be aggregate ? So that wouldn't work. >>Can you please expand on why it doesn't make sense to allow streams to >>be controlled seperately ? I've done most of my work on the player side >>with >>the idea that the streams could be seperate, so most likely I'm missing >>something. > > [Thomas Zeng] If two streams belong to same RTSP session, and you > issue PLAY on one stream, what would be the state of the overall session ? > what would be the NPT (Normal Play Time) of the session? If I recall > correctly, if PLAY/PAUSE were allowed on each track in a mutli-tracked RTSP > session, the RTSP state machine would break. I'm not sure that I understand why the state of the session is important. The server would be issueing the required streams. The NPT of the session would be whatever the player decided it would be - it can derive this from the RTPInfo, and decide how it wants to deal with it. Are you defining a specification on how to develop a server (which is what a state machine would imply) ? Or a method of interoperability ? >>Why ? To me, aggregate (or control of the entire session) control and >>non-aggregate control (or control based on each stream) can be used >>at the same time, and should be allowed. > > [Thomas Zeng] Yes, you are right here. The decision by the RTSP > task force was to let PLAY/PAUSE be aggregate, while SETUP/TEARDOWN and > MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an extension to > RTSP core spec). I'm not sure I understand still why MUTE is needed. All it does is PAUSE a single stream. The MUTE complicates the RTSP server state machine in exactly the same way that a non-aggregate PAUSE down. It's the same thing called something different. >>I guess I'm not understanding why this would be difficult. The only >>limitation would be that the timeline must be consistent across all >>streams. Otherwise, control the streams to your heart's content. > > [Thomas Zeng] Here the concern is on RTSP state machine. Which still has the same complications with the MUTE. Bill May _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 14:15:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10290 for ; Mon, 14 Jul 2003 14:15:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7qv-0006qZ-3T for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 14:15:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIF9ID026316 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 14:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7qu-0006qN-Ip for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10200 for ; Mon, 14 Jul 2003 14:15:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7qs-0004RH-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 14:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7qr-0004RE-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 14:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7qr-0006pz-N7; Mon, 14 Jul 2003 14:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7qM-0006l3-9b for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 14:14:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10094 for ; Mon, 14 Jul 2003 14:14:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7qJ-0004Pl-00 for mmusic@ietf.org; Mon, 14 Jul 2003 14:14:31 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19c7qJ-0004Pi-00 for mmusic@ietf.org; Mon, 14 Jul 2003 14:14:31 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19c7qH-0006N9-00; Mon, 14 Jul 2003 11:14:29 -0700 Date: Mon, 14 Jul 2003 11:14:29 -0700 From: Tom Marshall To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Message-ID: <20030714181429.GB24409@real.com> References: <3F12E4EB.4050404@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <3F12E4EB.4050404@ericsson.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > So please consider if you have any further requirements that should be=20 > consider for this work. We should in the next weeks have some consensus= =20 > on what work we should perform regarding the solution for symmetric NATs= =20 > and RTSP. The result of this discussion will be used to decide on what=20 > solution to select. Perhaps I misread this, but it sounds like you are saying that we should agree on one traversal solution. I thought the RTSP NAT document was intended (and does) present the various NAT traversal solutions along with their strengths and weaknesses, and let the implemetors decide which to use? --=20 =2E..if the church put in half the time on covetousness that it does on lus= t, this would be a better world. -- Garrison Keillor, "Lake Wobegon Days" --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/EvMFqznSmcYu2m8RArsyAJ0XyFm1q4FG4m6MSvgn8zVgpoyEewCePYM4 G1oRS0c2wtQ7TYplYiY+N0o= =eLpy -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 14 19:52:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08034 for ; Mon, 14 Jul 2003 19:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD70-0005UL-8H for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 19:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ENq6MP021093 for mmusic-archive@odin.ietf.org; Mon, 14 Jul 2003 19:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD70-0005U8-5W for mmusic-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 19:52:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07970 for ; Mon, 14 Jul 2003 19:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cD6y-0002w5-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 19:52:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cD6x-0002w2-00 for mmusic-web-archive@ietf.org; Mon, 14 Jul 2003 19:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD6v-0005Nt-RC; Mon, 14 Jul 2003 19:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD6b-0005Kt-Qd for mmusic@optimus.ietf.org; Mon, 14 Jul 2003 19:51:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07918 for ; Mon, 14 Jul 2003 19:51:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cD6X-0002vJ-00 for mmusic@ietf.org; Mon, 14 Jul 2003 19:51:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cD6W-0002uL-00 for mmusic@ietf.org; Mon, 14 Jul 2003 19:51:36 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6ENoriB009752; Mon, 14 Jul 2003 19:50:55 -0400 (EDT) Message-ID: <3F1341D8.9060703@dynamicsoft.com> Date: Mon, 14 Jul 2003 19:50:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. References: <20030714181429.GB24409@real.com> In-Reply-To: <20030714181429.GB24409@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Marshall wrote: > > So please consider if you have any further requirements that should be > > consider for this work. We should in the next weeks have some consensus > > on what work we should perform regarding the solution for symmetric NATs > > and RTSP. The result of this discussion will be used to decide on what > > solution to select. > > Perhaps I misread this, but it sounds like you are saying that we should > agree on one traversal solution. I thought the RTSP NAT document was > intended (and does) present the various NAT traversal solutions along with > their strengths and weaknesses, and let the implemetors decide which to > use? You need to be really careful with approaches like that. The problem is interoperability. Unless you agree on a mandatory to implement mechanism, you will have problems. Furthermore, it makes it hard to use the same client in deployments where one solution vs. another would be the optimal one. We have suffered alot on both these points in sip, where sip clients work in specific cases dependenting on which nat solution they have used. It has been a real barrier to deployment. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 03:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00937 for ; Tue, 15 Jul 2003 03:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKcT-0003yP-W1 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 03:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F7r5Sm015266 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 03:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKcS-0003y9-9k for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 03:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00924 for ; Tue, 15 Jul 2003 03:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKcP-0005XI-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 03:53:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cKcP-0005XF-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 03:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKcP-0003xl-KY; Tue, 15 Jul 2003 03:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKbb-0003wm-Tp for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 03:52:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00875 for ; Tue, 15 Jul 2003 03:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKbZ-0005WX-00 for mmusic@ietf.org; Tue, 15 Jul 2003 03:52:09 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19cKbY-0005WU-00 for mmusic@ietf.org; Tue, 15 Jul 2003 03:52:08 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6F7q5Ii005353; Tue, 15 Jul 2003 09:52:05 +0200 (MEST) Received: from ericsson.com (permit154.er.ki.sw.ericsson.se [147.214.97.154]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366B5Y0Z; Tue, 15 Jul 2003 09:52:10 +0200 Message-ID: <3F13B2A1.7000000@ericsson.com> Date: Tue, 15 Jul 2003 09:52:01 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill May CC: mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.com> <3F12EB45.7080003@cisco.com> In-Reply-To: <3F12EB45.7080003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Bill, Bill May wrote: > Thomas, > > I think that we can agree that this new specification would not be > backward compatible with existing RTSP session. To my knowledge the changes result in a subset of the functionality that RFC 2326 specifies. This subset is working in this regard the same way the original specification. In our discussion there where no implementations that actually use the functionality of having individual PLAY/PAUSE in a aggregated session. The reason of the change was basically get the protocol to be interoperable. There where so many strange things when you allow individual media control within an aggregated session. By requiring all media control methods (PLAY and PAUSE) to work on the aggregated the whole issue was resolved and everything becomes consistent. So the interoperability issues of this change seem minor and the client will get clear indications through error codes that it attempts something not allowed by the server. > > > To me, it does not seem like for good reason. Not enough bang for the > buck, but perhaps I am still missing something. > > As long as you are aware of this and have done so intentionally, that's > cool. But IMO, I would not not be making these changes (adding MUTE, > requiring PLAY/PAUSE to be aggregate as opposed to stream based) in > order to make wording or a state machine clearer. > > In fact, the MUTE complicates the state machine in the exact same way > that a non-aggregate PAUSE does. No it doesn't. As MUTE/UNMUTE only switch on and off the media delivery and do not effect the timing of the state and in what state machine state it is, it does not complicate things. > > > More below: > > Thomas Zeng wrote: > >>> I can see a scenario where you might want to stop the video, but still >>> maintain >>> the audio. In this case, you have 2 or more streams running, and the >>> client >>> wishes to stop 1 of them. This is a perfectly legal scenario. >> >> >> [Thomas Zeng] There are two ways to do what you want here: 1) issue >> teardown on the audio track. 2) perform a MUTE on the audio track. > > > Doesn't teardown now need to be aggregate ? So that wouldn't work. Teardown can be used both aggregated and non aggregated. > > > >>> Can you please expand on why it doesn't make sense to allow streams to >>> be controlled separately ? I've done most of my work on the player >>> side >>> with >>> the idea that the streams could be seperate, so most likely I'm missing >>> something. >> >> >> [Thomas Zeng] If two streams belong to same RTSP session, and you >> issue PLAY on one stream, what would be the state of the overall >> session ? >> what would be the NPT (Normal Play Time) of the session? If I recall >> correctly, if PLAY/PAUSE were allowed on each track in a >> mutli-tracked RTSP >> session, the RTSP state machine would break. > > > I'm not sure that I understand why the state of the session is important. > The server would be issueing the required streams. Have you tried to implement a correct minimal implementation of the RFC 2326 defined RTSP server? If you had I don't think you would ask this question. When I performed the implementation this resulted in a 50+ questions regarding how things should work that directly related to expected behaviour and interoperability. > > > The NPT of the session would be whatever the player decided it would be - > it can derive this from the RTPInfo, and decide how it wants to deal > with it. I don't think it is this simple. In a session with two aggregated session you will have actually three different playout clocks if you allow individual PLAY/PAUSE. - The aggregated session playout time - Media 1 playout time - media 2 playout time. When you perform an individual PLAY on a pause media using the media URL what should happened, what timers should be started? If you after that performs an aggregated PLAY, does that replace the previous media playout, or does it only start all not already running media? This is a rat hole. > > > Are you defining a specification on how to develop a server (which is > what > a state machine would imply) ? Or a method of interoperability ? This is a interoperability problem and a fix to a under specified part of RTSP. > > >>> Why ? To me, aggregate (or control of the entire session) control and >>> non-aggregate control (or control based on each stream) can be used >>> at the same time, and should be allowed. >> >> >> [Thomas Zeng] Yes, you are right here. The decision by the RTSP >> task force was to let PLAY/PAUSE be aggregate, while SETUP/TEARDOWN and >> MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an >> extension to >> RTSP core spec). > > > I'm not sure I understand still why MUTE is needed. All it does is PAUSE > a single stream. The MUTE complicates the RTSP server state machine > in exactly > the same way that a non-aggregate PAUSE down. > > It's the same thing called something different. Not exactly the same thing. You are correct that MUTE can be realized using one RTSP session per media and do all media synchronization at the client side. The MUTE/UNMUTE proposal is a separate extension draft and will need further review. You might be correct that MUTE/UNMUTE are not in fact needed. Best Regards Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 04:01:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01890 for ; Tue, 15 Jul 2003 04:01:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKkD-0004XW-S9 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F81573017444 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKkC-0004XH-Ba for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01822 for ; Tue, 15 Jul 2003 04:00:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKk9-0005kA-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cKk8-0005k7-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:01:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKkA-0004Vf-9r; Tue, 15 Jul 2003 04:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKjK-0004TN-Jw for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 04:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01704 for ; Tue, 15 Jul 2003 04:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKjI-0005hc-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:00:08 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19cKjH-0005hZ-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:00:07 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6F805GJ015048; Tue, 15 Jul 2003 10:00:05 +0200 (MEST) Received: from ericsson.com (permit154.er.ki.sw.ericsson.se [147.214.97.154]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366B555K; Tue, 15 Jul 2003 10:00:10 +0200 Message-ID: <3F13B482.1050500@ericsson.com> Date: Tue, 15 Jul 2003 10:00:02 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tom Marshall , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. References: <20030714181429.GB24409@real.com> <3F1341D8.9060703@dynamicsoft.com> In-Reply-To: <3F1341D8.9060703@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom and Jonathan, My goal is in regards to the symmetric NAT solution which requires server modifications to only have one solution. However when it comes to solution that can be implemented at the client side without server modifications or simply servers running the updated RTSP they will all be documented. Best Regards Magnus Jonathan Rosenberg wrote: > > > Tom Marshall wrote: > >> > So please consider if you have any further requirements that >> should be >> > consider for this work. We should in the next weeks have some >> consensus >> > on what work we should perform regarding the solution for >> symmetric NATs >> > and RTSP. The result of this discussion will be used to decide on >> what >> > solution to select. >> >> Perhaps I misread this, but it sounds like you are saying that we should >> agree on one traversal solution. I thought the RTSP NAT document was >> intended (and does) present the various NAT traversal solutions along >> with >> their strengths and weaknesses, and let the implemetors decide which >> to use? > > > You need to be really careful with approaches like that. The problem > is interoperability. Unless you agree on a mandatory to implement > mechanism, you will have problems. Furthermore, it makes it hard to > use the same client in deployments where one solution vs. another > would be the optimal one. We have suffered alot on both these points > in sip, where sip clients work in specific cases dependenting on which > nat solution they have used. It has been a real barrier to deployment. > > -Jonathan R. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 04:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02489 for ; Tue, 15 Jul 2003 04:09:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKrv-0005TA-Q5 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F893Ll021018 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKrv-0005Sv-Hi for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02443 for ; Tue, 15 Jul 2003 04:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKrs-0005uB-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:09:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cKrs-0005u8-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:09:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKru-0005SX-CH; Tue, 15 Jul 2003 04:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKrN-0005Oz-FZ for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 04:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02393 for ; Tue, 15 Jul 2003 04:08:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKrK-0005tM-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:08:26 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19cKrK-0005tF-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:08:26 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19cKrG-0006e2-00; Tue, 15 Jul 2003 01:08:22 -0700 Date: Tue, 15 Jul 2003 01:08:22 -0700 From: Tom Marshall To: Magnus Westerlund Cc: Bill May , mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI Message-ID: <20030715080822.GB25484@real.com> References: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.com> <3F12EB45.7080003@cisco.com> <3F13B2A1.7000000@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <3F13B2A1.7000000@ericsson.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >> [Thomas Zeng] There are two ways to do what you want here: 1) issue > >>teardown on the audio track. 2) perform a MUTE on the audio track. > > > > > >Doesn't teardown now need to be aggregate ? So that wouldn't work.=20 >=20 >=20 > Teardown can be used both aggregated and non aggregated. I was under the impression that RTSP/1.0 only allowed aggregate TEARDOWN, while RTSP/1.1 will allow both aggregate and non-aggregate TEARDOWN. > >I'm not sure I understand still why MUTE is needed. All it does is PAUSE > >a single stream. The MUTE complicates the RTSP server state machine=20 > >in exactly > >the same way that a non-aggregate PAUSE down. > > > >It's the same thing called something different. >=20 >=20 > Not exactly the same thing. You are correct that MUTE can be realized=20 > using one RTSP session per media and do all media synchronization at the= =20 > client side. The MUTE/UNMUTE proposal is a separate extension draft and= =20 > will need further review. You might be correct that MUTE/UNMUTE are not= =20 > in fact needed. I believe we have recently agreed that the RTP time continues while in the PAUSE state. Wouldn't this make MUTE and PAUSE pretty much identical? What would be the remaining difference(s)? --=20 One good reason why computers can do more work than people is that they never have to stop and answer the phone. --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/E7Z2qznSmcYu2m8RAkmgAJ9ap6xieqW1kHmSF+8DtMLESemgaACfRhFy oWLXSuTSdTc/4tPwAr9/w1I= =Uqsl -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 04:31:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04402 for ; Tue, 15 Jul 2003 04:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLDC-0007Fe-UY for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:31:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8V2ZQ027874 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLDC-0007FV-Ky for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:31:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04323 for ; Tue, 15 Jul 2003 04:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLD9-0006Oy-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:30:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLD9-0006Ov-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:30:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLDB-0007Dn-Bv; Tue, 15 Jul 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLD1-0007DD-Au for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 04:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04310 for ; Tue, 15 Jul 2003 04:30:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLCy-0006OF-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:30:48 -0400 Received: from mail-out2.apple.com ([17.254.0.51]) by ietf-mx with esmtp (Exim 4.12) id 19cLCx-0006OB-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:30:47 -0400 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h6F8UbfR019621 for ; Tue, 15 Jul 2003 01:30:37 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 15 Jul 2003 01:30:24 -0700 Received: from [81.160.227.51] ([17.112.73.139]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h6F8UVdl003023; Tue, 15 Jul 2003 01:30:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <20030715080822.GB25484@real.com> References: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.com> <3F12EB45.7080003@cisco.com> <3F13B2A1.7000000@ericsson.com> <20030715080822.GB25484@real.com> Date: Tue, 15 Jul 2003 10:34:18 +0200 To: Tom Marshall , Magnus Westerlund From: Dave Singer Subject: Re: [MMUSIC] Aggregate Control URI Cc: Bill May , mmusic@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > >I believe we have recently agreed that the RTP time continues while in the >PAUSE state. Wouldn't this make MUTE and PAUSE pretty much identical? What >would be the remaining difference(s)? RTP time continues indeed, but not NPT, whereas I understand MUTE to say that NPT is advancing, whereas when paused it is not. So, after play/pause a subsequent play will start where you paused (with RTP timestamps advanced by the duration of the pause, but the media continuous); play/mute and then subsequent unmute would unmute material that is later in the source content by the the muted duration. right? -- David Singer Apple Computer/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 04:36:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04872 for ; Tue, 15 Jul 2003 04:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLI6-0007dm-6J for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8a6KE029297 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 04:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLI5-0007cS-63 for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04824 for ; Tue, 15 Jul 2003 04:36:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLI2-0006XK-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:36:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLI1-0006XH-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 04:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLI2-0007a2-Oh; Tue, 15 Jul 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLHn-0007YL-PW for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 04:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04807 for ; Tue, 15 Jul 2003 04:35:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLHk-0006Wr-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:35:44 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19cLHj-0006Wo-00 for mmusic@ietf.org; Tue, 15 Jul 2003 04:35:44 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6F8ZcIi015841; Tue, 15 Jul 2003 10:35:39 +0200 (MEST) Received: from ericsson.com (permit154.er.ki.sw.ericsson.se [147.214.97.154]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XKJ2R8; Tue, 15 Jul 2003 10:35:38 +0200 Message-ID: <3F13BCD7.9000909@ericsson.com> Date: Tue, 15 Jul 2003 10:35:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Singer CC: mmusic@ietf.org Subject: Re: [MMUSIC] Aggregate Control URI References: <72263E8E8622D611975C0002B32C19D84A7C57@misty.packetvideo.com> <3F12EB45.7080003@cisco.com> <3F13B2A1.7000000@ericsson.com> <20030715080822.GB25484@real.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> >> I believe we have recently agreed that the RTP time continues while >> in the >> PAUSE state. Wouldn't this make MUTE and PAUSE pretty much >> identical? What >> would be the remaining difference(s)? > > > RTP time continues indeed, but not NPT, whereas I understand MUTE to > say that NPT is advancing, whereas when paused it is not. So, after > play/pause a subsequent play will start where you paused (with RTP > timestamps advanced by the duration of the pause, but the media > continuous); play/mute and then subsequent unmute would unmute > material that is later in the source content by the the muted duration. > > right? Yes, MUTE only specifies that delivery is not performed. If you are in PLAY state the NPT time continues to run. Cheers Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 05:09:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07739 for ; Tue, 15 Jul 2003 05:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLo3-0001AG-Vi for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 05:09:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F997qK004472 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 05:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLo2-00019x-Dx for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07677 for ; Tue, 15 Jul 2003 05:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLnz-0007Em-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 05:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLny-0007Ej-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 05:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLnx-00019F-PQ; Tue, 15 Jul 2003 05:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLn9-00018l-TX for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 05:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07583 for ; Tue, 15 Jul 2003 05:08:06 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLn6-0007DI-00 for mmusic@ietf.org; Tue, 15 Jul 2003 05:08:08 -0400 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 19cLn6-0007DF-00 for mmusic@ietf.org; Tue, 15 Jul 2003 05:08:08 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl6.philips.com (Postfix) with ESMTP id 9C28E5D7B3; Tue, 15 Jul 2003 11:08:08 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA28863; Tue, 15 Jul 2003 11:08:08 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA21927; Tue, 15 Jul 2003 11:08:07 +0200 (MEST) Subject: Re: [MMUSIC] Aggregate Control URI To: Magnus Westerlund Cc: mmusic@ietf.org, Bill May X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 15 Jul 2003 10:58:47 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 15/07/2003 11:09: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: , >> I'm not sure I understand still why MUTE is needed. All it does is PAUSE >> a single stream. The MUTE complicates the RTSP server state machine >> in exactly >> the same way that a non-aggregate PAUSE down. >> >> It's the same thing called something different. > >Not exactly the same thing. You are correct that MUTE can be realized >using one RTSP session per media and do all media synchronization at the >client side. The MUTE/UNMUTE proposal is a separate extension draft and >will need further review. You might be correct that MUTE/UNMUTE are not >in fact needed. one difference/advantage is the need to specify a target media time with PLAY, with MUTE/UNMUTE it could be optional: for example if I was to SETUP 2 audio streams and MUTE one from the start, I want to be able after some playback time to send MUTE on the one playing and UNMUTE on the other one, simultaneously (queued RTSP commands) , without specifying the target time: i.e. for the server it means "now" or "asap", and it should make sure that the media is sent in a way that there is "no gap". => it is "aggregate control" in the sense that the server must be aware of the NPT relationship between these two streams => it is like when you aggregate PLAY audio and video the server must send audio and video data that are at the same (NPT) media time. (BTW this would also be a useful step for stream switching;-) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Bill May cc: mmusic@ietf.org (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: Re: [MMUSIC] Aggregate Control URI Magnus Westerlund Sent by: mmusic-admin@ietf.org 15/07/2003 09:52 Hi Bill, Bill May wrote: > Thomas, > > I think that we can agree that this new specification would not be > backward compatible with existing RTSP session. To my knowledge the changes result in a subset of the functionality that RFC 2326 specifies. This subset is working in this regard the same way the original specification. In our discussion there where no implementations that actually use the functionality of having individual PLAY/PAUSE in a aggregated session. The reason of the change was basically get the protocol to be interoperable. There where so many strange things when you allow individual media control within an aggregated session. By requiring all media control methods (PLAY and PAUSE) to work on the aggregated the whole issue was resolved and everything becomes consistent. So the interoperability issues of this change seem minor and the client will get clear indications through error codes that it attempts something not allowed by the server. > > > To me, it does not seem like for good reason. Not enough bang for the > buck, but perhaps I am still missing something. > > As long as you are aware of this and have done so intentionally, that's > cool. But IMO, I would not not be making these changes (adding MUTE, > requiring PLAY/PAUSE to be aggregate as opposed to stream based) in > order to make wording or a state machine clearer. > > In fact, the MUTE complicates the state machine in the exact same way > that a non-aggregate PAUSE does. No it doesn't. As MUTE/UNMUTE only switch on and off the media delivery and do not effect the timing of the state and in what state machine state it is, it does not complicate things. > > > More below: > > Thomas Zeng wrote: > >>> I can see a scenario where you might want to stop the video, but still >>> maintain >>> the audio. In this case, you have 2 or more streams running, and the >>> client >>> wishes to stop 1 of them. This is a perfectly legal scenario. >> >> >> [Thomas Zeng] There are two ways to do what you want here: 1) issue >> teardown on the audio track. 2) perform a MUTE on the audio track. > > > Doesn't teardown now need to be aggregate ? So that wouldn't work. Teardown can be used both aggregated and non aggregated. > > > >>> Can you please expand on why it doesn't make sense to allow streams to >>> be controlled separately ? I've done most of my work on the player >>> side >>> with >>> the idea that the streams could be seperate, so most likely I'm missing >>> something. >> >> >> [Thomas Zeng] If two streams belong to same RTSP session, and you >> issue PLAY on one stream, what would be the state of the overall >> session ? >> what would be the NPT (Normal Play Time) of the session? If I recall >> correctly, if PLAY/PAUSE were allowed on each track in a >> mutli-tracked RTSP >> session, the RTSP state machine would break. > > > I'm not sure that I understand why the state of the session is important. > The server would be issueing the required streams. Have you tried to implement a correct minimal implementation of the RFC 2326 defined RTSP server? If you had I don't think you would ask this question. When I performed the implementation this resulted in a 50+ questions regarding how things should work that directly related to expected behaviour and interoperability. > > > The NPT of the session would be whatever the player decided it would be - > it can derive this from the RTPInfo, and decide how it wants to deal > with it. I don't think it is this simple. In a session with two aggregated session you will have actually three different playout clocks if you allow individual PLAY/PAUSE. - The aggregated session playout time - Media 1 playout time - media 2 playout time. When you perform an individual PLAY on a pause media using the media URL what should happened, what timers should be started? If you after that performs an aggregated PLAY, does that replace the previous media playout, or does it only start all not already running media? This is a rat hole. > > > Are you defining a specification on how to develop a server (which is > what > a state machine would imply) ? Or a method of interoperability ? This is a interoperability problem and a fix to a under specified part of RTSP. > > >>> Why ? To me, aggregate (or control of the entire session) control and >>> non-aggregate control (or control based on each stream) can be used >>> at the same time, and should be allowed. >> >> >> [Thomas Zeng] Yes, you are right here. The decision by the RTSP >> task force was to let PLAY/PAUSE be aggregate, while SETUP/TEARDOWN and >> MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an >> extension to >> RTSP core spec). > > > I'm not sure I understand still why MUTE is needed. All it does is PAUSE > a single stream. The MUTE complicates the RTSP server state machine > in exactly > the same way that a non-aggregate PAUSE down. > > It's the same thing called something different. Not exactly the same thing. You are correct that MUTE can be realized using one RTSP session per media and do all media synchronization at the client side. The MUTE/UNMUTE proposal is a separate extension draft and will need further review. You might be correct that MUTE/UNMUTE are not in fact needed. Best Regards Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 05:27:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09602 for ; Tue, 15 Jul 2003 05:27:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5s-0002Ny-Gl for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 05:27:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9RWir009166 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 05:27:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5s-0002Nl-Dm for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:27:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09510 for ; Tue, 15 Jul 2003 05:27:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM5o-0007ei-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 05:27:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cM5l-0007eY-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 05:27:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5M-0002Eb-QX; Tue, 15 Jul 2003 05:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM4w-0002Do-1K for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 05:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09475 for ; Tue, 15 Jul 2003 05:26:28 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM4s-0007eS-00 for mmusic@ietf.org; Tue, 15 Jul 2003 05:26:30 -0400 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 19cM4r-0007eO-00 for mmusic@ietf.org; Tue, 15 Jul 2003 05:26:29 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl6.philips.com (Postfix) with ESMTP id A4A0C5CD05; Tue, 15 Jul 2003 11:26:30 +0200 (MET DST) Received: from smtprelay-nl2.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 LAA04745; Tue, 15 Jul 2003 11:26:30 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA02722; Tue, 15 Jul 2003 11:26:28 +0200 (MEST) Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. To: Magnus Westerlund Cc: Jonathan Rosenberg , mmusic@ietf.org, Tom Marshall X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 15 Jul 2003 11:17:07 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 15/07/2003 11:27:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, I totally agree with Jonathan, if we leave the door open to several solutions you can be sure each of them will be implemented (because when you have a hammer all the problems are nails;-) and we will create even more trouble than we already have, plus a lot of burden on implementers and IOT plus the risk that we actually produce a mess that will simply not work, e.g. the problem is that some solutions are aggresive to others for example an ALG kills STUN, as simple as that (I have seen that happen recently;-( So I would really hope we would decide to choose ONE solution, even if takes longer and creates a few more unhappy people. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Jonathan Rosenberg cc: Tom Marshall mmusic@ietf.org (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Magnus Westerlund Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Classification: Sent by: mmusic-admin@ietf.org 15/07/2003 10:00 Hi Tom and Jonathan, My goal is in regards to the symmetric NAT solution which requires server modifications to only have one solution. However when it comes to solution that can be implemented at the client side without server modifications or simply servers running the updated RTSP they will all be documented. Best Regards Magnus Jonathan Rosenberg wrote: > > > Tom Marshall wrote: > >> > So please consider if you have any further requirements that >> should be >> > consider for this work. We should in the next weeks have some >> consensus >> > on what work we should perform regarding the solution for >> symmetric NATs >> > and RTSP. The result of this discussion will be used to decide on >> what >> > solution to select. >> >> Perhaps I misread this, but it sounds like you are saying that we should >> agree on one traversal solution. I thought the RTSP NAT document was >> intended (and does) present the various NAT traversal solutions along >> with >> their strengths and weaknesses, and let the implemetors decide which >> to use? > > > You need to be really careful with approaches like that. The problem > is interoperability. Unless you agree on a mandatory to implement > mechanism, you will have problems. Furthermore, it makes it hard to > use the same client in deployments where one solution vs. another > would be the optimal one. We have suffered alot on both these points > in sip, where sip clients work in specific cases dependenting on which > nat solution they have used. It has been a real barrier to deployment. > > -Jonathan R. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 05:28:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09732 for ; Tue, 15 Jul 2003 05:28:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM6q-0002Sy-1Z for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 05:28:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9SWb3009474 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 05:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM6p-0002Sj-Ul for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:28:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09666 for ; Tue, 15 Jul 2003 05:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM6L-0002P2-Fe; Tue, 15 Jul 2003 05:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM64-0002OX-6s for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 05:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09558 for ; Tue, 15 Jul 2003 05:27:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM60-0007ff-00 for mmusic@ietf.org; Tue, 15 Jul 2003 05:27:40 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19cM5q-0007ds-00 for mmusic@ietf.org; Tue, 15 Jul 2003 05:27:31 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h6F9Pv2B006499; Tue, 15 Jul 2003 02:25:57 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 02:25:57 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D804CD0A76@misty.packetvideo.com> From: Thomas Zeng To: Tom Marshall , Magnus Westerlund Cc: mmusic@ietf.org Subject: RE: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Date: Tue, 15 Jul 2003 02:25:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Dear Tom: Yes, we have presented "various NAT traversal solutions along with their strengths and weaknesses", but some of these solutions happen to require protocol development (e.g. port co-Located STUN). Correct me if I am wrong, but I think none of the off-the-shelf, UDP based solutions (e.g.,, STUN) work for Symmetric NAT, yet Symmetric NATs are rather common. Here I don't count TURN and ICE yet since they are only IDs, and even when they do become RFCs, their complexity seems to be high enough such that implementors will, as a knee-jerky reaction, fall back to TCP tunnelling for NAT traversal. Perhaps TCP tunnelling is acceptable (Magnus would disgree with me), or perhaps we could develope a UDP based solution whose complexity is not much worse than TCP tunnelling? Then there is RTP DoS problem ... Hence the change of direction, so to speak. Cheers, - thomas -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Monday, July 14, 2003 11:14 AM To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. > So please consider if you have any further requirements that should be > consider for this work. We should in the next weeks have some consensus > on what work we should perform regarding the solution for symmetric NATs > and RTSP. The result of this discussion will be used to decide on what > solution to select. Perhaps I misread this, but it sounds like you are saying that we should agree on one traversal solution. I thought the RTSP NAT document was intended (and does) present the various NAT traversal solutions along with their strengths and weaknesses, and let the implemetors decide which to use? -- ...if the church put in half the time on covetousness that it does on lust, this would be a better world. -- Garrison Keillor, "Lake Wobegon Days" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 10:32:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21781 for ; Tue, 15 Jul 2003 10:32:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQqK-0000hl-4R for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 10:31:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEVmqH002708 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 10:31:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQqJ-0000hb-WB for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21727 for ; Tue, 15 Jul 2003 10:31:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQq7-0002Tj-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 10:31:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQq1-0002TH-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 10:31:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQpa-0000d1-IJ; Tue, 15 Jul 2003 10:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQp7-0000bg-Fw for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 10:30:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21643 for ; Tue, 15 Jul 2003 10:30:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQp5-0002Sk-00 for mmusic@ietf.org; Tue, 15 Jul 2003 10:30:31 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19cQou-0002Sc-00 for mmusic@ietf.org; Tue, 15 Jul 2003 10:30:20 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19cQoI-0006oa-00; Tue, 15 Jul 2003 07:29:42 -0700 Date: Tue, 15 Jul 2003 07:29:42 -0700 From: Tom Marshall To: Thomas Zeng Cc: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Message-ID: <20030715142942.GA26155@real.com> References: <72263E8E8622D611975C0002B32C19D804CD0A76@misty.packetvideo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <72263E8E8622D611975C0002B32C19D804CD0A76@misty.packetvideo.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2003 at 02:25:55AM -0700, Thomas Zeng wrote: > Dear Tom: >=20 > Yes, we have presented "various NAT traversal solutions along with their > strengths and weaknesses", but some of these solutions happen to require > protocol development (e.g. port co-Located STUN).=20 >=20 > Correct me if I am wrong, but I think none of the off-the-shelf, UDP based > solutions (e.g.,, STUN) work for Symmetric NAT, yet Symmetric NATs are > rather common. Here I don't count TURN and ICE yet since they are only ID= s, > and even when they do become RFCs, their complexity seems to be high enou= gh > such that implementors will, as a knee-jerky reaction, fall back to TCP > tunnelling for NAT traversal. >=20 > Perhaps TCP tunnelling is acceptable (Magnus would disgree with me), or > perhaps we could develope a UDP based solution whose complexity is not mu= ch > worse than TCP tunnelling? >=20 > Then there is RTP DoS problem ... >=20 > Hence the change of direction, so to speak. I believe these are all good arguments for documenting and supporting Symmetric RTP in the draft: - Works through Symmetric NAT. - Works through ALGs. - Very simple to implement. - Does not change DoS threat level. I believe that Symmetric RTP should be presented as a simple and basic NAT traversal solution for the case where the server is in the open and the client may be behind a NAT (the client need not know or care, because using Symmetric RTP will not break things if it's not really behind a NAT). We can then continue on with the more complex cases, such as servers behind NATs. --=20 Apathy Club meeting this Friday. If you want to come, you're not invited. --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/FA/WqznSmcYu2m8RAvOdAJ9l/JDv32Z6roNboSNCDwWvQUNhzwCfSsso tse0fLSQXTvUiEEEawch2NI= =itrS -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 10:37:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22043 for ; Tue, 15 Jul 2003 10:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQvU-000140-Dy for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 10:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEb8Pu004081 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 10:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQvU-00013k-AU for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:37:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22033 for ; Tue, 15 Jul 2003 10:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQvR-0002WA-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 10:37:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQvM-0002W7-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 10:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQvN-00011J-KV; Tue, 15 Jul 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQui-000104-JJ for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 10:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21993 for ; Tue, 15 Jul 2003 10:36:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQug-0002Vm-00 for mmusic@ietf.org; Tue, 15 Jul 2003 10:36:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cQuV-0002Ve-00 for mmusic@ietf.org; Tue, 15 Jul 2003 10:36:07 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FEZIiB010081; Tue, 15 Jul 2003 10:35:20 -0400 (EDT) Message-ID: <3F14111F.80403@dynamicsoft.com> Date: Tue, 15 Jul 2003 10:35:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Thomas Zeng , Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. References: <20030715142942.GA26155@real.com> In-Reply-To: <20030715142942.GA26155@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 inline. Tom Marshall wrote: > On Tue, Jul 15, 2003 at 02:25:55AM -0700, Thomas Zeng wrote: > > Dear Tom: > > > > Yes, we have presented "various NAT traversal solutions along with their > > strengths and weaknesses", but some of these solutions happen to require > > protocol development (e.g. port co-Located STUN). > > > > Correct me if I am wrong, but I think none of the off-the-shelf, UDP > based > > solutions (e.g.,, STUN) work for Symmetric NAT, yet Symmetric NATs are > > rather common. Here I don't count TURN and ICE yet since they are > only IDs, > > and even when they do become RFCs, their complexity seems to be high > enough > > such that implementors will, as a knee-jerky reaction, fall back to TCP > > tunnelling for NAT traversal. > > > > Perhaps TCP tunnelling is acceptable (Magnus would disgree with me), or > > perhaps we could develope a UDP based solution whose complexity is > not much > > worse than TCP tunnelling? > > > > Then there is RTP DoS problem ... > > > > Hence the change of direction, so to speak. > > I believe these are all good arguments for documenting and supporting > Symmetric RTP in the draft: > > - Works through Symmetric NAT. > - Works through ALGs. > - Very simple to implement. > - Does not change DoS threat level. How do you arrive at that? Symmetric RTP has the problem I outlined in my draft. I just need to spoof the source of an IP packet, and then I can launch the attack. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 10:51:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22690 for ; Tue, 15 Jul 2003 10:51:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR95-0001ro-HE for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 10:51:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEpB8P007175 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 10:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR95-0001re-Dm for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:51:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22635 for ; Tue, 15 Jul 2003 10:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cR8z-0002dh-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 10:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cR8u-0002de-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 10:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR8v-0001pz-KV; Tue, 15 Jul 2003 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR8t-0001pl-0w for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 10:50:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22624 for ; Tue, 15 Jul 2003 10:50:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cR8l-0002dW-00 for mmusic@ietf.org; Tue, 15 Jul 2003 10:50:51 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19cR8a-0002dT-00 for mmusic@ietf.org; Tue, 15 Jul 2003 10:50:41 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19cR8J-0006pS-00; Tue, 15 Jul 2003 07:50:23 -0700 Date: Tue, 15 Jul 2003 07:50:23 -0700 From: Tom Marshall To: Jonathan Rosenberg Cc: Thomas Zeng , Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Message-ID: <20030715145023.GA26242@real.com> References: <20030715142942.GA26155@real.com> <3F14111F.80403@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <3F14111F.80403@dynamicsoft.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >I believe these are all good arguments for documenting and supporting > >Symmetric RTP in the draft: > > > > - Works through Symmetric NAT. > > - Works through ALGs. > > - Very simple to implement. > > - Does not change DoS threat level. >=20 > How do you arrive at that? Symmetric RTP has the problem I outlined in=20 > my draft. I just need to spoof the source of an IP packet, and then I=20 > can launch the attack. A proper implementation on the server side will only accept a Symmetric RTP packet which originates from the same IP as the RTSP control connection (and yes, we should make sure to document this prominently). Note that a client could send a flood of media packets to another client on its own network, but this is something that it can already do. Thus the DoS threat level remains unchanged. --=20 For my birthday I got a humidifier and a de-humidifier... I put them in the same room and let them fight it out. -- Steven Wright --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/FBSvqznSmcYu2m8RAn26AKCAUImXhUu9HxKkl3rOECsR5fy1zgCfTrrD YiOADtjrRCJFziRDW5JJ1Ks= =4WZq -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 11:47:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24870 for ; Tue, 15 Jul 2003 11:47:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cS1K-0004Ws-8X for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 11:47:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FFlETV017403 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 11:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cS1K-0004Wc-4E for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 11:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24857 for ; Tue, 15 Jul 2003 11:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cS1I-000377-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 11:47:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cS1D-000373-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 11:47:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cS17-0004V0-9h; Tue, 15 Jul 2003 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cS0r-0004Th-SU for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 11:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24820 for ; Tue, 15 Jul 2003 11:46:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cS0q-00036t-00 for mmusic@ietf.org; Tue, 15 Jul 2003 11:46:44 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19cS0f-00036c-00 for mmusic@ietf.org; Tue, 15 Jul 2003 11:46:33 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6FFjiIi024699; Tue, 15 Jul 2003 17:45:44 +0200 (MEST) Received: from ericsson.com (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XKM4XG; Tue, 15 Jul 2003 17:45:44 +0200 Message-ID: <3F1421A7.50202@ericsson.com> Date: Tue, 15 Jul 2003 17:45:43 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org, Bill May Subject: Re: [MMUSIC] Aggregate Control URI References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, See below: philippe.gentric@philips.com wrote: >>>I'm not sure I understand still why MUTE is needed. All it does is PAUSE >>>a single stream. The MUTE complicates the RTSP server state machine >>>in exactly >>>the same way that a non-aggregate PAUSE down. >>> >>>It's the same thing called something different. >>> >>> >>Not exactly the same thing. You are correct that MUTE can be realized >>using one RTSP session per media and do all media synchronization at the >>client side. The MUTE/UNMUTE proposal is a separate extension draft and >>will need further review. You might be correct that MUTE/UNMUTE are not >>in fact needed. >> >> > >one difference/advantage is the need to specify a target media time with PLAY, >with MUTE/UNMUTE it could be optional: > >for example if I was to SETUP 2 audio streams and MUTE one from the start, >I want to be able after some playback time to send MUTE on the one playing >and UNMUTE on the other one, simultaneously (queued RTSP commands) > It is not queued RTSP commands, it is pipelined commands. >, without specifying the target time: >i.e. for the server it means "now" or "asap", and it should make sure that the media >is sent in a way that there is "no gap". > Yes, not specifying a range for MUTE will make it happend directly. So by unmuting before muteing will ensure seamless switching. > >=> it is "aggregate control" in the sense that the server must be aware of the NPT relationship >between these two streams > If the media streams that a client are muteing and unmuting is in the same session they are running using the same NPT timestamp. > >=> it is like when you aggregate PLAY audio and video >the server must send audio and video data that are at the same (NPT) media time. > > Yes, >(BTW this would also be a useful step for stream switching;-) > I don't know that. The SETUP overhead is considerable. Best Regards Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 14:54:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29268 for ; Tue, 15 Jul 2003 14:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUwF-0004Va-C8 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 14:54:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FIsBI3017326 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 14:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUwD-0004VM-RC for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 14:54:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29262 for ; Tue, 15 Jul 2003 14:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cUwB-0004Wu-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 14:54:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cUw5-0004Wr-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 14:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUw5-0004Ux-7z; Tue, 15 Jul 2003 14:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUvy-0004Uj-1C for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 14:53:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29258 for ; Tue, 15 Jul 2003 14:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cUvv-0004Wo-00 for mmusic@ietf.org; Tue, 15 Jul 2003 14:53:51 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cUvk-0004Wc-00 for mmusic@ietf.org; Tue, 15 Jul 2003 14:53:40 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FIqwiB010256; Tue, 15 Jul 2003 14:52:59 -0400 (EDT) Message-ID: <3F144D81.4040005@dynamicsoft.com> Date: Tue, 15 Jul 2003 14:52:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Thomas Zeng , Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. References: <20030715145023.GA26242@real.com> In-Reply-To: <20030715145023.GA26242@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Marshall wrote: > > >I believe these are all good arguments for documenting and supporting > > >Symmetric RTP in the draft: > > > > > > - Works through Symmetric NAT. > > > - Works through ALGs. > > > - Very simple to implement. > > > - Does not change DoS threat level. > > > > How do you arrive at that? Symmetric RTP has the problem I outlined in > > my draft. I just need to spoof the source of an IP packet, and then I > > can launch the attack. > > A proper implementation on the server side will only accept a Symmetric RTP > packet which originates from the same IP as the RTSP control connection > (and > yes, we should make sure to document this prominently). That doesnt work with a nat that has more than one public IP. The RTP and RTSP requests might NAT to different addresses. > Note that a client > could send a flood of media packets to another client on its own network, > but this is something that it can already do. Thus the DoS threat level > remains unchanged. It still seems like a problem, though. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 15 23:30:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15277 for ; Tue, 15 Jul 2003 23:30:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cczl-0001ou-Kz for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 23:30:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G3ULxh006997 for mmusic-archive@odin.ietf.org; Tue, 15 Jul 2003 23:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cczi-0001om-Uh for mmusic-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 23:30:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15266 for ; Tue, 15 Jul 2003 23:30:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cczg-00017D-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 23:30:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cczb-00017A-00 for mmusic-web-archive@ietf.org; Tue, 15 Jul 2003 23:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cczT-0001oM-TZ; Tue, 15 Jul 2003 23:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ccyk-0001o3-IW for mmusic@optimus.ietf.org; Tue, 15 Jul 2003 23:29:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15257 for ; Tue, 15 Jul 2003 23:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ccyi-00014R-00 for mmusic@ietf.org; Tue, 15 Jul 2003 23:29:16 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19ccyW-000141-00 for mmusic@ietf.org; Tue, 15 Jul 2003 23:29:05 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 15 Jul 2003 20:16:37 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Tue, 15 Jul 2003 20:16:37 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Tue, 15 Jul 2003 20:23:00 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19cctB-0001v7-00 for ; Tue, 15 Jul 2003 20:23:33 -0700 Date: Tue, 15 Jul 2003 20:22:11 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_10,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #83 - 2 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media (SourceForge.net) 2. [ rtspspec-Feature Requests-522607 ] Need END_OF_STREAM request (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 15 Jul 2003 07:46:51 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media Bugs item #771638, was opened at 2003-07-15 16:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: a=range in SDP to indicate live media Initial Comment: Today there is some confusion on how a client should know that media is live. To be able to indicate this in SDP the following is proposed: Use a=range with any timeformet but in open ended style will indicate that the media is live, e.g. a=range:npt=0- or a=range:npt=now-. This makes it possible to use also for sessions using SMTPE or UTC times. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 15 Jul 2003 08:25:05 -0700 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-522607 ] Need END_OF_STREAM request Feature Requests item #522607, was opened at 2002-02-25 20:49 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=522607&group_id=23194 Category: None >Group: Protocol Extension Status: Open Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Nobody/Anonymous (nobody) Summary: Need END_OF_STREAM request Initial Comment: Currently there is no way for Server to inform Client the completion of a presentation (VOD or Live) without issuing a TEARDOWN and thus release reources. What if the player wants to use the same resources (pertinent to its sessionID) to watch another clip? It would be wasteful to teardown and then acquire another sessionID immediately. Would like to see a END_OF_STREAM method added on the S->C direction. E.g.: END_OF_STREAM or RTSP/1.0 SESSION: REASON: ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-07-15 17:24 Message: Logged In: YES user_id=302620 I think this issues should be further discussed. However I think this clearly is an protocol extension, not part of the core. It would solve the problem for live and also enable this to be clear in other scenarios. The basic semantics is: The server has/will have fulfilled the PLAY request. Putting this into RTSP has the advantage that it becomes media transport agnostic, however the indication may also be suitable to put into a media transport protocol. Further consideration on this is necessary. If someone has need, please write up an draft to be an RTSP extension or go to RTP, etc to put the functionality in. ---------------------------------------------------------------------- Comment By: Jason Lango (jasonlango) Date: 2002-03-14 01:55 Message: Logged In: YES user_id=223672 If this makes it into the spec, it would be a useful addition to know the last packet sequence numbers expected for each track (to identify packet loss at the end of stream) Perhaps this could be conveyed in an RTP-Info header? i.e. END_OF_STREAM RTSP/1.0 Session: RTP-Info: ;seqno=1234567,;seqno=... ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377747&aid=522607&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 03:34:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18673 for ; Wed, 16 Jul 2003 03:34:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgnj-0006lH-3H for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 03:34:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G7YBq5025992 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 03:34:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgni-0006jx-Q5 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 03:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18654 for ; Wed, 16 Jul 2003 03:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgnf-000445-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 03:34:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cgnZ-000442-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 03:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgnZ-0006jW-8j; Wed, 16 Jul 2003 03:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgnJ-0006j6-7d for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 03:33:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18651 for ; Wed, 16 Jul 2003 03:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgnG-00043t-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:33:42 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19cgn6-00043k-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:33:32 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19cgml-00074G-00; Wed, 16 Jul 2003 00:33:11 -0700 Date: Wed, 16 Jul 2003 00:33:11 -0700 From: Tom Marshall To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Message-ID: <20030716073311.GA27065@real.com> References: <20030715145023.GA26242@real.com> <3F144D81.4040005@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <3F144D81.4040005@dynamicsoft.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > > >I believe these are all good arguments for documenting and supporting > > > >Symmetric RTP in the draft: > > > > > > > > - Works through Symmetric NAT. > > > > - Works through ALGs. > > > > - Very simple to implement. > > > > - Does not change DoS threat level. > > > > > > How do you arrive at that? Symmetric RTP has the problem I outlined in > > > my draft. I just need to spoof the source of an IP packet, and then I > > > can launch the attack. > > > >A proper implementation on the server side will only accept a Symmetric = RTP > >packet which originates from the same IP as the RTSP control connection= =20 > >(and > >yes, we should make sure to document this prominently). >=20 > That doesnt work with a nat that has more than one public IP. The RTP=20 > and RTSP requests might NAT to different addresses. That is correct. In such a case, a more complex mechanism would be needed.= =20 However, I have yet to enounter or even hear of such a NAT setup. I think it's safe to say that this is a rare corner case. Symmetric RTP is a very simple solution that works in the vast majority of implemented NATs (my guess is 99% or so) when the server is in the open and the client is behind a NAT (or not). I'm not trying to convince anyone otherwise. I'm only saying that there is a very heavy penalty in terms of implementation complexity to get that extra 1% and we should keep a simple option available for those who don't need to handle all of the possible scenarios and corner cases. > >Note that a client > >could send a flood of media packets to another client on its own network, > >but this is something that it can already do. Thus the DoS threat level > >remains unchanged. >=20 > It still seems like a problem, though. How so? --=20 Logic is a systematic method of coming to the wrong conclusion with confidence. --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/FP+3qznSmcYu2m8RAq4LAKCFCwUJlYqUoB7cwGKO4fmtC4UxfgCcC6k6 //GXTg11s3aVF6h/MsN1vyY= =HB8v -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 03:40:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19096 for ; Wed, 16 Jul 2003 03:40:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtV-0007RJ-Fr for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 03:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G7e9ro028588 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 03:40:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtV-0007R1-8K for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 03:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19055 for ; Wed, 16 Jul 2003 03:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgtS-00048f-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 03:40:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cgtN-00048c-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 03:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtO-0007Oa-IH; Wed, 16 Jul 2003 03:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgsP-0007MW-BG for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 03:39:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19000 for ; Wed, 16 Jul 2003 03:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgsN-00047h-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:38:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cgsC-00047D-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:38:48 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6G7c5iB010757; Wed, 16 Jul 2003 03:38:06 -0400 (EDT) Message-ID: <3F1500D6.1070700@dynamicsoft.com> Date: Wed, 16 Jul 2003 03:37:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. References: <20030716073311.GA27065@real.com> In-Reply-To: <20030716073311.GA27065@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 inline. Tom Marshall wrote: > > That doesnt work with a nat that has more than one public IP. The RTP > > and RTSP requests might NAT to different addresses. > > That is correct. In such a case, a more complex mechanism would be needed. > However, I have yet to enounter or even hear of such a NAT setup. I think > it's safe to say that this is a rare corner case. > > Symmetric RTP is a very simple solution that works in the vast majority of > implemented NATs (my guess is 99% or so) when the server is in the open and > the client is behind a NAT (or not). I'm not trying to convince anyone > otherwise. I'm only saying that there is a very heavy penalty in terms of > implementation complexity to get that extra 1% and we should keep a simple > option available for those who don't need to handle all of the possible > scenarios and corner cases. I agree its the simplest solution in the cases where it works (though there is still that dos attack). The real issue is whether the group is interested in some of the other areas of applicability where the mechanism will not work, such as where the RTSP server is not in the open. If those are areas where you want RTSP to function, you would end up having two solutions, and you will have all the problems of figuring out which one to use. I've been down that route with SIP, and its not a pleasant one. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 03:54:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19735 for ; Wed, 16 Jul 2003 03:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch72-0008Ak-Js for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 03:54:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G7s88r031415 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 03:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch72-0008Ac-AN for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 03:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19728 for ; Wed, 16 Jul 2003 03:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ch6z-0004Hz-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 03:54:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ch6u-0004Hw-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 03:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch6u-0008A6-Vn; Wed, 16 Jul 2003 03:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch6c-00089p-13 for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 03:53:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19723 for ; Wed, 16 Jul 2003 03:53:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ch6Z-0004Hp-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:53:39 -0400 Received: from [81.160.147.207] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19ch6O-0004HR-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:53:28 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6G7r1d1000638; Wed, 16 Jul 2003 08:53:07 +0100 (BST) (envelope-from csp@csperkins.org) Date: Wed, 16 Jul 2003 09:53:01 +0200 From: Colin Perkins To: pessi@iki.fi Cc: mmusic@ietf.org Message-Id: <20030716095301.651b8ab7.csp@csperkins.org> In-Reply-To: References: <200305231412.KAA06476@ietf.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Inconsistency in draft-ietf-mmusic-sdp-new-13.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Pekka Pessi writes: > Hello all, > > In the sdp-new, there seems to be a contradiction between the > ABNF definition of "token-char" and comments after the > definition: > > token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 > / %x41-5A / %x5E-7E > ; definition from RFC 2045 - > ; "any (US-ASCII) CHAR except SPACE, CTLs, > ; or tspecials". > ; the tspecials are ()<>@,;: > > According to the ABNF, the tspecials include quote (%22, "), > slash (%2F, /), equal (%3D, =), question mark (%3f, ?), square > brackets (%5B, [ and %5D, ]), and backslash (%5C, \), too: > > ; the tspecials are ()/<>@,;:"=?[\] > > As it looks like that the sdp-new-14 is recycled once more, so > it is possible to fix the comment there (or ABNF, if that is > more appropriate). I'd like to solicit opinions from implementors about this. Please state your preference for either: 1) Leave the ABNF for token-char as-is, but remove the comment 2) Change the ABNF for token-char to be: token-char = %x21-27 / %x2A-2B / %x2D-2F / %x30-39 / %x3D / %x3F / %x41-5B / %x5C-%x5D / %x5E-7E adding the characters mentioned above. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 04:00:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19988 for ; Wed, 16 Jul 2003 04:00:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chCv-00009K-Cp for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 04:00:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G80DHc000552 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 04:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chCv-00008o-0q for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 04:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19968 for ; Wed, 16 Jul 2003 04:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chCn-0004MG-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 04:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19chCh-0004MD-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 04:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chCj-00006Y-2i; Wed, 16 Jul 2003 04:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chBn-0008Rd-UT for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 03:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19902 for ; Wed, 16 Jul 2003 03:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chBl-0004Jq-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:59:01 -0400 Received: from [81.160.147.207] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19chBa-0004Jb-00 for mmusic@ietf.org; Wed, 16 Jul 2003 03:58:50 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6G7vid1000708; Wed, 16 Jul 2003 08:57:45 +0100 (BST) (envelope-from csp@csperkins.org) Date: Wed, 16 Jul 2003 09:57:44 +0200 From: Colin Perkins To: Belling Thomas Cc: magnus.westerlund@ericsson.com, thomas.belling@siemens.com, mmusic@ietf.org Subject: Re: [MMUSIC] RTP bandwidth for multiple media streams Message-Id: <20030716095744.21cfc42d.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks. These changes look reasonable: comments from the group? Colin --> Belling Thomas writes: > Dear Colin >=20 > I would like to suggest the following additions to the SDP new draft > (denoted by ">>> <<<") >=20 > Alternatively, removing the and the corresponding > explanations from page 19f is acceptable to me, if nobody has concerns > with respect to the backward compatibility. >=20 > Thanks, Thomas >=20 >=20 >=20 > On page 13f: >=20 > Bandwidth >=20 > b=3D: >=20 > ... >=20 > Two modifiers are initially defined: >=20 > CT Conference Total > If the bandwidth of a session or media in a session is > different from the bandwidth implicit from the scope, a > "b=3DCT:..." line should be supplied for the session giving > the proposed upper limit to the bandwidth used. The primary > purpose of this is to give an approximate idea as to whether > two or more sessions can co-exist simultaneously. > >>> For RTP, if several RTP sessions are part of the conference, > the conference total refers to total bandwidth of all RTP > sessions. <<< > =20 >=20 > AS Application-Specific Maximum > The bandwidth is interpreted to be application-specific (it > will be the application's concept of maximum bandwidth). > Normally this will coincide with what is set on the > application's "maximum bandwidth" control if applicable. > For RTP based applications, AS gives the RTP "session > bandwidth" as defined in section 6.2 of [RFC1889]. >=20 > Note that CT gives a total bandwidth figure for all the media at > all sites. AS gives a bandwidth figure for a single media at a > single site, although there may be many sites sending > simultaneously. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On page 19f: >=20 > Media Announcements >=20 > m=3D >=20 > ... >=20 > The second sub-field is the transport port to which the media > stream is sent. The meaning of the transport port depends on the > network being used as specified in the relevant "c=3D" field, and on > the transport protocol defined in the third sub-field. Other > ports used by the media application (such as the RTCP port > [RFC1889]) MAY be derived algorithmically from the base media port > or MAY be specified in a separate attribute (e.g. "a=3Drtcp:" as > defined in [RTCPSDP]). >=20 > For applications where hierarchically encoded streams are being > sent to a unicast address, it may be necessary to specify multiple > transport ports. This is done using a similar notation to that > used for IP multicast addresses in the "c=3D" field: >=20 >=20 > m=3D / >=20 > In such a case, the ports used depend on the transport protocol. > For RTP, the default is that only the even numbered ports are used > for data and the corresponding one-higher odd port is used for > >>> RTCP >>> belonging to this RTP session, and the > >denotes the number of RTP sessions<<<. For example: >=20 > m=3Dvideo 49170/2 RTP/AVP 31 >=20 > would specify that ports 49170 and 49171 form one RTP/RTCP pair > and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the > transport protocol and 31 is the format (see below). If non- > contiguous ports are required, they must be signalled using a > separate attribute (e.g. "a=3Drtcp:" as defined in [RTCPSDP]) > ... >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Colin Perkins [mailto:csp@csperkins.org] > Gesendet: Mittwoch, 25. Juni 2003 19:03 > An: Magnus Westerlund > Cc: thomas.belling@siemens.com; mmusic@ietf.org > Betreff: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams >=20 >=20 > Can you suggest explicit wording changes to clarify the draft? There is > probably still time to incorporate minor edits for clarification. >=20 > Colin >=20 >=20 >=20 > --> Magnus > Westerlund writes: > > Hi Thomas, > >=20 > > Even more inline: > >=20 > > Belling Thomas wrote: > > > Hi Magnus, > > >=20 > > > My answers are inline > > >=20 > > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Gesendet: Montag, 23. Juni 2003 09:27 > > > An: Belling Thomas > > > Cc: 'mmusic@ietf.org' > > > Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams > > >=20 > > >=20 > > > Hi, > > >=20 > > > I would agree with the interpretation, at least when it comes to b=3D= AS > > > as it clearly specifies that this is the RTP session bandwidth. When > > > one uses a m=3D line with port/2 it becomes two RTP sessions. However= I > > > am not certain over how one should in this case interpret any of the > > > other bandwidth attributes. > > >=20 > > > [Thomas] Fine, but is that 100 Percent clear from the wording of the > > > RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a > > > clarification there > >=20 > > Yes, this should probably be clarified. I don't think it is obvious. > >=20 > > >=20 > > > The available bandwidth modifiers are: > > > CT > > > RR > > > RS > > >=20 > > > Lets look at them: > > >=20 > > > CT is defined in draft-ietf-mmusic-sdp-new-12 as: > > > CT Conference Total > > > If the bandwidth of a session or media in a session is > > > different from the bandwidth implicit from the scope, a > > > "b=3DCT:..." line should be supplied for the session > > > giving the proposed upper limit to the bandwidth used.=20 > > > The primary purpose of this is to give an approximate > > > idea as to whether two or more sessions can co-exist > > > simultaneously. > > >=20 > > > Based on this I would interpret that a given CT value should be for > > > the complete media, i.e. counting the total of both RTP sessions. > > >=20 > > > [Thomas] I agree that this is an interpretation in line with my > > > understanding of the intentions of the CT bandwidth modifier. > > > However, the wording is not so clear. What is a "session"? If you > > > understand"RTP session", this would contradict your interpretation. > > > As an aside: 3GPP ignores this parameter, so from that perspective a > > > clarification is less urgent than for the AS modifier. > >=20 > > Yes, the session in the quote is a bit unclear. I think it is a larger= =20 > > session concept, like the complete streaming session, or probably when= =20 > > it was written the conferencing session with all the media included. On > > media level the text indicates the complete media, which in this case > > is transported over several RTP sessions. So based on these two=20 > > interpretations I arrive at my conclusion. > >=20 > > > When it concerns TIAS I will do the same interpretation that the=20 > > > bandwidth value apply per RTP session. > > >=20 > > > [Thomas] Makes sense if you take TIAS as a kind of refinement of the > > > AS modifier. I did not yet read the draft with that question in mind, > > > and the draft is still in a stage where this can be clarified. > >=20 > > Yes, it can still be modified. I have made an update and I did not=20 > > address the issue. The reason being is that I think the SDP draft > > should=20 > > first address this. Based on this clarification I would add to the=20 > > TIAS draft if necessary. > >=20 > > >=20 > > > My concern is that this simplistic model is probably not what you > > > would like if you would actually use this functionality. If one uses > > > multiple RTP sessions for a single media you are probably doing some > > > form of scalability, etc., and would like to specify the values > > > independently per RTP session. Fortunately there exist today > > > alternatives to achieve this behaviour today. With the help of > > > grouping of media lines it is possible to specify that several m=3D > > > lines are part of the same media. Using FID there is only a pitfall > > > with the following sentence:"A media agent handling a media flow that > > > comprises several "m" > > > lines MUST send a copy of the media to every "m" line part of the > > > flow as long as the codecs and the direction attribute present in > > > a particular "m" line allow it." > > >=20 > > > If that is a problem it might be easier to define a new grouping=20 > > > attribute for that situation. > > > Finally I have a question to the group, has anyone seen that "m=3D > > > port/2..." ever been used. And in that case how. > > >=20 > > > [Thomas] Take the simple example of stereo sound. Why not use the "m= =3D > > > port/2 " notification for that? Something in that direction might > > > have been the original motification. From a 3GPP perspective, where > > > this relates to thev bandwidth on the air and possibly the rate > > > charged for a service, we should have a clear understanding as this > > > possibility exists and might also be misused otherwise. > >=20 > > I don't think stereo is a good example. First reason is that you=20 > > normally don't split left and right channel into different packets,=20 > > unless they are really big, reasons are like synchronization. Therefore > > most audio codecs are possible to transport over RTP using a single=20 > > source. The sample based codec normally only specify that every other=20 > > sample is left and the other are right. Frame based codec normally > > have more advanced schemes where they encode left and right together to > > take advantage of the similarities between channels. > >=20 > > My thinking is actually along the lines, if no one uses it, why not=20 > > remove it, we will still have to if no implementations are identified=20 > > when going to draft standard. > >=20 > >=20 > > Best Regards > >=20 > > Magnus Westerlund > >=20 > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 >=20 > --=20 > Colin Perkins > csp@csperkins.org >=20 --=20 Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 04:01:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20034 for ; Wed, 16 Jul 2003 04:01:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chDn-0000Fk-QC for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 04:01:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G817m2000957 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 04:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chDn-0000FM-Lv for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 04:01:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20020 for ; Wed, 16 Jul 2003 04:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chDl-0004Mv-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 04:01:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19chDf-0004Ms-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 04:00:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chDh-0000CL-I9; Wed, 16 Jul 2003 04:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chDI-0000BH-6t for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 04:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19984 for ; Wed, 16 Jul 2003 04:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chDE-0004Ma-00 for mmusic@ietf.org; Wed, 16 Jul 2003 04:00:32 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19chD3-0004MS-00 for mmusic@ietf.org; Wed, 16 Jul 2003 04:00:21 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19chCx-00076L-00; Wed, 16 Jul 2003 01:00:15 -0700 Date: Wed, 16 Jul 2003 01:00:15 -0700 From: Tom Marshall To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. Message-ID: <20030716080015.GB27065@real.com> References: <20030716073311.GA27065@real.com> <3F1500D6.1070700@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline In-Reply-To: <3F1500D6.1070700@dynamicsoft.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > > That doesnt work with a nat that has more than one public IP. The RTP > > > and RTSP requests might NAT to different addresses. > > > >That is correct. In such a case, a more complex mechanism would be need= ed. > >However, I have yet to enounter or even hear of such a NAT setup. I thi= nk > >it's safe to say that this is a rare corner case. > > > >Symmetric RTP is a very simple solution that works in the vast majority = of > >implemented NATs (my guess is 99% or so) when the server is in the open = and > >the client is behind a NAT (or not). I'm not trying to convince anyone > >otherwise. I'm only saying that there is a very heavy penalty in terms = of > >implementation complexity to get that extra 1% and we should keep a simp= le > >option available for those who don't need to handle all of the possible > >scenarios and corner cases. >=20 > I agree its the simplest solution in the cases where it works (though=20 > there is still that dos attack). The real issue is whether the group=20 > is interested in some of the other areas of applicability where the=20 > mechanism will not work, such as where the RTSP server is not in the=20 > open. If those are areas where you want RTSP to function, you would=20 > end up having two solutions, and you will have all the problems of=20 > figuring out which one to use. I've been down that route with SIP, and=20 > its not a pleasant one. Regarding the dos attack, I maintain that the threat does not change from the current usage without NAT traversal (provided the server enforces the destination address constraint). Please provide an example of a case where the threat is increased if you believe otherwise. Please correct me if I'm wrong (I'm not very familiar with SIP), but my understanding is that SIP is primarily intended to be used in a peer to peer model while RTSP is primarily intended to be used in a client server model.= =20 I suspect this is probably a big reason for the unpleasantness that you mention. For specific applications (such as ours), Symmetric RTP will cover about 99% of the cases. The remaining 1% are covered with TCP interleaving. This has been shown to be true with a similar mechanism in our proprietary RDT transport. It's unlikely that the added implementation complexity for the other solutions will be worth the effort. Therefore, Symmetric RTP is very attractive in a real world application. --=20 Most people are too busy to have time for anything important. --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/FQYPqznSmcYu2m8RAo2nAJ4zsQgqoc1b4YTReO5mgbwlVBiIrgCdGw9X 1crHZhr9WYg8WPkqJwN/dHM= =kZ9K -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 05:07:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22107 for ; Wed, 16 Jul 2003 05:07:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciFi-00044q-I2 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:07:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G97APj015671 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciFi-00043c-Cu for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:07:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22075 for ; Wed, 16 Jul 2003 05:07:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciFf-0004w8-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:07:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ciFZ-0004w5-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciFY-000407-95; Wed, 16 Jul 2003 05:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciEn-0003w2-RD for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 05:06:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22050 for ; Wed, 16 Jul 2003 05:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciEk-0004vn-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:06:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ciEZ-0004vf-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:05:59 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6G95QGJ026470; Wed, 16 Jul 2003 11:05:26 +0200 (MEST) Received: from ericsson.com (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366CCKCV; Wed, 16 Jul 2003 11:05:35 +0200 Message-ID: <3F151550.4080004@ericsson.com> Date: Wed, 16 Jul 2003 11:05:20 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Jonathan Rosenberg , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT discussion on wednesday and thursday. References: <20030716080015.GB27065@real.com> In-Reply-To: <20030716080015.GB27065@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have some comments about this. I think that we should rather consider what we need to solve the DoS attack scenario. The main reason for solving this in the RTSP setting is to lift the restriction that servers can send media only to the IP address the TCP connection comes from. If one can remove this restriction one very interesting use cases becomes available: - Inviting RTSP servers into SIP calls or conferences. This is not possible otherwise if the controlling entity is different from the receiving entity. This will definitely be the case if one runs centralized conferencing with a focal point for all traffic. There probably are more use cases when RTSP allows the use of other destination addresses. They are in fact two problems, destination validation and NAT traversal. However they seem to using the same protocols and are connected, so I think we should take the opportunity to kill two birds with one stone. However I think that we should be careful in the design of the mechanism. First it shouldn't incur more than the necessary extra RTT to do the validation in use cases where there is no NAT. For clients behind NATs there will be at least one extra RTT to create the address mappings in the NAT. The solution of servers behind NATs will be a low priority and the work may only consist of keeping the door open for such extensions unless they come very easily which I don't think. Best Regards Magnus Westerlund > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 05:13:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22313 for ; Wed, 16 Jul 2003 05:13:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciLU-0004Yh-O2 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9D894017517 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciLU-0004YS-KV for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22307 for ; Wed, 16 Jul 2003 05:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciLR-0004yz-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:13:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ciLL-0004yw-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciLN-0004Wr-EO; Wed, 16 Jul 2003 05:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciKy-0004WS-4J for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 05:12:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22304 for ; Wed, 16 Jul 2003 05:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciKu-0004yo-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:12:33 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ciKj-0004yX-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:12:22 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6G9BkIi019487 for ; Wed, 16 Jul 2003 11:11:46 +0200 (MEST) Received: from ericsson.com (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 NW4W7Q7J; Wed, 16 Jul 2003 11:11:46 +0200 Message-ID: <3F1516CF.9060001@ericsson.com> Date: Wed, 16 Jul 2003 11:11:43 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP discussion today Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, There where no room available at the conference center so we will have to make this an ad-hoc. Please meet at 17.30 in the main foyer near the registration desk. We will then go down to the riverside (5 min walk) and have the discussion at one of the fast food places there. Based on yesterdays sightings there will be rather plenty of room there. We will continue until it is time to go to the IAB plenary. Please don't be late, we will not wait long. Any person late can call me on +46 70 211 48 44 for information on where we are. Cheers Magnus Westerlund A issue list for the discussions are: RTSP discussions topics RTSP & NAT - Goals - Select solution - FW - ALGs RTSP Core - Session and control URL definitions - Proposal for detecting live streams via SDP 'range' attribute. I think Magnus will have an updated proposal since last week? - Possible methods for signalling end of stream in RTP (both RTP/RTCP extensions and RTSP extensions are possibilities). - RTP extensions to make multibitrate files more cache-friendly. The most important piece of information that a proxy needs is a bitrate field, but there are other issues as well. - Should REDIRECT automatically close session? - How to handle implicit redirection through session description protocol. Majority favors allowing it per default. - How to detect the updated spec? Version number change 1.1 or 2.0, or only use require and tag when necessary. - Request to Response timeout. The time a request takes until any response is received is not bound. Look at SIP solution? RTSP MUTE/UNMUTE - Need for it, revisit requirements advantages. RTSP stream switching - Requirements - Way forward? RTSP TLS -into main spec if small enough! _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 05:29:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22948 for ; Wed, 16 Jul 2003 05:29:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciaf-0005Ve-CF for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:28:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9SnaD021172 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciaf-0005VP-81 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:28:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22896 for ; Wed, 16 Jul 2003 05:28:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciab-00057l-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:28:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ciaW-000576-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:28:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciXx-0005Jv-Ee; Wed, 16 Jul 2003 05:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciXf-0005Je-R8 for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 05:25:43 -0400 Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22789 for ; Wed, 16 Jul 2003 05:25:37 -0400 (EDT) Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h6G9PDhX013578; Wed, 16 Jul 2003 11:25:13 +0200 (MEST) Message-ID: <3F151A3A.4060406@tzi.uni-bremen.de> Date: Wed, 16 Jul 2003 11:26:18 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: csp@csperkins.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Slides for tomorrow Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To all presenters for tomorrow's MMUSIC session: Please send a copy of your slides to csp@csperkins.org jo@acm.org at least one hour prior to our meeting tomorrow, i.e. latest at 8:00am. We will then have them ready for your presentations on our laptops and also put them up on the web page. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 05:29:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23019 for ; Wed, 16 Jul 2003 05:29:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciax-0005a4-Hs for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9T7xN021448 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciax-0005Zr-EG for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22931 for ; Wed, 16 Jul 2003 05:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciau-00058D-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:29:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ciao-00058A-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciaq-0005WY-PW; Wed, 16 Jul 2003 05:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cial-0005W3-H1 for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 05:28:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22909 for ; Wed, 16 Jul 2003 05:28:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciah-00057o-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:28:51 -0400 Received: from adsl-63-203-202-182.dsl.snfc21.pacbell.net ([63.203.202.182] helo=bays02.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 19ciaW-00057S-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:28:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [MMUSIC] stream switching MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 16 Jul 2003 02:27:18 -0700 Message-ID: <30A6344AEBFC85429C30FF6C9C501CD128583A@bays02.mediator.com> Thread-Topic: [MMUSIC] stream switching Thread-Index: AcNKBUxCZw6MvEz8Qo2vEid68vus2gBdaHHf From: "Gamze Seckin" To: "Magnus Westerlund" , Cc: Content-Transfer-Encoding: base64 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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: base64 Content-Transfer-Encoding: base64 aGkgUGhpbGlwcGUsDQogDQpJIGFncmVlIHdpdGggTWFnbnVzJ3MgY29tbWVudHMgb24gZGlmZmVy ZW50aWF0aW5nIGNvbnRlbnQgcmF0ZSBmcm9tIHRyYW5zbWlzc2lvbiByYXRlIGFuZCBrZWVwaW5n IGFuIGV5ZSBvbiByZWNpZXZlciBidWZmZXIgb3ZlcmZsb3cgYW5kIHVuZGVyZmxvdy4gVGhlc2Ug YXJlIGFsbCB2YWxpZCBhbmQgdXNlZnVsIGRpc2N1c3Npb25zIGJ1dCBJIGJlbGlldmUgYXJlIG91 dCBvZiB0aGUgc2NvcGUgb2YgdGhlIHN0cmVhbSBzd2l0Y2hpbmcgZG9jdW1lbnRzIChwbGVhc2Ug Y29ycmVjdCBtZSBpZiBJIGFtIHdyb25nKS5JIGJlbGlldmUgdGhlIGRyYWZ0IHRyaWVzIHRvIGNv dmVyIGZhciB0b28gbWFueSByZXF1aXJlbWVudHMgdGhhdCBhcmUgcmF0ZSBjb250cm9sIHJlbGF0 ZWQgKHdoaWNoIGhhdmUgYmVlbi9hcmUgZGlzY3Vzc2VkIGluIG90aGVyIHdnJ3MpLiANCiANCkkg cGVyc29uYWxseSB3b3VsZCBleHBlY3QgdGhlc2UgdHdvIGRyYWZ0cyBvbiBzdHJlYW0gc3dpdGNo aW5nIHRvIGJlIG1vcmUgc3BlY2lmaWMgb24gY29kZWMgY2hhbmdlIHN1cHBvcnQgYW5kIGFkZHJl c3NpbmcgdGhlIGlzc3VlcyBvZiB0aGUgdHJhbnNwb3J0IChtb3JlIHNlcmlvdXMgcHJvYmxlbXMg dGhhdCBuZWVkIGFuIGFuc3dlcikuDQpJIHRoaW5rIHNlY3Rpb24gMi41IGlzIHRoZSBjb3JlIG9m IHRoZSBkb2N1bWVudCwgc2luY2UgdmlkZW8gc3RyZWFtIHN3aXRjaGVzIGFyZSByZWFsbHkgbm90 IGEgYmlnIGlzc3VlLCB3aGVyZWFzIGF1ZGlvIHN3aXRjaGVzIHJlcXVpcmUgbW9yZSBjb21wbGlj YXRlZCBzb2x1dGlvbnMgdGhhdCBtYXkgaW1wYWN0IHRoZSB1c2VyIGV4cGVyaWVuY2UuIEFuZCBo ZW5jZSB3ZSBzaG91bGQgZGlzY3VzcyBhbmQgcmVjb21tZW5kIHNvbHV0aW9ucyBmb3IgdGhvc2Uu Lg0KIA0KdGhhbmtzDQotZ2FtemUgc2Vja2luDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSANCglGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbV0gDQoJU2VudDogTW9uIDcvMTQvMjAwMyA1OjQwIEFNIA0KCVRvOiBwaGls aXBwZS5nZW50cmljQHBoaWxpcHMuY29tIA0KCUNjOiBtbXVzaWNAaWV0Zi5vcmcgDQoJU3ViamVj dDogUmU6IFtNTVVTSUNdIHN0cmVhbSBzd2l0Y2hpbmcNCgkNCgkNCg0KCUhpIFBoaWxsaXBlLA0K CQ0KCUkgaG9wZSB0aGF0IEkgY2FuIGNsYXJpZnkgYW55dGhpbmcgdGhhdCB3YXMgdW5jbGVhci4g SSBhbHNvIGhhcyBzb21lDQoJZnVydGhlciBjb21tZW50cywgc2VlIGJlbG93Lg0KCQ0KCXBoaWxp cHBlLmdlbnRyaWNAcGhpbGlwcy5jb20gd3JvdGU6DQoJDQoJPk1hZ251cywgeW91IHdyb3RlOg0K CT4gDQoJPg0KCT4+VG8gZW5hYmxlIHRoaXMgdGhlIGNvbXBsZXRlIHN5c3RlbSBtdXN0IGVuc3Vy ZSB0aGUgZm9sbG93aW5nIHRoaW5nczoNCgk+Pi0gQ29uZ2VzdGlvbiBDb250cm9sIG9yIHJhdGhl ciBhZGFwdGluZyB0cmFuc21pc3Npb24gcmF0ZXMgdG8gYXZhaWxhYmxlDQoJPj5uZXR3b3JrIHJh dGUgPT4gYXZvaWRpbmcgaGlnaCBwYWNrZXQgbG9zcyByYXRlcyB0aGF0IHNldmVyZWx5IGVmZmVj dA0KCT4+cXVhbGl0eS4NCgk+PiAgIA0KCT4+DQoJPg0KCT4gICB5ZXMNCgk+DQoJPiANCgk+DQoJ Pj4tIEF2b2lkIHRoYXQgdGhlIHJlY2VpdmVycyBidWZmZXJzIGVpdGhlciB1bmRlciBmbG93IChj YXVzZXMgaW50ZXJydXB0KQ0KCT4+b3Igb3ZlcmZsb3cgKHNob3cgdXAgYXMgcGFja2V0IGxvc3Mp Lg0KCT4+DQoJPj4gICANCgk+Pg0KCT4NCgk+ICAgeWVzLCB0aGlzIGlzIGZ1bmRhbWVudGFsIGZv ciBzZWFtbGVzcy1uZXNzDQoJPg0KCT4gDQoJPg0KCT4+QmFzZWQgb24gdGhpcyBvbmUgY2FuIGFy cml2ZSBhdCB0aGUgY29uY2x1c2lvbiB0aGF0IHRoZSBtZWRpYSBvciBjb250ZW50DQoJPj5yYXRl IG11c3QgYmUgYWRhcHRlZCwgb3RoZXJ3aXNlIHRoZSB1bmRlcmZsb3cgY29uZGl0aW9uIHdpbGwg YmUNCgk+PmltcG9zc2libGUgdG8gYXZvaWQuIElmIG9uZSBwZXJmb3JtcyBjb250ZW50IGFkYXB0 YXRpb24gdG93YXJkcyBsb3dlcg0KCT4+Yml0LXJhdGVzIG9uZSBtdXN0IGFsc28gcGVyZm9ybSBh ZGFwdGF0aW9uIHRvd2FyZHMgaGlnaGVyIHJhdGVzLg0KCT4+DQoJPj4gICANCgk+Pg0KCT4NCgk+ ICAgSSBhbSBub3Qgc3VyZSBhYm91dCB0aGlzICJtdXN0IiwgY291bGQgaXQgYmUgdGhhdCB5b3Vy IGFyZQ0KCT4gICBjb25zaWRlcmluZyBkaWZmZXJlbnRseSBtZWRpYSByYXRlIGFuZCB0cmFuc21p c3Npb24gcmF0ZSA/DQoJPiANCgk+DQoJDQoJV2hhdCBJIG1lYW4gaXMgdGhhdCBpZiB0aGUgYXZh aWxhYmxlIHRyYW5zbWlzc2lvbiByYXRlIGlzIGxlc3MgdGhlIG1lZGlhDQoJcmF0ZSB0aGVuIHlv dSBvbiBzb21lIHRpbWUgc2NhbGUgaWYgbm90aGluZyBjaGFuZ2VzIHlvdSB3aWxsIGVtcHR5IHlv dXINCglidWZmZXIuIFRoZXJlZm9yZSB5b3UgIm11c3QiIGNoYW5nZSB0aGUgbWVkaWEgcmF0ZSB0 byBhdm9pZCB0aGlzIG9yIGhhdmUNCglpbnRlcnJ1cHRzLiBJIGRvbid0IGtub3cgYWJvdXQgYW55 IG90aGVyIHNvbHV0aW9uLg0KCQ0KCT4gICBiZWNhdXNlIEkgYW0gbm90IGNvbnNpZGVyaW5nIGNo YW5naW5nIHRoZSB0cmFuc21pc3Npb24gcmF0ZSAoYXMgYQ0KCT4gICBlbmQtdG8tZW5kIGFwcGxp Y2F0aW9uIGlzc3VlKSA9PiBzdHJlYW0gc3dpdGNoaW5nIGlzIG9ubHkgYWJvdXQNCgk+ICAgY2hh bmdpbmcgdGhlICptZWRpYSogcmF0ZS4NCgk+DQoJDQoJSSBkb24ndCB0aGluayB5b3UgY2FuIGV4 Y2x1ZGUgdGhlIHRyYW5zbWlzc2lvbiByYXRlIGZyb20gdGhlIGVxdWF0aW9uLg0KCUluIG15IG9w aW5pb24geW91IG5lZWQgdG8gY29uc2lkZXIgdHJhbnNtaXNzaW9uIHJhdGUsIHJlY2VpdmVyIGJ1 ZmZlcnMsDQoJYW5kIHRoZSBtZWRpYSByYXRlIGFsbCB0b2dldGhlci4NCgkNCgk+DQoJPiAgIHdo YXQgSSB3YW50IHRvIG1lYW4gaXMgeW91IGRvbnQgKm5lZWQqIHRvIGluY3JlYXNlIHRoZSBtZWRp YSByYXRlDQoJPiAgIHRvIGF2b2lkIHVuZGVmbG93cyBidXQgaW5zdGVhZCB5b3UgbWF5ICp3YW50 KiB0byBpbmNyZWFzZSB0aGUNCgk+ICAgbWVkaWEgcmF0ZSBpbiBvcmRlciB0byBpbXByb3ZlIHRo ZSB1c2VyIGV4cGVyaWVuY2UgaW4gdGVybXMgb2YNCgk+ICAgaW1hZ2UgcXVhbGl0eS4uLg0KCT4N CglJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4sIGJ1dCBJIGd1ZXNzIHRoZSBmb2xsb3dpbmcu IEluIGNhc2VzIHlvdSBhcmUNCglub3QgdHJhbnNtaXNzaW9uIHJhdGUgbGltaXRlZCBvbmUgaXMg bm90IHJlcXVpcmVkIHRvIGluY3JlYXNlIHRoZSBtZWRpYQ0KCXJhdGUsIGhvd2V2ZXIgaXQgaXMg Y29tbW9ubHkgZGVzaXJlZC4gSSBjYW4gYWdyZWUgdGhhdCB0aGVyZSBhcmUgc29tZQ0KCW5lZWQg dG8gYWxsb3cgdGhlIHJlY2VpdmVyIHRvIHNwZWNpZnkgd2hhdCBpcyBhbGxvd2VkIGluIHJlc3Bl Y3QgdG8NCgltZWRpYSByYXRlIG1vZGlmaWNhdGlvbnMuDQoJDQoJPg0KCT4gDQoJPg0KCT4+VGhp cyBJIHRoaW5rIGlzIHRoZSBiYXNpYyByZXF1aXJlbWVudCBhbmQgYXNzdW1wdGlvbnMgdGhhdCBh cHBseSB0byB5b3VyDQoJPj5yZXF1aXJlbWVudHMgZHJhZnQuDQoJPj4NCgk+PkJhc2VkIG9uIHRo aXMgYW55IHNvbHV0aW9uIGNhbiBiZSBkaXZpZGVkIHVwIGludG8gZGlmZmVyZW50DQoJPj5mdW5j dGlvbmFsaXR5IGJsb2NrczoNCgk+Pg0KCT4+LSBUcmFuc21pc3Npb24gcmF0ZSBjb250cm9sLCB0 aGlzIGZ1bmN0aW9uYWxpdHkgZW5zdXJlcyB0aGF0IGEgc2VuZGVyDQoJPj5kb2VzIG5vdCBzZW5k IG1vcmUgZGF0YSB0aGVuIHRoZSBuZXR3b3JrIGNhbiB0cmFuc3BvcnQgd2l0aG91dCBiZWluZyB0 bw0KCT4+dW5mYWlyLCBvciBvdmVyZmxvdyBuZXR3b3JrIGJ1ZmZlcnMuDQoJPj4NCgk+PiAgIA0K CT4+DQoJPg0KCT4gICBodW0sIGFnYWluIGkgcHJlZmVyIHRoZSB0ZXJtICJtZWRpYSByYXRlIGNv bnRyb2wiIGlmIHlvdSBkb250IG1pbmQ/DQoJPg0KCQ0KCU5vLCBJIGRvbid0IHRoaW5rIHlvdSBj b21wbGV0ZWx5IHVuZGVyc3RhbmQuIEluIGEgc3lzdGVtIHdoZXJlIHRoZQ0KCWJ1ZmZlciBzcGFj ZSBpcyBrbm93biB5b3UgZG9uJ3QgaGF2ZSB0byB0cmFuc21pdCB0aGUgZGF0YSBpbiB0aGUgc2Ft ZQ0KCXJhdGUgYXMgdGhlIG1lZGlhIHJhdGUuIER1ZSB0byB0aGUgYnVmZmVyIG9uZSBjYW4gZHVy aW5nIHNvbWUgcGFydHMgb2YNCgl0aGUgc2Vzc2lvbiB0cmFuc21pdCBkYXRhIGF0IHJhdGVzIHRo YXQgYXJlIGJvdGggaGlnaGVyIGFuZCBsb3dlciB0aGFuDQoJdGhlIG1lZGlhIHJhdGUuIEhvd2V2 ZXIgd2hlbiBkb2luZyB0aGlzIHlvdSBuZWVkIHRvIGVuc3VyZSB0aGF0IHlvdSBhcmUNCglub3Qg dW5kZXIgb3Igb3ZlcmZsb3dpbmcgdGhlIHJlY2VpdmVyIGJ1ZmZlci4gV2hhdCB5b3UgdHJ5IHRv IGRvIGlzIHRvDQoJc2ltcGxpZnkgdGhpcyBzeXN0ZW0gdG8gYmFzaWNhbGx5IHNheSB0aGF0IHRo ZSB0cmFuc21pc3Npb24gcmF0ZSBpcw0KCWVxdWFsIHRvIG1lZGlhIHJhdGUgd2hpY2ggSSB0aGlu ayBwcmV2ZW50cyBiZXR0ZXIgcGVyZm9ybWFuY2UuDQoJDQoJSWYgYW55IG9uZSBkb2VzIG5vdCB1 bmRlcnN0YW5kIHRoaXMsIHBsZWFzZSBwcm9kIG1lIGFuZCBJIHdpbGwgdHJ5IHRvDQoJcHJvdmlk ZSBhIGJldHRlciBleHBsYW5hdGlvbiBvZiB0aGUgY29tcGxldGUgc3lzdGVtLg0KCQ0KCT4NCgk+ IA0KCT4NCgk+Pi0gUmVjZWl2ZXIgYnVmZmVyIGNvbnRyb2wsIHRoaXMgZnVuY3Rpb25hbGl0eSBl bnN1cmUgdGhhdCBvbmUgZG9lcyBub3QNCgk+Pm92ZXJmbG93IHRoZSBjbGllbnQncyByZWNlaXZl ciBidWZmZXJzLg0KCT4+DQoJPj4gICANCgk+Pg0KCT4NCgk+ICAgeWVzLCBub3Qgc3VyZSB0aGVy ZSBpcyBtdWNoIHRvICJkbyIgdGhlcmUgaW4gdGVybXMgb2YgSUVURiBzcGVjPw0KCT4NCgkNCglU aGVyZSBpcyBub3RoaW5nIGluIElFVEYgdGhhdCBhbGxvd3MgZmVlZGJhY2sgb3IgZXZlbiBzcGVj aWZpY2F0aW9uDQoJYWJvdXQgdGhlIHJlY2VpdmVyIGJ1ZmZlcnMgdG8gb3IgYnkgdGhlIHNlbmRp bmcgc2lkZS4gVGhpcyBpcyBhbmFsb2dvdXMNCgl0byBUQ1AncyByZWNlaXZlciB3aW5kb3cgdGhh dCBhbGxvdyB0byBjb250cm9sIHRoZSBmbG93IG9mIG1lZGlhLg0KCQ0KCT4NCgk+DQoJPiANCgk+ DQoJPj4tIENvbnRlbnQgcmF0ZSBjb250cm9sLCBmdW5jdGlvbmFsaXR5IHRvIGVuc3VyZSB0aGF0 IHRoZSB0cmFuc21pdHRlZA0KCT4+ZGF0ZSBmaXRzIHRoZSBhdmFpbGFibGUgbmV0d29yayByYXRl LCB3aGlsZSBhdCB0aGUgc2FtZSB0aW1lIGVuc3VyZSB0aGF0DQoJPj50aGUgcmVjZWl2ZXIgYnVm ZmVyIGRvZXMgbm90IHVuZGVyZmxvdy4NCgk+Pg0KCT4+ICAgDQoJPj4NCgk+DQoJPiAgIHllcyEg dGhpcyBpcyBzdHJlYW0gc3dpdGNoaW5nIHByaW5jaXBsZSwgYnV0IGFnYWluIGl0IGlzIGFib3V0 DQoJPiAgICJtZWRpYSByYXRlIiwgbm90IGNoYW5naW5nIHRoZSB0cmFuc21pc3Npb24gcmF0ZS4N Cgk+DQoJDQoJVGhpcyBJIGNhbiBhZ3JlZSBpcyB3aGF0IHlvdSBkZXNjcmliZSBhcyBtZWRpYSBy YXRlIGNvbnRyb2wuIEJ5DQoJc2VsZWN0aW5nIG9yIGNvbnRyb2xsaW5nIHRoZSBtZWRpYSByYXRl IG9uZSBjYW4gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mDQoJdHJhbnNtaXNzaW9uIHJhdGUgYW5k IHJlY2VpdmVyIGJ1ZmZlcnMuDQoJDQoJPg0KCT4gDQoJPg0KCT4+QmFzZWQgb24gdGhpcyBmdW5j dGlvbmFsaXR5IGJsb2NrcyBvbmUgY2FuIHVzZSBvbmUgb3Igc2V2ZXJhbA0KCT4+cHJvdG9jb2xz L3NvbHV0aW9ucyB0byByZWFsaXplIHRoZW0uIFRoZXkgZG8gbm90IG5lZWQgdG8gYmUgc2VwYXJh dGUgYW5kDQoJPj5jYW4gdXRpbGl6ZSBpbmZvcm1hdGlvbiBlbmFibGVkIGJ5IGFueSBvZiB0aGUg b3RoZXIgZnVuY3Rpb25hbGl0eQ0KCT4+YmxvY2tzLiBIb3dldmVyIEkgYmVsaWV2ZSB0aGF0IGFs bCBwYXJ0cyBtdXN0IGJlIHByZXNlbnQgdG8gaGF2ZSBhDQoJPj5jb21wbGV0ZSBzb2x1dGlvbi4g QWxzbyBob3cgdG8gcmVhbGl6ZSB0aGUgc29sdXRpb25zIGlzIGEgbm90IGZpeGVkIGJ5DQoJPj50 aGlzLg0KCT4+DQoJPj5JIHdvdWxkIHN1Z2dlc3QgdGhhdCBvbmUgdHJpZXMgdG8gZ3JvdXAgdGhl IHJlcXVpcmVtZW50cyByZWdhcmRpbmcgd2hpY2gNCgk+Pm9mIHRoZSBmdW5jdGlvbmFsaXR5J3Mg dGhleSBhZGRyZXNzLg0KCT4+DQoJPj4gICANCgk+Pg0KCT4NCgk+ICAgV2hpY2ggZ3JvdXBzIHdv dWxkIHlvdSBzdWdnZXN0ID8NCgk+DQoJDQoJU29tZSBzdWdnZXN0aW9ucyB3b3VsZCBiZToNCgkN CglNZWRpYSByZXF1aXJlbWVudHM6IFJlcXVpcmVtZW50cyB0byBwcmV2ZW50IHRoZSBtZWRpYSBm cm9tIGJlaW5nDQoJY29ycnVwdGVkIG9yIHdvcnNlbiBxdWFsaXR5LCBsaWtlIGxpbWl0ZWQgcGFj a2V0IGxvc3NlcywgZ2FwIGZyZWUNCglzd2l0Y2hpbmcsIFJBUCxldGMuDQoJDQoJU2lnbmFsbGlu ZyByZXF1aXJlbWVudHM6IFJlcXVpcmVtZW50cyB0aGF0IGFyZSBhIHJlbGF0ZWQgdG8gd2hhdCB0 aGUNCglzaWduYWxsaW5nIG1lY2hhbmlzbSBuZWVkcyB0byBhY2hpZXZlLg0KCQ0KCVN5c3RlbSBy ZXF1aXJlbWVudHM6IFJlcXVpcmVtZW50cyB0aGF0IGhhdmUgbW9yZSBnZW5lcmFsIGZlZWxpbmcs IGxpa2UNCgliYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgZXRjLg0KCQ0KCQ0KCT4NCgk+DQoJPiAN Cgk+DQoJPj5XaGVuIG9uZSBjb21lcyB0byBzb2x1dGlvbiBvbmUgbXVzdCBzdGFydCBkaXNjdXNz aW5nIHdoYXQgY29udHJvbA0KCT4+cGFyYWRpZ20gb25lIGRlc2lyZXMsIGFzIGl0IHdpbGwgaGVh dmlseSBpbmZsdWVuY2UgdGhlIHNvbHV0aW9uLiBUaHJlZQ0KCT4+ZGlmZmVyZW50IG9uZXMgYXJl Og0KCT4+LSBTZXJ2ZXIgY29udHJvbGxlZDogSW4gdGhpcyB0aGUgc2VydmVyIGlzIHRoZSByZXNw b25zaWJsZSBmb3IgYWxsDQoJPj5kZWNpc2lvbnMgcmVnYXJkaW5nIHRoZSBhZGFwdGF0aW9uLiBU aGUgY2xpZW50IHNpbXBseSByZXBvcnRzIGNlcnRhaW4NCgk+Pm1lYXN1cmVtZW50cyB0aGF0IHRo ZSBzZXJ2ZXIgaW50ZXJwcmV0cy4NCgk+Pg0KCT4+LSBDbGllbnQgY29udHJvbGxlZDogVGhlIGNs aWVudCBtYWtlcyB0aGUgZGVjaXNpb25zIGFuZCBpbnRlcnByZXRhdGlvbnMNCgk+Pm9mIHdoYXQg aXQgc2VlLiBUaGVuIGl0IGlzc3VlcyBjb21tYW5kcyB0byB0aGUgc2VydmVyIHRoYXQgaXQgbXVz dA0KCT4+Zm9sbG93LiBUaGUgc2VydmVyIGlzIGEgc2ltcGxlIHNsYXZlLg0KCT4+DQoJPj4gICAN Cgk+Pg0KCT4NCgk+ICAgc2xhdmUsIHllcywgYnV0IGEgc2xhdmUgdGhhdCAqY291bGQqIHJlZnVz ZSB0byBvYmV5IDstKSBlLmcuIGFzDQoJPiAgIGRpc2N1c3NlZCBpbiBteSBkcmFmdCBmb3IgcmF0 ZSBjb250cm9sIGEgc2VydmVyIG11c3QgYmUgYWxsb3dlZCB0bw0KCT4gICBkZW55IGEgcmVxdWVz dCBmb3IgYSBoaWdoZXIgZGF0YSByYXRlLi4uDQoJPg0KCT4gDQoJPg0KCUluIGEgdHJ1ZSBjbGll bnQgY29udHJvbCBwYXJhZGlnbSwgdGhpcyBtYXkgbm90IGV2ZW4gYmUgdHJ1ZS4gQnV0IHRoZQ0K CWJhc2ljIHBvaW50IGlzIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBtYXkgbW90aXZhdGUgdGhlIGNo b2ljZSwgYnV0IHdlDQoJc2hvdWxkIG5vdCBjaG9pY2UgYSBhIHBhcmFkaWdtIGFuZCB0aGVuIHdy aXRlIHRoZSByZXF1aXJlbWVudHMgdG8gZnVsZmlsDQoJdGhlbS4gSSBoYXZlIGEgcmF0aGVyIGxv bmcgbGlzdCBvZiBjb21tZW50cyB0byB3aGVuIHRoaXMgZGlzY3Vzc2lvbg0KCW5lZWRzIHRvIGJl IHN0YXJ0ZWQuDQoJDQoJPiANCgk+DQoJPj4tIEh5YnJpZCBjb250cm9sOiBJbiBhIGh5YnJpZCBj b250cm9sIHNjZW5hcmlvIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXJzDQoJPj5tYWtlcyBkZWNpc2lv bnMgYW5kIGludGVycHJldGF0aW9ucyBvZiB0aGUgZGF0YS4NCgk+Pg0KCT4+SSB3aWxsIG5vdCB0 cnkgdG8gY29tcGFyZSB0aGVzZSBzb2x1dGlvbnMgdGhpcyBpZiBmb3IgZnV0dXJlDQoJPj5kaXNj dXNzaW9ucy4gSWYgb25lIGlzIGludGVyZXN0ZWQgaW4gYSBzZXJ2ZXIgY29udHJvbGxlZCBzb2x1 dGlvbiBvbmUNCgk+PmNhbiBsb29rIGF0IHRoZSBsYXRlc3QgcHJvcG9zYWwgaW4gM0dQUCBTQTQ6 DQoJPj5odHRwOi8vd3d3LjNncHAub3JnL2Z0cC90c2dfc2EvV0c0X0NPREVDL1RTR1M0XzI3L0Rv Y3MvUzQtMDMwNTAxLnppcA0KCT4+TG9vayBhdCB0aGUgYnVmZmVyIHJlcG9ydGluZyBtb2RlIHZh cmlhbnQuIFRoaXMgcHJvcG9zYWwgcHJvdmlkZXMNCgk+PnJlY2VpdmVyIGJ1ZmZlciBjb250cm9s IGFuZCBjb250ZW50IHJhdGUgY29udHJvbC4gVGhlIHRyYW5zbWlzc2lvbiByYXRlDQoJPj5jb250 cm9sIGlzIGhhbmRsZWQgdGhyb3VnaCBSVENQIHJlcG9ydHMgd2l0aCBlbmFibGVkIGV4dGVuZGVk IHJlcG9ydHMgb2YNCgk+PnBhY2tldCBsb3NzIHZlY3RvcnMuDQoJPj4NCgk+PiAgIA0KCT4+DQoJ Pg0KCT4gICBJIGhhdmUgdG8gc2F5IHRoYXQgdXNpbmcgc3VjaCBSVENQIGV4dGVuc2lvbnMgbG9v a3MgdmVyeSBtdWNoIGxpa2UNCgk+ICAgImNsaWVudCBjb250cm9sIiB0byBtZSA7LSkgYnV0IEkg ZG9udCByZWFsbHkgY2FyZSBhYm91dCB0aGUNCgk+ICAgdGVybWlub2xvZ3kgOy0pDQoJPg0KCQ0K CUFjdHVhbGx5IHRoZSBtZWNoYW5pc20gaW4gbXkgb3BpbmlvbiBpcyB2ZXJ5IHNlcnZlciBjb250 cm9sbGVkLiBUaGUNCgljbGllbnQgcHJvdmlkZXMgdGhlIHNlcnZlciBzaWRlIHdpdGggc29tZSBw YXJhbWV0ZXJzIHRlbGxpbmcgaXQgd2hhdCB0bw0KCWFjaGlldmUuIFRoZW4gdGhlIGNsaWVudCBw cm92aWRlcyByZWd1bGFyIGZlZWRiYWNrIHRvIGFsbG93IHRoZSBzZXJ2ZXINCgl0byBydW4gdGhl IGFsZ29yaXRobXMgYW5kIGNvbnRyb2wgdGhlIHdob2xlIHN5c3RlbS4NCgkNCgk+DQoJPg0KCT4g DQoJPg0KCT4+U29tZSBtb3JlIGRpcmVjdCBjb21tZW50cyBvbiB0aGUgZHJhZnQ6DQoJPj4NCgk+ PjEuIEludHJvZHVjdGlvbjogVGhlIGVuY29kaW5nIGNvdWxkIGJlIGRvbmUgaW4gcmVhbCB0aW1l IGFsbG93aW5nDQoJPj5tYXhpbXVtIGZsZXhpYmlsaXR5IGluIHRoZSBwcm9kdWNlZCBjb250ZW50 IHJhdGUuIEhvd2V2ZXIgdGhpcyBpcyBtYXkNCgk+Pm5vdCByZXN1bHQgaW4gb3B0aW1hbCBlbmNv ZGluZ3MgYW5kIGFyZSBhbHNvIHZlcnkgcmVzb3VyY2UgZGVtYW5kaW5nIGZvcg0KCT4+YSBzZXJ2 ZXIuDQoJPj4NCgk+PiAgIA0KCT4+DQoJPg0KCT4NCgk+ICAgeWVzLCBJIGRpZCBub3QgbWVudGlv biB0aGlzIHBvc3NpYmlsaXR5IGJlY2F1c2UgaW4gbGFyZ2Ugc2NhbGUNCgk+ICAgbWVkaWEgZGlz dHJpYnV0aW9uIHRoaXMgd291bGQgZWZmZWN0aXZlbHkgcmVxdWlyZSBvbmUgInByb2R1Y3Rpb24i DQoJPiAgIGVuY29kZXIgcGVyIGNsaWVudCwgd2hpY2ggaXMgLWV2ZW4gaW4gc2V2ZXJhbCB5ZWFy cyBmcm9tIG5vdy0gd2F5DQoJPiAgIGJleW9uZCB0aGUgY29zdCBwb2ludHMgZm9yIHRoaXMgdHlw ZSBvZiBwcm9kdWN0cy4NCgk+IA0KCT4NCglJIHRoaW5rIHRoYXQgc3BlbmRpbmcgdHdvIHNlbnRl bmNlcyBvbiB0aGlzIGlzIHVzZWZ1bCwganVzdCB0byBtYWtlIGl0DQoJY2xlYXIgdGhhdCBpdCBo YXMgYmVlbiBjb25zaWRlcmVkIGJ1dCBoYXMgc2lnbmlmaWNhbnQgcHJvYmxlbXMuDQoJDQoJPg0K CT4gDQoJPg0KCT4+Mi4gU2VjdGlvbiAyLjEuMSBhbmQgMi4xLjI6IEkgdGhpbmsgdGhlIGJlaGF2 aW91ciBpbiB0aGlzIGNhc2Ugc2hvdWxkDQoJPj5yZWFsbHkgYmUgZGVwZW5kaW5nIG9uIHRoZSBv cGVyYXRvcnMgcG9saWNpZXMuIEkgd291bGQgbm90IGxpa2UgdG8gaGF2ZQ0KCT4+bXkgZXhwZW5z aXZlbHkgcGFpZCBvbiBkZW1hbmQgdmlkZW8gcmVkdWNlZCBpbiBxdWFsaXR5IGlmIHRoaXMgbmV0 d29yaw0KCT4+aXMgb2YgdGhlIHR5cGUgeW91IGRlc2NyaWJlLiBIb3dldmVyIEkgY2FuIHNlZSB0 aGF0IHdlIHNob3VsZCBlbmFibGUgdGhpcy4NCgk+PiAgIA0KCT4+DQoJPg0KCT4NCgk+ICAgWWVz LCB5b3UgYXJlIHJpZ2h0LCBhbGwgdGhpcyBhc3N1bWVzIHRoZSBjb3JyZWN0IGNvbW1lcmNpYWwN Cgk+ICAgYWdyZWVtZW50cyBhcmUgaW4gcGxhY2UuIE91ciBleHBlcmllbmNlIGlzIGhvd2V2ZXIg dGhhdCBhIGVuZCB1c2VyDQoJPiAgIGFsd2F5cyBwcmVmZXJzIGEgY29udGludW91cyBwbGF5YmFj aywgZXZlbiBhIGRlZ3JhZGVkIG9uZSwNCgk+ICAgcHJvdmlkaW5nIHRoYXQgdGhlIGRlZ3JhZGF0 aW9uIGlzICJyZXNvbmFibGUiLCBhbGwgb3RoZXIgc29sdXRpb25zDQoJPiAgIGluY2x1ZGluZyAi ZnJlZXplcyIgZm9yIHJlYnVmZmVyZWluZyBhcmUgbm90IGFjY2VwdGFibGUgZm9yIHRoZQ0KCT4g ICB3aWRlIHB1YmxpYyB3aG8gaXMgYWNjdXN0b21lZCB0byBUViA7LSgNCgk+DQoJPkZyb20gYW4g SUVURiBwb2ludCBvZiB2aWV3IChoZXksIGp1c3QgZ2l2aW5nIG15IG93biBvcGluaW9uIDstKQ0K CT5JIHRoaW5rIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRoYXQgaW1wbGVtZW50YXRpb25zICpi eSBkZWZhdWx0Kg0KCT53b3VsZCAiYmVoYXZlIGEgbGEgVEZSQyIgcmF0aGVyIHRoYW4gd2hhdCB3 ZSBoYXZlIHRvZGF5LA0KCT5iZWNhdXNlIG90aGVyd2lzZSAtYXMgc2FsbHkgZmxveWQgcG9pbnRl ZCBvdXQgdGhpcyBtb3JuaW5nLQ0KCT53ZSB3b3VsZCBydW4gaW50byByYXRoZXIgbmFzdHkgdHJv dWJsZS4NCgk+DQoJDQoJWWVzLCBJIGFncmVlIHRoYXQgb3ZlciBhbnkgYmVzdCBlZmZvcnQgbmV0 d29yayB5b3UgbmVlZCBzb21lIHR5cGUgb2YNCgljb25nZXN0aW9uIGF2b2lkYW5jZS4gU28gZGVm YXVsdCBiZWhhdmlvdXIgaXMgZ29vZCwgaG93ZXZlciB3ZSBtdXN0IGFsc28NCglhbGxvdyBmb3Ig c3lzdGVtcyB0aGF0IGhhcyBRb1MgYWdyZWVtZW50cy4NCgkNCgk+DQoJPg0KCT4gDQoJPg0KCT4+ My4gU2VjdGlvbiAyLjI6IEkgdGhpbmsgeW91IG5lZWQgdG8gYmUgYSBiaXQgbW9yZSBjbGVhciB0 aGF0IHRoaXMgaXMgb25lDQoJPj5leGFtcGxlIG9mIGEgc2VydmljZS4gQWxzbyB0aGUgQU1SIHJh dGUgb2YgNSBrYnBzIGlzIGEgYml0IHRvIGxvdy4gVGhlDQoJPj40Ljc1IGticHMgbW9kZSBoYXMg YSBxdWFsaXR5IHRoYXQgaXMgbm90IHRoZSBiZXN0LiBIb3dldmVyIHRvIGFjaGlldmUNCgk+PnRo aXMgYml0LXJhdGUgeW91IG11c3Qgb25seSBzZW5kIG9uZSBBTVIgcGFja2V0IGV2ZXJ5IDEuMjgg c2Vjb25kcywNCgk+PndoaWNoIG1lYW5zIDY0IGFtciBmcmFtZXMgcGVyIHBhY2tldC4gVGhpcyBp cyBub3QgcmVhbGlzdGljIGFzIGV2ZXJ5DQoJPj5wYWNrZXQgd2lsbCBiZSByZXF1aXJlZCB0byBy ZWFjaCB0aGUgcmVjZWl2ZXIgdG8gYWNoaWV2ZSBhY2NlcHRhYmxlDQoJPj5xdWFsaXR5LiBJIHdv dWxkIHRoaW5rIHRoYXQgcmVhc29uYWJsZSBBTVIgcXVhbGl0aWVzIGFyZSB1c2luZyBhdCBsZWFz dA0KCT4+MTAgcGFja2V0IGV2ZXJ5IHNlY29uZCwgbWVhbmluZyB0aGF0IGEgaGVhZGVyIG92ZXJo ZWFkIG9mIDMga2Jwcy4NCgk+Pg0KCT4+ICAgDQoJPj4NCgk+DQoJPiAgIHJpZ2h0Lg0KCT4NCgk+ IA0KCT4NCgk+PjQuIFNlY3Rpb24gMi41OiBJIHRoaW5rIHRoaXMgc2VjdGlvbiBhc3N1bWVzIHNv bWV0aGluZyB0aGF0IGFyZSBub3QNCgk+PnF1aXRlIHRydWUuIEZpcnN0IHRoZSBpbXBvc3NpYmls aXR5IHRvIHNpZ25hbCB0aGlzIHJhdGUgc3dpdGNoIHVzaW5nDQoJPj5jdXJyZW50IHByb3RvY29s cy4NCgk+PiAgIA0KCT4+DQoJPg0KCT4gICBXaGF0ICppcyogaW1wb3NzaWJsZSBpcyB0byBmaW5k IGEgY29tcHJlaGVuc2l2ZSBzcGVjIGZvciBzdHJlYW0NCgk+ICAgc3dpdGNoaW5nICEtKSBhbmQg aXQgaXMgbXkgaW50ZW50aW9uIHRvIHByb3ZpZGUgb25lLCBpIHdvdWxkIGxvdmUgdG8NCgk+ICAg InVzZSB0aGUgY3VycmVudCBwcm90b2NvbHMiIQ0KCT4NCgk+IA0KCT4NCgk+PkkgY2xhaW0gaXQg aXMgcG9zc2libGUgYnV0IG1vc3QgbGlrZWx5IG5vdCBzdXBwb3J0ZWQNCgk+PmJ5IGFueSBhdmFp bGFibGUgY2xpZW50Lg0KCT4+ICAgDQoJPj4NCgk+DQoJPiAgIEFuZCB0aGF0IHdvdWxkIGJlIHRo ZSBwb2ludCBpbiB3cml0aW5nIHRoYXQgc3BlYy4uLg0KCT4NCgk+IA0KCT4NCgk+PlRvIHNpZ25h bCB0aGUgcmF0ZSBzd2l0Y2ggaW4gU0RQIHlvdSBwcmVzZW50DQoJPj5vbmUgZGlmZmVyZW50IFJU UCBwYXlsb2FkIHR5cGVzIGZvciBlYWNoIGNvZGVjIGFuZCBjb25maWd1cmF0aW9uLCBtb3N0DQoJ Pj5saWtlbHkgYXQgbGVhc3QgNCBtYXliZSA1LiBUaGUgNDAgYW5kIDUwIGticHMgQUFDIHN0ZXJl byBtYXkgYmUgcG9zc2libGUNCgk+PnRvIGVuY29kZSB1c2luZyB0aGUgc2FtZSBBQUMgY29uZmln dXJhdGlvbi4gVGhlIGRlY2xhcmVkIHBheWxvYWQgdHlwZXMNCgk+PmFyZSBwcmVzZW50IGluIGEg U0RQLiBBIGNsaWVudCBzaGFsbCBub3QgYWNjZXB0IHRoZSBzZXNzaW9uIGFuZCBzZXR1cA0KCT4+ dGhlIG1lZGlhIHN0cmVhbSB1bmxlc3MgaXQgY2FuIGhhbmRsZSBhbGwgdGhlc2UgY29kZWNzLiBJ ZiBpdCBoYXMgc2V0dXANCgk+PnRoaXMgbWVkaWEgc3RyZWFtIGl0IGhhcyBpbiBmYWN0IGFjY2Vw dGVkIHRoYXQgYW55IG9mIHRoZSBjb2RlYyBtYXkgYmUNCgk+PnVzZWQgaW4gdGhlIG1lZGlhIHN0 cmVhbS4NCgk+Pg0KCT4+ICAgDQoJPj4NCgk+DQoJPiAgIHdlbGwsIEkgY29tcGxldGVseSBhZ3Jl ZSB0aGF0ICp0aGF0KiBtYXkgYmUgYSBzb2x1dGlvbiB0byBzdHJlYW0NCgk+ICAgc3dpdGNoaW5n LCB0aGUgcG9pbnQgdGhlbiB3b3VsZCBiZSB0byBkb2N1bWVudCBpdCEtKQ0KCT4gDQoJPg0KCQ0K CUdvb2QsIHRoZW4geW91IHNob3VsZCByYXRoZXIgZG9jdW1lbnQgdGhpcyBkZWZpY2llbmN5IHJh dGhlciB0aGFuDQoJY2xhaW1pbmcgdGhhdCBpdCBpcyBwb3NzaWJsZS4NCgkNCgk+DQoJPiANCgk+ DQoJPj5UaGUgc2VydmVyIGNhbiBoZXJlIHVzZSBkaWZmZXJlbnQgc3RyYXRlZ2llcyB3aGVuIHN3 aXRjaGluZy4gVGhlIG1vc3QNCgk+Pmxpa2VseSBvbmUgaXMgdG8gdXNlIGEgc2luZ2xlIFNTUkMg YW5kIGluIHRoZSBzYW1lIFJUUCBzZXF1ZW5jZSBudW1iZXINCgk+PmFuZCB0aW1lc3RhbXAgc3Bh Y2Ugc2VuZCB0aGUgc2VsZWN0ZWQgbWVkaWEgcXVhbGl0eS4NCgk+PiAgIA0KCT4+DQoJPg0KCT4g ICBhZ3JlZWQsIHRoaXMgaXMgYSB2ZXJ5IG5pY2UgcG9zc2liaWxpdHkuLi50aGF0IG9idmlvdWxz eSB3ZSB3b3VsZA0KCT4gICBuZWVkIHRvICpzZXJpb3VseSogZG9jdW1lbnQgLi4uIGJlY2F1c2Ug dGhpcyBpcyBub3QgdGhlICJkZWZhdWx0Ig0KCT4gICB0aGluZyBhdCBhbGwgZnJvbSBleGlzdGlu ZyBzcGVjcywgcmlnaHQ/DQoJPg0KCT4gDQoJPg0KCQ0KCUkgaGF2ZSBzZWVuIGl0IGFzIGJlaW5n IHRoZSBkZWZhdWx0IGJlaGF2aW91ciwgaG93ZXZlciB0aGlzIGlzIG5vdGhpbmcNCgl0aGF0IGhh cyBiZWVuIHRob3JvdWdobHkgZGlzY3Vzc2VkIGluIEFWVCBhbmQgdGhlIFJUUCBzcGVjIG5vdCBi ZSB0aGF0DQoJY2xlYXIgb24gdGhpcyBwb2ludC4gRG9jdW1lbnRpbmcgdGhpcyB3b3VsZCBiZSBh IGdvb2QgdGhpbmcuDQoJDQoJPiANCgk+DQoJPj5XaGVuIHRoZSBzZXJ2ZXINCgk+PnN3aXRjaGVk IHRoaXMgd2lsbCBiZSBpbmRpY2F0ZWQgYnkgdGhlIG5ldyBSVFAgUFQuIFRoaXMgaGFzIGEgc2xp Z2h0DQoJPj5wcm9ibGVtIGFzIFJUUC9SVENQIGRvZXMgbm90IGhhbmRsZSBzd2l0Y2hlZCBSVFAg VFMgcmF0ZSBwZXJmZWN0bHkuIFRoZQ0KCT4+Y2xpZW50IG1heSBpbiBmYWN0IGxvc2Ugc3luY2hy b25pemF0aW9uIHVudGlsIGl0IHJlY2VpdmVzIGEgUlRDUCBwYWNrZXQNCgk+PmFmdGVyIHRoZSBz d2l0Y2ggaGFzIHRha2VuIHBsYWNlLg0KCT4+ICAgDQoJPj4NCgk+DQoJPiAgIHJpZ2h0ISB0aGF0 IGlzIGEga2V5IGlzc3VlIQ0KCT4NCgk+IA0KCT4NCgk+PlRoaXMgaGFwcGVucyBpZiB0aGUgcGFj a2V0IHdoZXJlIHRoZQ0KCT4+UlRQIFRTIHJhdGUgc3dpdGNoZXMgaXMgbG9zdC4gVGhpcyBpcyBu b3QgYSBwcm9ibGVtIGFzIGxvbmcgYXMgdGhlIFJUUA0KCT4+VFMgcmF0ZSBiZWZvcmUgYW5kIGFm dGVyIHRoZSBwYXlsb2FkIHR5cGUgc3dpdGNoIGhhcyB0aGUgc2FtZSBUUyByYXRlLg0KCT4+SW4g b3RoZXIgd29yZHMgbm90IGEgcHJvYmxlbSBmb3IgYW55IHZpZGVvIGNvZGVjIHdoaWNoIGFsbCBy dW5zIGF0DQoJPj45MDAwMC4NCgk+PiAgIA0KCT4+DQoJPg0KCT4gICB5ZXMsIG5vdCBhIHByb2Js ZW0gKmlmKiAoYXMgbWVudGlvbmVkIGFib3ZlKSB5b3UgbWFuZGF0ZSB0aGUgc2FtZQ0KCT4gICBS VFBUUyBzcGFjZSBmb3IgYWxsIHN0cmVhbXMgLi4uDQoJPg0KCT4gDQoJPg0KCT4+VGhpcyBpcyBt b3JlIGEgcHJvYmxlbSBmb3IgYXVkaW8gY29kZWNzLiBJIHdvdWxkIGluIGZhY3QgdHJ5IHRvDQoJ Pj5hZGRyZXNzIHRoaXMgcHJvYmxlbSB3aXRoIGF1ZGlvIGNvZGVjcyBieSBlbnN1cmluZyB0aGF0 IGFueSBhdWRpbyBjb2RlYw0KCT4+aXMgYWxsb3dlZCB0byBzZWxlY3QgYSBSVFAgVFMgcmF0ZSB0 aGF0IGlzIGEgZXZlbiByYXRlIG11bHRpcGxlIG9mIGl0cw0KCT4+bmF0aXZlIHZhbHVlLiBUaGlz IHdvdWxkIGFsbG93IGF1ZGlvIGNvZGVjcyB0byBydW4gYXQgYSB0aGUgc21hbGxlc3QNCgk+PmNv bW1vbiBkZW5vbWluYXRvciByYXRlLg0KCT4+DQoJPj4gICANCgk+Pg0KCT4NCgk+ICAgSXMgaXQg YWx3YXlzIHBvc3NpYmxlL2VmZmljaWVudD8NCgk+DQoJDQoJTm8sIG5vdCBmb3IgdGhlIGN1cnJl bnRseSBzcGVjaWZpZWQgUlRQIHBheWxvYWQgZm9ybWF0cy4gSXQgaXMgc29tZXRoaW5nDQoJSSB3 aWxsIHJlY29tbWVuZCBpbiBmdXR1cmUgcGF5bG9hZCBmb3JtYXRzIHRvIGFsbG93IGZvciB0aGlz IGZ1bmN0aW9uYWxpdHkuDQoJDQoJPg0KCT4gDQoJPg0KCT4+VGhlIG90aGVyIHN0cmF0ZWd5IGF0 IHBvaW50cyBvZiBzd2l0Y2hpbmcgd291bGQgYmUgdG8gdXNlIGRpZmZlcmVudA0KCT4+U1NSQ3Mu IFRoaXMgd291bGQgdmlvbGF0ZSB0aGUgc2VtYW50aWNzIHRoYXQgYSBTU1JDIHJlcHJlc2VudHMg YSBjZXJ0YWluDQoJPj5zb3VyY2UuIFRoaXMgYWxzbyBoYXMgc29tZSBwcm9ibGVtcyB3aXRoIHRo ZSBzeW5jaHJvbml6YXRpb24gb2YgdGhlDQoJPj5kaWZmZXJlbnQgU1NSQ3MuIFRoaXMgY2FuJ3Qg YmUgZG9uZSBpbiBSVFNQIGFzIFJUU1AgZHVlIHRvIGFuIGVycm9uZW91cw0KCT4+ZGVmaW5pdGlv biBvZiBSVFAtSW5mbyBkaWQgbm90IG1hcCBlYWNoIHN5bmNocm9uaXphdGlvbiBpbmZvcm1hdGlv biB0bw0KCT4+dGhlIFNTUkMuIFRoaXMgY2FuIG9ubHkgYmUgZml4ZWQgdGhyb3VnaCBhIG5ldyBo ZWFkZXIgZHVlIHRvIGJhY2t3YXJkcw0KCT4+Y29tcGF0aWJpbGl0eSBwcm9ibGVtcy4gT3RoZXJ3 aXNlIFJUQ1AgY291bGQgYmUgdXNlZC4gQnkgc2VuZGluZyBTUiBmb3INCgk+PmFsbCBTU1JDIG9u ZSBjb3VsZCBpbiBmYWN0IGVuc3VyZSB0aGF0IHRoZSBzeW5jaHJvbml6YXRpb24gaXMgYXZhaWxh YmxlLg0KCT4+SXQgd2lsbCB1dGlsaXplIG1vcmUgUlRDUCBiYW5kd2lkdGguDQoJPj4NCgk+PiAg IA0KCT4+DQoJPg0KCT5IdW0sIHNvIHdlIHNob3VsZCBkaXNyZWdhcmQgdGhpcyBvcHRpb24/DQoJ Pg0KCQ0KCUkgdGhpbmsgc28uDQoJDQoJPg0KCT4gDQoJPg0KCT4+NS4gU2VjdGlvbiAzLjEuMjog SSBkb24ndCB0aGluayB5b3Ugc2hvdWxkIG1peCBjb25nZXN0aW9uIGNvbnRyb2wgd2l0aA0KCT4+ YWRhcHRhdGlvbiBjb250cm9sIHRoYXQgaGFyZC4gSW4gbXkgb3BpbmlvbiwgaG93IGRyYXN0aWMg YSBjb250ZW50IHJhdGUNCgk+PmNoYW5nZSBpcyBuZWVkZWQgYW5kIGhvdyBtdWNoIGRlcGVuZHMg b24gdGhlIGNsaWVudHMgYnVmZmVyIHN0YXR1cy4NCgk+Pg0KCT4+ICAgDQoJPj4NCgk+DQoJPnNv cnJ5LCBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoYXQgb25lPw0KCT4NCgkNCglUaGlzIGhhcyB0byBk byB3aXRoIHRoZSBjb21wbGV0ZSBzeXN0ZW0gdGhhdCBhIHNlbmRlciBjYW4gdHJhbnNtaXQgYXQN CglvbmUgcmF0ZSwgd2hpbGUgdGhlIG1lZGlhIHJhdGUgaGFzIGFub3RoZXIgcmF0ZS4gVGhlIGRp c2NyZXBhbmN5IGlzDQoJaGFuZGxlZCBieSB0aGUgcmVjZWl2ZXIgYnVmZmVyLiBUaGVyZWZvcmUg dGhlIGNvbnRyb2wgb2YgdGhlIG1lZGlhIHJhdGUNCgljYW4gYmUgcGVyZm9ybWVkIG1vcmUgZHJh c3RpYyBvciBub3QgZGVwZW5kaW5nIG9uIHdoYXQgdGhlIGJ1ZmZlciBzdGF0dXMNCglpcy4gQW4g YWxtb3N0IGVtcHR5IHJlY2VpdmVyIGJ1ZmZlciBuZWVkcyB0byBiZSBoYW5kbGVkIHF1aWNrbHkg YW5kDQoJZHJhc3RpY2FsbHksIHByb2JhYmx5IGJlIHJlZHVjaW5nIHRoZSBtZWRpYSByYXRlIHNp Z25pZmljYW50bHkuIElmIHRoZQ0KCWJ1ZmZlciBhcmUgcmF0aGVyIGZ1bGwgdGhlIGhhbmRsaW5n IG9mIHRoaXMgY2FuIGJlIG11Y2ggbGVzcyBkcmFzdGljLCBhDQoJc21hbGwgZGlzY3JlcGFuY3kg Y2FuIHNpbXBseSBiZSB0cmllZCB0byB3YWl0ZWQgb3V0LiBPciB0aGUgcXVhbGl0eQ0KCWNoYW5n ZSBjYW4gYmUgbWluaW1hbC4NCgkNCgk+IA0KCT4NCgk+DQoJPiANCgk+DQoJPj44LiBTZWN0aW9u IDMuNzogSSBkb24ndCB0aGluayB3ZSBjYW4gZGVwbG95IGEgc29sdXRpb24gZm9yIHN3aXRjaGlu Zw0KCT4+dGhhdCBnaXZlcyBmdWxsIGZ1bmN0aW9uYWxpdHkgYW5kIGF0IHRoZSBzYW1lIHRpbWUg aXMgYmFja3dhcmRzDQoJPj5jb21wYXRpYmxlLiBIb3dldmVyIHRoaW5rIG9uIGhvdyBvbmUgY2Fu IG1haW50YWluIHNvbWUgb2YgdGhlDQoJPj5mdW5jdGlvbmFsaXR5IGFuZCBiZWluZyBiYWNrd2Fy ZHMgY29tcGF0aWJsZSBtYXkgYmUgYSB3b3J0aCB0aGUgZWZmb3J0Lg0KCT4+SG93ZXZlciB0aGlz IGlzIHJhdGhlciBhIGRlc2lnbiBldmFsdWF0aW9uIGNyaXRlcmlhIHRoYW4gYSByZXF1aXJlbWVu dC4NCgk+Pg0KCT4+ICAgDQoJPj4NCgk+DQoJPiAgIGRvIHlvdSBtZWFuIGl0IGlzIG5vdCBhcHBy b3ByaWF0ZSB0byBoYXZlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgYXMNCgk+ICAgYSByZXF1aXJl bWVudD8NCgk+DQoJPiANCgk+DQoJDQoJSXQgbWlnaHQsIGhvd2V2ZXIgSSB0aGluayBpdCBzaG91 bGQgYmUgZnVydGhlciBjb25zaWRlcmVkLiBJIHRoaW5rDQoJbGlzdGluZyB0aGUgbGV2ZWwgYXMg Y3JpdGljYWwgaXMgdG8gaGlnaCBsZXZlbC4NCgkNCglDaGVlcnMNCgkNCglNYWdudXMgV2VzdGVy bHVuZA0KCQ0KCQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJbW11c2ljIG1haWxpbmcgbGlzdA0KCW1tdXNpY0BpZXRmLm9yZw0KCWh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KCQ0KDQo= _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 05:47:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23482 for ; Wed, 16 Jul 2003 05:47:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cisO-0006JI-8H for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9l8tY024255 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cisO-0006J8-55 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23465 for ; Wed, 16 Jul 2003 05:47:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cisK-0005IK-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cisF-0005IH-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cisG-0006Gy-Uf; Wed, 16 Jul 2003 05:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cirR-0006Ef-Gv for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 05:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23438 for ; Wed, 16 Jul 2003 05:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cirO-0005I0-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:46:06 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19cirD-0005Hk-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:45:55 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6G9jJRi013762; Wed, 16 Jul 2003 03:45:19 -0600 (MDT) Received: from jamba (jamba [129.146.125.67]) by phys-ha1mpka.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id CAA20388; Wed, 16 Jul 2003 02:45:19 -0700 (PDT) Message-Id: <200307160945.CAA20388@phys-ha1mpka.eng.sun.com> Date: Wed, 16 Jul 2003 02:45:19 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan Subject: Re: [MMUSIC] RTSP discussion today To: mmusic@ietf.org, magnus.westerlund@ericsson.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j8RY68nFpwRhEYz8eEczhg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , hi Magnus, I have been thinking about how 'playlists' may be supported with RTSP/RTP. Playlists are what one might use in an internet radio session for instance, pre-program a set of songs that are to be played out in sequence on the same RTP session. Would it be possible to discuss this topic at the meeting today? From what I gather, there are multiple constraints on how playlists might work: for instance, the RTP timescales between multiple consecutive streams on the same RTP session cannot change, even thr the encoding rate and type can change - and is indicated by the Payload type of the RTP packets. From RTSP - there are complications when PAUSE is issued. If the RTP timestamps are allowed to advance while in a PAUSE state, then let us look at the impact of this: SETUP SETUP PLAY PLAY Now assume that a RTSP PAUSE is issued. This PAUSE can occur at the time of playing stream a or stream b or just at the point of switching from stream a to b. In the last case, if timestamps are allowed to advance during PAUSE, it means all of the packet timestamps need to be recalculated after the PAUSE point, (as for other PAUSE cases) even though the PLAY issued earlier would have used a different timestamp. This seems very awkward. I'm wondering if the decisions to allow RTP timestamps to advance during a PAUSE is such a good idea, after all. The only motivation seemed to be that this is the way it worked for conferencing. However the RTSP spec is relevant to other applications too, so it would be desirable to have a spec that defines a base-line, that is like a 'least common denominator'. After that other specs can define what is to be done for specifc applications. This seems to be the approach followed wrt Mute/Unmute. I would urge that we revisit the discussion with RTP timestamps. thanks geetha > Date: Wed, 16 Jul 2003 11:11:43 +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.4) Gecko/20030624 Netscape/7.1 (ax) > X-Accept-Language: en-us, en > To: mmusic@ietf.org > Content-Transfer-Encoding: 7bit > Content-Transfer-Encoding: 7bit > Subject: [MMUSIC] RTSP discussion today > X-BeenThere: mmusic@ietf.org > X-Mailman-Version: 2.0.12 > List-Unsubscribe: , > List-Id: Multiparty Multimedia Session Control Working Group > List-Post: > List-Help: > List-Subscribe: , > > Hi, > > There where no room available at the conference center so we will have > to make this an ad-hoc. Please meet at 17.30 in the main foyer near the > registration desk. We will then go down to the riverside (5 min walk) > and have the discussion at one of the fast food places there. Based on > yesterdays sightings there will be rather plenty of room there. We will > continue until it is time to go to the IAB plenary. > > Please don't be late, we will not wait long. Any person late can call me > on +46 70 211 48 44 for information on where we are. > > Cheers > > Magnus Westerlund > > > A issue list for the discussions are: > > RTSP discussions topics > > RTSP & NAT > > - Goals > - Select solution > - FW > - ALGs > > > RTSP Core > > - Session and control URL definitions > > - Proposal for detecting live streams via SDP 'range' attribute. I > think Magnus will have an updated proposal since last week? > > - Possible methods for signalling end of stream in RTP (both RTP/RTCP > extensions and RTSP extensions are possibilities). > > - RTP extensions to make multibitrate files more cache-friendly. The > most important piece of information that a proxy needs is a bitrate > field, but there are other issues as well. > > - Should REDIRECT automatically close session? > > - How to handle implicit redirection through session description protocol. > Majority favors allowing it per default. > > - How to detect the updated spec? Version number change 1.1 or 2.0, or > only use require and tag when necessary. > > - Request to Response timeout. The time a request takes until any > response is > received is not bound. Look at SIP solution? > > RTSP MUTE/UNMUTE > > - Need for it, revisit requirements advantages. > > > RTSP stream switching > > - Requirements > > - Way forward? > > RTSP TLS > > -into main spec if small enough! > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 05:58:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23646 for ; Wed, 16 Jul 2003 05:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cj32-0006pw-10 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:58:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9w8hi026279 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 05:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cj31-0006pm-RZ for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:58:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23639 for ; Wed, 16 Jul 2003 05:58:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cj2y-0005Ln-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:58:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cj2s-0005Lk-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 05:57:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cj2u-0006o2-Qm; Wed, 16 Jul 2003 05:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cj2n-0006nq-Mu for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 05:57:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23607 for ; Wed, 16 Jul 2003 05:57:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cj2k-0005LI-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:57:50 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19cj2Z-0005LD-00 for mmusic@ietf.org; Wed, 16 Jul 2003 05:57:39 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6G9vYGJ006129; Wed, 16 Jul 2003 11:57:34 +0200 (MEST) Received: from ericsson.com (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 NW4W7Y40; Wed, 16 Jul 2003 11:57:34 +0200 Message-ID: <3F15218A.6050005@ericsson.com> Date: Wed, 16 Jul 2003 11:57:30 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP discussion today References: <200307160945.CAA20388@phys-ha1mpka.eng.sun.com> In-Reply-To: <200307160945.CAA20388@phys-ha1mpka.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, Geetha Srikantan wrote: >hi Magnus, > >I have been thinking about how 'playlists' may be supported with RTSP/RTP. >Playlists are what one might use in an internet radio session for instance, >pre-program a set of songs that are to be played out in sequence on the same >RTP session. >Would it be possible to discuss this topic at the meeting today? > Sure, lets see how long we can come in the discussion. Regarding playlists, why not treat it as a live station and use HTTP to program the station. It does not seem suitable to perform this type of control in RTSP without further extensions for media resource control. > >From what I gather, there are multiple constraints on how playlists might work: >for instance, the RTP timescales between multiple consecutive streams on the >same RTP session cannot change, even thr the encoding rate and type can change - >and is indicated by the Payload type of the RTP packets. > >From RTSP - there are complications when PAUSE is issued. >If the RTP timestamps are allowed to advance while in a PAUSE state, >then let us look at the impact of this: > >SETUP >SETUP >PLAY >PLAY > >Now assume that a RTSP PAUSE is issued. >This PAUSE can occur at the time of playing stream a or stream b or >just at the point of switching from stream a to b. In the last case, >if timestamps are allowed to advance during PAUSE, it means all of >the packet timestamps need to be recalculated after the PAUSE point, >(as for other PAUSE cases) even though >the PLAY issued earlier would have used a different timestamp. >This seems very awkward. > >I'm wondering if the decisions to allow RTP timestamps to advance during a >PAUSE is such a good idea, after all. The only motivation seemed to be that >this is the way it worked for conferencing. However the RTSP spec is relevant >to other applications too, so it would be desirable to have a spec that >defines a base-line, that is like a 'least common denominator'. After that >other specs can define what is to be done for specifc applications. >This seems to be the approach followed wrt Mute/Unmute. I would urge that >we revisit the discussion with RTP timestamps. > The REASON for having this clarification of the usage of RTP timestamps are RTP and RTCP itself. The RTCP based synchronization and reporting would be very confused if you did not have continuos timestamp space. IF you would go stop the RTP timestamp space during pause while RTCP keeps advancing it at the defined rate parts of the TS space will be reused and the RTCP synchronization information will be impossible to match against the RTSP synchronization information. I know that people think this clarification creates some problems. However as having implemented this I know that it is not very many lines of code for the server. The client has only one significant problem which is to synchronize buffered data prior to pause with the data arriving after a pause. However this is a small practicality which have a solution. Best Regards Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 06:48:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24928 for ; Wed, 16 Jul 2003 06:48:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjpR-0001Hc-K9 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 06:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GAm9pf004928 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 06:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjpQ-0001HP-Up for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 06:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24908 for ; Wed, 16 Jul 2003 06:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjpM-0005lJ-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 06:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cjpH-0005lG-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 06:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjpJ-0001Gs-HL; Wed, 16 Jul 2003 06:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjox-0001Gb-0v for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 06:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24894 for ; Wed, 16 Jul 2003 06:47:32 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjos-0005l2-00 for mmusic@ietf.org; Wed, 16 Jul 2003 06:47:34 -0400 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 19cjoh-0005ky-00 for mmusic@ietf.org; Wed, 16 Jul 2003 06:47:23 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id 78C496BFDA; Wed, 16 Jul 2003 12:47:00 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id MAA19104; Wed, 16 Jul 2003 12:47:00 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id MAA13247; Wed, 16 Jul 2003 12:46:59 +0200 (MEST) Subject: RE: [MMUSIC] stream switching To: "Gamze Seckin" Cc: "Magnus Westerlund" , mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 16 Jul 2003 12:37:38 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 16/07/2003 12:48:05 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: , Gamze, Thank you for your feedback! > I believe the draft tries to cover far too many requirements > that are rate control related (which have been/are discussed in other wg's). I am sorry it gives this impression. rate control is EXPLICITELY out of the scope. clearly rate control is dealt with using TFRC, DCCP etc ====The scope is purely media/codec control.==== I tried however to be exhaustive about the context and of course rate control is at the hearth of it ;-) >... since video stream switches are really not a big issue, I am *extremely* surprised you can say this, did you try to feed a MPEG-4 video stream into a H263 decoder recently ? what about screen size changes? when a video decoder tries to write into a display buffer an image larger than the buffer the result is never pretty to see!-) > whereas audio switches require more complicated solutions that may impact the user experience. yes, audio is totally critical since it does not suffer any gap. > And hence we should discuss and recommend solutions for those.. I would be horrified to limit the scope to audio! the point on the contrary is to be able to switch streams of all types, audio, video, text, you name it. (streaming text is a use case that is missing in the document) (I dont think anybody will ever need to switch text streams for rate control reasons however) there is the case where the user wants to switch from the italian subtitles into the german subtitles. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: "Magnus Westerlund" Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: Subject: RE: [MMUSIC] stream switching "Gamze Seckin" Classification: Sent by: mmusic-admin@ietf.org 16/07/2003 11:27 hi Philippe, I agree with Magnus's comments on differentiating content rate from transmission rate and keeping an eye on reciever buffer overflow and underflow. These are all valid and useful discussions but I believe are out of the scope of the stream switching documents (please correct me if I am wrong).I believe the draft tries to cover far too many requirements that are rate control related (which have been/are discussed in other wg's). I personally would expect these two drafts on stream switching to be more specific on codec change support and addressing the issues of the transport (more serious problems that need an answer). I think section 2.5 is the core of the document, since video stream switches are really not a big issue, whereas audio switches require more complicated solutions that may impact the user experience. And hence we should discuss and recommend solutions for those.. thanks -gamze seckin -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Mon 7/14/2003 5:40 AM To: philippe.gentric@philips.com Cc: mmusic@ietf.org Subject: Re: [MMUSIC] stream switching Hi Phillipe, I hope that I can clarify anything that was unclear. I also has some further comments, see below. philippe.gentric@philips.com wrote: >Magnus, you wrote: > > >>To enable this the complete system must ensure the following things: >>- Congestion Control or rather adapting transmission rates to available >>network rate => avoiding high packet loss rates that severely effect >>quality. >> >> > > yes > > > >>- Avoid that the receivers buffers either under flow (causes interrupt) >>or overflow (show up as packet loss). >> >> >> > > yes, this is fundamental for seamless-ness > > > >>Based on this one can arrive at the conclusion that the media or content >>rate must be adapted, otherwise the underflow condition will be >>impossible to avoid. If one performs content adaptation towards lower >>bit-rates one must also perform adaptation towards higher rates. >> >> >> > > I am not sure about this "must", could it be that your are > considering differently media rate and transmission rate ? > > What I mean is that if the available transmission rate is less the media rate then you on some time scale if nothing changes you will empty your buffer. Therefore you "must" change the media rate to avoid this or have interrupts. I don't know about any other solution. > because I am not considering changing the transmission rate (as a > end-to-end application issue) => stream switching is only about > changing the *media* rate. > I don't think you can exclude the transmission rate from the equation. In my opinion you need to consider transmission rate, receiver buffers, and the media rate all together. > > what I want to mean is you dont *need* to increase the media rate > to avoid undeflows but instead you may *want* to increase the > media rate in order to improve the user experience in terms of > image quality... > I am not sure what you mean, but I guess the following. In cases you are not transmission rate limited one is not required to increase the media rate, however it is commonly desired. I can agree that there are some need to allow the receiver to specify what is allowed in respect to media rate modifications. > > > >>This I think is the basic requirement and assumptions that apply to your >>requirements draft. >> >>Based on this any solution can be divided up into different >>functionality blocks: >> >>- Transmission rate control, this functionality ensures that a sender >>does not send more data then the network can transport without being to >>unfair, or overflow network buffers. >> >> >> > > hum, again i prefer the term "media rate control" if you dont mind? > No, I don't think you completely understand. In a system where the buffer space is known you don't have to transmit the data in the same rate as the media rate. Due to the buffer one can during some parts of the session transmit data at rates that are both higher and lower than the media rate. However when doing this you need to ensure that you are not under or overflowing the receiver buffer. What you try to do is to simplify this system to basically say that the transmission rate is equal to media rate which I think prevents better performance. If any one does not understand this, please prod me and I will try to provide a better explanation of the complete system. > > > >>- Receiver buffer control, this functionality ensure that one does not >>overflow the client's receiver buffers. >> >> >> > > yes, not sure there is much to "do" there in terms of IETF spec? > There is nothing in IETF that allows feedback or even specification about the receiver buffers to or by the sending side. This is analogous to TCP's receiver window that allow to control the flow of media. > > > > >>- Content rate control, functionality to ensure that the transmitted >>date fits the available network rate, while at the same time ensure that >>the receiver buffer does not underflow. >> >> >> > > yes! this is stream switching principle, but again it is about > "media rate", not changing the transmission rate. > This I can agree is what you describe as media rate control. By selecting or controlling the media rate one can meet the requirements of transmission rate and receiver buffers. > > > >>Based on this functionality blocks one can use one or several >>protocols/solutions to realize them. They do not need to be separate and >>can utilize information enabled by any of the other functionality >>blocks. However I believe that all parts must be present to have a >>complete solution. Also how to realize the solutions is a not fixed by >>this. >> >>I would suggest that one tries to group the requirements regarding which >>of the functionality's they address. >> >> >> > > Which groups would you suggest ? > Some suggestions would be: Media requirements: Requirements to prevent the media from being corrupted or worsen quality, like limited packet losses, gap free switching, RAP,etc. Signalling requirements: Requirements that are a related to what the signalling mechanism needs to achieve. System requirements: Requirements that have more general feeling, like backwards compatibility, etc. > > > > >>When one comes to solution one must start discussing what control >>paradigm one desires, as it will heavily influence the solution. Three >>different ones are: >>- Server controlled: In this the server is the responsible for all >>decisions regarding the adaptation. The client simply reports certain >>measurements that the server interprets. >> >>- Client controlled: The client makes the decisions and interpretations >>of what it see. Then it issues commands to the server that it must >>follow. The server is a simple slave. >> >> >> > > slave, yes, but a slave that *could* refuse to obey ;-) e.g. as > discussed in my draft for rate control a server must be allowed to > deny a request for a higher data rate... > > > In a true client control paradigm, this may not even be true. But the basic point is that the requirements may motivate the choice, but we should not choice a a paradigm and then write the requirements to fulfil them. I have a rather long list of comments to when this discussion needs to be started. > > >>- Hybrid control: In a hybrid control scenario both client and servers >>makes decisions and interpretations of the data. >> >>I will not try to compare these solutions this if for future >>discussions. If one is interested in a server controlled solution one >>can look at the latest proposal in 3GPP SA4: >>http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_27/Docs/S4-030501.zip >>Look at the buffer reporting mode variant. This proposal provides >>receiver buffer control and content rate control. The transmission rate >>control is handled through RTCP reports with enabled extended reports of >>packet loss vectors. >> >> >> > > I have to say that using such RTCP extensions looks very much like > "client control" to me ;-) but I dont really care about the > terminology ;-) > Actually the mechanism in my opinion is very server controlled. The client provides the server side with some parameters telling it what to achieve. Then the client provides regular feedback to allow the server to run the algorithms and control the whole system. > > > > >>Some more direct comments on the draft: >> >>1. Introduction: The encoding could be done in real time allowing >>maximum flexibility in the produced content rate. However this is may >>not result in optimal encodings and are also very resource demanding for >>a server. >> >> >> > > > yes, I did not mention this possibility because in large scale > media distribution this would effectively require one "production" > encoder per client, which is -even in several years from now- way > beyond the cost points for this type of products. > > I think that spending two sentences on this is useful, just to make it clear that it has been considered but has significant problems. > > > >>2. Section 2.1.1 and 2.1.2: I think the behaviour in this case should >>really be depending on the operators policies. I would not like to have >>my expensively paid on demand video reduced in quality if this network >>is of the type you describe. However I can see that we should enable this. >> >> > > > Yes, you are right, all this assumes the correct commercial > agreements are in place. Our experience is however that a end user > always prefers a continuous playback, even a degraded one, > providing that the degradation is "resonable", all other solutions > including "freezes" for rebuffereing are not acceptable for the > wide public who is accustomed to TV ;-( > >From an IETF point of view (hey, just giving my own opinion ;-) >I think it would be a good idea that implementations *by default* >would "behave a la TFRC" rather than what we have today, >because otherwise -as sally floyd pointed out this morning- >we would run into rather nasty trouble. > Yes, I agree that over any best effort network you need some type of congestion avoidance. So default behaviour is good, however we must also allow for systems that has QoS agreements. > > > > >>3. Section 2.2: I think you need to be a bit more clear that this is one >>example of a service. Also the AMR rate of 5 kbps is a bit to low. The >>4.75 kbps mode has a quality that is not the best. However to achieve >>this bit-rate you must only send one AMR packet every 1.28 seconds, >>which means 64 amr frames per packet. This is not realistic as every >>packet will be required to reach the receiver to achieve acceptable >>quality. I would think that reasonable AMR qualities are using at least >>10 packet every second, meaning that a header overhead of 3 kbps. >> >> >> > > right. > > > >>4. Section 2.5: I think this section assumes something that are not >>quite true. First the impossibility to signal this rate switch using >>current protocols. >> >> > > What *is* impossible is to find a comprehensive spec for stream > switching !-) and it is my intention to provide one, i would love to > "use the current protocols"! > > > >>I claim it is possible but most likely not supported >>by any available client. >> >> > > And that would be the point in writing that spec... > > > >>To signal the rate switch in SDP you present >>one different RTP payload types for each codec and configuration, most >>likely at least 4 maybe 5. The 40 and 50 kbps AAC stereo may be possible >>to encode using the same AAC configuration. The declared payload types >>are present in a SDP. A client shall not accept the session and setup >>the media stream unless it can handle all these codecs. If it has setup >>this media stream it has in fact accepted that any of the codec may be >>used in the media stream. >> >> >> > > well, I completely agree that *that* may be a solution to stream > switching, the point then would be to document it!-) > > Good, then you should rather document this deficiency rather than claiming that it is possible. > > > >>The server can here use different strategies when switching. The most >>likely one is to use a single SSRC and in the same RTP sequence number >>and timestamp space send the selected media quality. >> >> > > agreed, this is a very nice possibility...that obvioulsy we would > need to *seriouly* document ... because this is not the "default" > thing at all from existing specs, right? > > > I have seen it as being the default behaviour, however this is nothing that has been thoroughly discussed in AVT and the RTP spec not be that clear on this point. Documenting this would be a good thing. > > >>When the server >>switched this will be indicated by the new RTP PT. This has a slight >>problem as RTP/RTCP does not handle switched RTP TS rate perfectly. The >>client may in fact lose synchronization until it receives a RTCP packet >>after the switch has taken place. >> >> > > right! that is a key issue! > > > >>This happens if the packet where the >>RTP TS rate switches is lost. This is not a problem as long as the RTP >>TS rate before and after the payload type switch has the same TS rate. >>In other words not a problem for any video codec which all runs at >>90000. >> >> > > yes, not a problem *if* (as mentioned above) you mandate the same > RTPTS space for all streams ... > > > >>This is more a problem for audio codecs. I would in fact try to >>address this problem with audio codecs by ensuring that any audio codec >>is allowed to select a RTP TS rate that is a even rate multiple of its >>native value. This would allow audio codecs to run at a the smallest >>common denominator rate. >> >> >> > > Is it always possible/efficient? > No, not for the currently specified RTP payload formats. It is something I will recommend in future payload formats to allow for this functionality. > > > >>The other strategy at points of switching would be to use different >>SSRCs. This would violate the semantics that a SSRC represents a certain >>source. This also has some problems with the synchronization of the >>different SSRCs. This can't be done in RTSP as RTSP due to an erroneous >>definition of RTP-Info did not map each synchronization information to >>the SSRC. This can only be fixed through a new header due to backwards >>compatibility problems. Otherwise RTCP could be used. By sending SR for >>all SSRC one could in fact ensure that the synchronization is available. >>It will utilize more RTCP bandwidth. >> >> >> > >Hum, so we should disregard this option? > I think so. > > > >>5. Section 3.1.2: I don't think you should mix congestion control with >>adaptation control that hard. In my opinion, how drastic a content rate >>change is needed and how much depends on the clients buffer status. >> >> >> > >sorry, I do not understand that one? > This has to do with the complete system that a sender can transmit at one rate, while the media rate has another rate. The discrepancy is handled by the receiver buffer. Therefore the control of the media rate can be performed more drastic or not depending on what the buffer status is. An almost empty receiver buffer needs to be handled quickly and drastically, probably be reducing the media rate significantly. If the buffer are rather full the handling of this can be much less drastic, a small discrepancy can simply be tried to waited out. Or the quality change can be minimal. > > > > > >>8. Section 3.7: I don't think we can deploy a solution for switching >>that gives full functionality and at the same time is backwards >>compatible. However think on how one can maintain some of the >>functionality and being backwards compatible may be a worth the effort. >>However this is rather a design evaluation criteria than a requirement. >> >> >> > > do you mean it is not appropriate to have backward compatibility as > a requirement? > > > It might, however I think it should be further considered. I think listing the level as critical is to high level. Cheers Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 07:32:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26145 for ; Wed, 16 Jul 2003 07:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckW2-0003yf-TC for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 07:32:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBWASq015283 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 07:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckW2-0003yQ-Pw for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26137 for ; Wed, 16 Jul 2003 07:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckW2-0006AJ-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 07:32:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ckVw-0006AG-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 07:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckVt-0003wE-B7; Wed, 16 Jul 2003 07:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckVT-0003um-Tj for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 07:31:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26114 for ; Wed, 16 Jul 2003 07:31:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckVT-00069m-00 for mmusic@ietf.org; Wed, 16 Jul 2003 07:31:35 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19ckVI-00067o-00 for mmusic@ietf.org; Wed, 16 Jul 2003 07:31:24 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19ckT3-0007Hd-00; Wed, 16 Jul 2003 04:29:05 -0700 Date: Wed, 16 Jul 2003 04:29:05 -0700 From: Tom Marshall To: Magnus Westerlund Cc: Geetha Srikantan , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP discussion today Message-ID: <20030716112905.GA27952@real.com> References: <200307160945.CAA20388@phys-ha1mpka.eng.sun.com> <3F15218A.6050005@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <3F15218A.6050005@ericsson.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >I have been thinking about how 'playlists' may be supported with RTSP/RT= P. > >Playlists are what one might use in an internet radio session for=20 > >instance, pre-program a set of songs that are to be played out in sequen= ce=20 > >on the same > >RTP session. > >Would it be possible to discuss this topic at the meeting today? It seems to me there are two types of playlists: those created on the server side (pre-set) and those created on the client side (dynamic). Which are you interested in? I can see ways of supporting both today without any RTSP or RTP extensions. > The REASON for having this clarification of the usage of RTP timestamps= =20 > are RTP and RTCP itself. The RTCP based synchronization and reporting=20 > would be very confused if you did not have continuos timestamp space. IF= =20 > you would go stop the RTP timestamp space during pause while RTCP keeps= =20 > advancing it at the defined rate parts of the TS space will be reused=20 > and the RTCP synchronization information will be impossible to match=20 > against the RTSP synchronization information. I have observed in conversations that opinions vary as to whether RTCP should continue to be sent during the PAUSE period. Perhaps this issue deserves clarification? --=20 Under any conditions, anywhere, whatever you are doing, there is some ordinance under which you can be booked. -- Robert D. Sprecht, Rand Corp. --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/FTcBqznSmcYu2m8RAoGtAJ0XJa3hilsFf4wfTvAIz/ZFAwvubACeNdMM odiXydwWjwt1ALHdYKN/+8k= =/U1h -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 09:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00005 for ; Wed, 16 Jul 2003 09:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmcf-0003iT-0c for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 09:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GDl87l014277 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 09:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmce-0003iB-L0 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 09:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29978 for ; Wed, 16 Jul 2003 09:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmcc-0007GQ-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 09:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cmcW-0007GN-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 09:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmcX-0003g3-2J; Wed, 16 Jul 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmbi-0003dD-EN for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 09:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29946 for ; Wed, 16 Jul 2003 09:46:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmbg-0007Fb-00 for mmusic@ietf.org; Wed, 16 Jul 2003 09:46:08 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19cmbV-0007FK-00 for mmusic@ietf.org; Wed, 16 Jul 2003 09:45:57 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GDj5pi005219; Wed, 16 Jul 2003 06:45:05 -0700 (PDT) Received: from jamba (jamba [129.146.125.67]) by phys-ha1mpka.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id GAA26291; Wed, 16 Jul 2003 06:45:04 -0700 (PDT) Message-Id: <200307161345.GAA26291@phys-ha1mpka.eng.sun.com> Date: Wed, 16 Jul 2003 06:45:04 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan Subject: Re: [MMUSIC] RTSP discussion today To: magnus.westerlund@ericsson.com, tmarshall@real.com Cc: Geetha.Srikantan@sun.com, mmusic@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yQawEz3XeiG3Q8tBHX9PCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > > >I have been thinking about how 'playlists' may be supported with RTSP/RTP. > > >Playlists are what one might use in an internet radio session for > > >instance, pre-program a set of songs that are to be played out in sequence > > >on the same > > >RTP session. > > >Would it be possible to discuss this topic at the meeting today? > > It seems to me there are two types of playlists: those created on the server > side (pre-set) and those created on the client side (dynamic). Which are > you interested in? I can see ways of supporting both today without any RTSP > or RTP extensions. Server side playlists are most iteresting to me. I'm not sure that RTSP or RTP extensions are needed, either. > > > The REASON for having this clarification of the usage of RTP timestamps > > are RTP and RTCP itself. The RTCP based synchronization and reporting > > would be very confused if you did not have continuos timestamp space. IF > > you would go stop the RTP timestamp space during pause while RTCP keeps > > advancing it at the defined rate parts of the TS space will be reused > > and the RTCP synchronization information will be impossible to match > > against the RTSP synchronization information. > > I have observed in conversations that opinions vary as to whether RTCP > should continue to be sent during the PAUSE period. Perhaps this issue > deserves clarification? That's definitely something to discuss as well. geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 09:59:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00588 for ; Wed, 16 Jul 2003 09:59:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmoe-0004Vd-0v for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 09:59:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GDxWsY017331 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 09:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmod-0004VS-UM for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 09:59:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00560 for ; Wed, 16 Jul 2003 09:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmo8-0004RJ-PZ; Wed, 16 Jul 2003 09:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmo2-0004Qr-DN for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 09:58:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00518 for ; Wed, 16 Jul 2003 09:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmo0-0007MU-00 for mmusic@ietf.org; Wed, 16 Jul 2003 09:58:52 -0400 Received: from [81.160.147.207] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19cmno-0007M1-00 for mmusic@ietf.org; Wed, 16 Jul 2003 09:58:41 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6GDvjd1004270 for ; Wed, 16 Jul 2003 14:57:46 +0100 (BST) (envelope-from csp@csperkins.org) Date: Wed, 16 Jul 2003 15:57:45 +0200 From: Colin Perkins To: mmusic@ietf.org Message-Id: <20030716155745.0998862c.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] IESG comments on SDPnew Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 IESG recently review the SDPnew draft, and sent the following comments. I'll be talking about these in MMUSIC tomorrow. Colin >Ned Freed: >This document should explicitly say it obsoletes RFC 2327. > >This document apparently defines the application/sdp media type, replacing >the definition in RFC 2327, but contains no media type registration form >nor any IANA action associated with the registration. (This was also true >of RFC 2327.) > >A 44 page document REALLY needs a table of contents. (I realize the RFC >Editor is supposed to deal with this, but RFC 2327 is 42 pages and didn't >have a TOC either.) > >That's it! > >Steve: >k= strikes me as almost useless. It doesn't have enough information >(such as algorithm) to really be usable. I see no protection against >replay prevention, nor any mention of that as a requirement for secure >transport of SDP announcements. In fact, nothing is said about channel >requirements in this context other than "secure and trusted". Is k= >really used? Should it be deleted in favor of a pointer to >draft-ietf-mmusic-sdescriptions? > >The Security Consideration section says that automatic mechanisms >SHOULD NOT be used to start up interactive applications without user >knowledge. I'd prefer MUST NOT, and I'd ask for consent, not simplhy >knowledge. See the /dev/audio part of >http://www.cert.org/advisories/CA-1993-15.html for why this is a >problem... > >Russ: > Section 4.3 talks about private sessions. It says: > > "The details of how encryption is performed are dependent on > the mechanism used to convey SDP - e.g. mechanisms are defined > for SDP transported using SAP [RFC2974] and SIP [RFC3261]." > > Why aren't S/MIME for email and TLS for WWW included here? > > In section 5, the discussion of encryption keys says: > > "k=clear: > > The encryption key is included untransformed in this key > field. This method MUST NOT be used unless it can be > guaranteed that the SDP is conveyed over a secure channel. > > k=base64: > > The encryption key is included in this key field but has > been base64 encoded because it includes characters that are > prohibited in SDP. This method MUST NOT be used unless it > can be guaranteed that the SDP is conveyed over a secure > channel." > > These restrictions are necessary but not sufficient. You must also >ensure that the secure channel is with the party that is authorized to >join the session, not an intermediary. If a caching server is used, there >ought to be a way to keep the server from accessing the key. > > Also, it is generally a good idea to indicate the algorithm that a >cryptographic key is intended to support. I suggest that the encryption >key type be revised to specify the key as well as the algorithm that the >key will be used with. > > Finally, many security protocols require two keys, one for >confidentiality and another for integrity. This specification does not >support the transfer of two keys. > > In section 6, the document says: > > "Use of the "k=" field poses a significant security risk, > since it conveys session encryption keys in the clear. SDP > MUST NOT be used to convey key material, unless it can be > guaranteed that the channel over which the SDP is delivered is > both private and authenticated." > > I agree. It would therefore be desirable for the "k=" field to > support >two other alternatives. First, it would be nice to name the key without >actually including the key. In PEM (see RFC 1040), the Recipient-ID was >used to name key-encryption keys, and a similar scheme could be employed >here. Second, it would be nice to encrypt the session key in a key that is >not included in SDP. PEM also includes a mechanism for wrapped symmetric >keys. > >Ted: >In Section 5, for the description of u= > > I'd suggest eliminating "as used by WWW clients." and adding a > citation to draft-fielding-uri-rfc2396bis (or at least rfc2396). > Note that this definition seems to presume that all URIs used > will be dereferencable, which is not true for all URIs. If this > is a limitation, then it should be stated. > > The k= also seems to presume that the URI is > dereferencable. If this is a limitation of the URI, it should be > made explicit >which schemes > are appropriate here. Frankly, it seems to mean http:; if that > is the case, specifying it seems like a good idea. Even for > dereferencable URI schemes, not all will use MIME to mark the > reply (think of an ftp: URI, for example). When they do, the > mime content-encoding specifies the encoding of the _message_, > so reusing the word"encoding" here seems problematic. How would > "For those URI schemes which use MIME, the content-encoding and > content-type headers of the reply may provide guidance on the > format of the key." work? > > On that same hobby horse, the ABNF in the appendix has: > ; sub-rules of 'u=' > uri = URI-reference; see RFC1630 and RFC2732 > > I think this should be a pointer to 2396 or the 2396bis draft. > > For the a= inactive designation, we've discussed what addresses > to use for sessions which are being set up but for which > addresses are not > yet known. It was suggested apps use something like "sdp.inactive" so > that the .inactive TLD could reinforce the a=inactive flag. In that > instance, would the presence of that TLD be a condition under which > the RTCP SHOULD is appropriately not done, and no RTCP sent? If so, is > mentioning that case appropriate here? > > In the IANA considerations, it looks the draft should specify > that the > IANA must update the MIME media type registration to point to this doc > instead of RFC 2327. > >Notes: > >Having Section 5 contain so much without sub-headers made it hard to >give pointers to sections in the comments; that may be true for others >using the spec as well. > >In section 5, in the section describing the first subfield of c= > Just as a query, has anyone considered using a specific marker > of private address realms for SDP? That is, using a network type > other than IN to indicate that the domain name or address given > are not globally unique/globally reachable? > >In the Security considerations, "Many different protocols may be used >to distribute session description," looks like session description should >be plural. > >Bill: >In the ABNF, the definition of "m1" ends with an extra ). > > >The text says that type characters are case-sensitive. >Unfortunately, this means that ASCII values have to be >used in the ABNF instead of strings, since ABNF strings >are case-insensitive. e.g. > > proto-version = "v=" 1*DIGIT CRLF > >really has to be something like > > proto-version = %x76 "=" 1*DIGIT CRLF >or > proto-version = %x76.3d 1*DIGIT CRLF > >since both "v=0" and "V=0" match the one with "v=". > >I realize that this latter error is copied from RFC 2327. If this is >the only objection I'm not going to stand on it too strongly. > > Bill > >COMMENTS: >======== >Erik Nordmark: >Intro/abstract doesn't say the document obsoletes RFC 2137, which >I think is the intent. > >The text on internationalization says UTF-8 only applies to informational >fields. Does this mean it isn't required to perform any normalization >whatsoever on the UTF-8? >Would it make sense to explicitly state that normalization isn't needed. > >Typo: > removed. It is assumed that transports of SDP specify will > specify this. >s/specify// > -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 10:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02733 for ; Wed, 16 Jul 2003 10:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cn5h-0005dA-9w for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 10:17:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GEH9St021638 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 10:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cn5h-0005cv-5r for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 10:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02703 for ; Wed, 16 Jul 2003 10:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cn5e-0007a6-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 10:17:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cn5Z-0007a3-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 10:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cn5Z-0005cN-LD; Wed, 16 Jul 2003 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cn5K-0005bD-Fh for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 10:16:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02674 for ; Wed, 16 Jul 2003 10:16:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cn5H-0007Zs-00 for mmusic@ietf.org; Wed, 16 Jul 2003 10:16:44 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19cn56-0007Wk-00 for mmusic@ietf.org; Wed, 16 Jul 2003 10:16:33 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6GEDXGJ026390; Wed, 16 Jul 2003 16:13:33 +0200 (MEST) Received: from ericsson.com (permit154.er.ki.sw.ericsson.se [147.214.97.154]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XKT7QG; Wed, 16 Jul 2003 16:13:33 +0200 Message-ID: <3F155D88.2010605@ericsson.com> Date: Wed, 16 Jul 2003 16:13:28 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Geetha Srikantan , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP discussion today References: <20030716112905.GA27952@real.com> In-Reply-To: <20030716112905.GA27952@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 >I have observed in conversations that opinions vary as to whether RTCP >should continue to be sent during the PAUSE period. Perhaps this issue >deserves clarification? > > Yes, this should be clarified in the specification. It is expected that RTCP is sent at all time during session from SETUP to TEARDOWN. I have logged a tracking bug for this. Best Regards Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 10:33:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03658 for ; Wed, 16 Jul 2003 10:33:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnLF-0006cS-48 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 10:33:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GEXD1r025441 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 10:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnLC-0006bx-53 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 10:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03577 for ; Wed, 16 Jul 2003 10:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnL9-0007mT-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 10:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cnL3-0007mQ-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 10:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnL3-0006b3-9u; Wed, 16 Jul 2003 10:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnKg-0006aR-CN for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 10:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03536 for ; Wed, 16 Jul 2003 10:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnKe-0007lj-00 for mmusic@ietf.org; Wed, 16 Jul 2003 10:32:36 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cnKT-0007jw-00 for mmusic@ietf.org; Wed, 16 Jul 2003 10:32:25 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn1-373.cisco.com [10.21.97.117]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6GEUbuH029116; Wed, 16 Jul 2003 07:30:37 -0700 (PDT) Message-Id: <5.1.1.5.2.20030716072453.0650ec80@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 16 Jul 2003 07:30:37 -0700 To: Colin Perkins From: Mark Baugher Subject: Re: [MMUSIC] IESG comments on SDPnew Cc: mmusic@ietf.org, Russ Housley , oran@cisco.com, mat@cisco.com In-Reply-To: <20030716155745.0998862c.csp@csperkins.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: , Colin, I'd like to comment on Russ's comment. See below. At 03:57 PM 7/16/2003 +0200, Colin Perkins wrote: >The IESG recently review the SDPnew draft, and sent the following comments. >I'll be talking about these in MMUSIC tomorrow. > >Colin > > > >Ned Freed: > >This document should explicitly say it obsoletes RFC 2327. > > > >This document apparently defines the application/sdp media type, replacing > >the definition in RFC 2327, but contains no media type registration form > >nor any IANA action associated with the registration. (This was also true > >of RFC 2327.) > > > >A 44 page document REALLY needs a table of contents. (I realize the RFC > >Editor is supposed to deal with this, but RFC 2327 is 42 pages and didn't > >have a TOC either.) > > > >That's it! > > > >Steve: > >k= strikes me as almost useless. It doesn't have enough information > >(such as algorithm) to really be usable. I see no protection against > >replay prevention, nor any mention of that as a requirement for secure > >transport of SDP announcements. In fact, nothing is said about channel > >requirements in this context other than "secure and trusted". Is k= > >really used? Should it be deleted in favor of a pointer to > >draft-ietf-mmusic-sdescriptions? > > > >The Security Consideration section says that automatic mechanisms > >SHOULD NOT be used to start up interactive applications without user > >knowledge. I'd prefer MUST NOT, and I'd ask for consent, not simplhy > >knowledge. See the /dev/audio part of > >http://www.cert.org/advisories/CA-1993-15.html for why this is a > >problem... > > > >Russ: > > Section 4.3 talks about private sessions. It says: > > > > "The details of how encryption is performed are dependent on > > the mechanism used to convey SDP - e.g. mechanisms are defined > > for SDP transported using SAP [RFC2974] and SIP [RFC3261]." > > > > Why aren't S/MIME for email and TLS for WWW included here? > > > > In section 5, the discussion of encryption keys says: > > > > "k=clear: > > > > The encryption key is included untransformed in this key > > field. This method MUST NOT be used unless it can be > > guaranteed that the SDP is conveyed over a secure channel. > > > > k=base64: > > > > The encryption key is included in this key field but has > > been base64 encoded because it includes characters that are > > prohibited in SDP. This method MUST NOT be used unless it > > can be guaranteed that the SDP is conveyed over a secure > > channel." > > > > These restrictions are necessary but not sufficient. You must also > >ensure that the secure channel is with the party that is authorized to > >join the session, not an intermediary. If a caching server is used, there > >ought to be a way to keep the server from accessing the key. > > > > Also, it is generally a good idea to indicate the algorithm that a > >cryptographic key is intended to support. I suggest that the encryption > >key type be revised to specify the key as well as the algorithm that the > >key will be used with. > > > > Finally, many security protocols require two keys, one for > >confidentiality and another for integrity. This specification does not > >support the transfer of two keys. > > > > In section 6, the document says: > > > > "Use of the "k=" field poses a significant security risk, > > since it conveys session encryption keys in the clear. SDP > > MUST NOT be used to convey key material, unless it can be > > guaranteed that the channel over which the SDP is delivered is > > both private and authenticated." > > > > I agree. It would therefore be desirable for the "k=" field to > > support > >two other alternatives. First, it would be nice to name the key without > >actually including the key. In PEM (see RFC 1040), the Recipient-ID was > >used to name key-encryption keys, and a similar scheme could be employed > >here. Second, it would be nice to encrypt the session key in a key that is > >not included in SDP. PEM also includes a mechanism for wrapped symmetric > >keys. I think it would be wrong to place security mechanisms inside SDP since SDP is used with an encapsulating protocol. SDP needs to use the mechanisms of the encapsulating protocol for protecting its keys, cryptographic parameters, session security parameters, and other descriptions that are of security interest. That being said, I agree with Russ and Steve that k= is under-specified. That's what I found a year ago when I needed to use it for SRTP. Mark > > > >Ted: > >In Section 5, for the description of u= > > > > I'd suggest eliminating "as used by WWW clients." and adding a > > citation to draft-fielding-uri-rfc2396bis (or at least rfc2396). > > Note that this definition seems to presume that all URIs used > > will be dereferencable, which is not true for all URIs. If this > > is a limitation, then it should be stated. > > > > The k= also seems to presume that the URI is > > dereferencable. If this is a limitation of the URI, it should be > > made explicit > >which schemes > > are appropriate here. Frankly, it seems to mean http:; if that > > is the case, specifying it seems like a good idea. Even for > > dereferencable URI schemes, not all will use MIME to mark the > > reply (think of an ftp: URI, for example). When they do, the > > mime content-encoding specifies the encoding of the _message_, > > so reusing the word"encoding" here seems problematic. How would > > "For those URI schemes which use MIME, the content-encoding and > > content-type headers of the reply may provide guidance on the > > format of the key." work? > > > > On that same hobby horse, the ABNF in the appendix has: > > ; sub-rules of 'u=' > > uri = URI-reference; see RFC1630 and RFC2732 > > > > I think this should be a pointer to 2396 or the 2396bis draft. > > > > For the a= inactive designation, we've discussed what addresses > > to use for sessions which are being set up but for which > > addresses are not > > yet known. It was suggested apps use something like > "sdp.inactive" so > > that the .inactive TLD could reinforce the a=inactive flag. In that > > instance, would the presence of that TLD be a condition under which > > the RTCP SHOULD is appropriately not done, and no RTCP sent? If > so, is > > mentioning that case appropriate here? > > > > In the IANA considerations, it looks the draft should specify > > that the > > IANA must update the MIME media type registration to point to > this doc > > instead of RFC 2327. > > > >Notes: > > > >Having Section 5 contain so much without sub-headers made it hard to > >give pointers to sections in the comments; that may be true for others > >using the spec as well. > > > >In section 5, in the section describing the first subfield of c= > > Just as a query, has anyone considered using a specific marker > > of private address realms for SDP? That is, using a network type > > other than IN to indicate that the domain name or address given > > are not globally unique/globally reachable? > > > >In the Security considerations, "Many different protocols may be used > >to distribute session description," looks like session description should > >be plural. > > > >Bill: > >In the ABNF, the definition of "m1" ends with an extra ). > > > > > >The text says that type characters are case-sensitive. > >Unfortunately, this means that ASCII values have to be > >used in the ABNF instead of strings, since ABNF strings > >are case-insensitive. e.g. > > > > proto-version = "v=" 1*DIGIT CRLF > > > >really has to be something like > > > > proto-version = %x76 "=" 1*DIGIT CRLF > >or > > proto-version = %x76.3d 1*DIGIT CRLF > > > >since both "v=0" and "V=0" match the one with "v=". > > > >I realize that this latter error is copied from RFC 2327. If this is > >the only objection I'm not going to stand on it too strongly. > > > > Bill > > > >COMMENTS: > >======== > >Erik Nordmark: > >Intro/abstract doesn't say the document obsoletes RFC 2137, which > >I think is the intent. > > > >The text on internationalization says UTF-8 only applies to informational > >fields. Does this mean it isn't required to perform any normalization > >whatsoever on the UTF-8? > >Would it make sense to explicitly state that normalization isn't needed. > > > >Typo: > > removed. It is assumed that transports of SDP specify will > > specify this. > >s/specify// > > > > >-- >Colin Perkins >csp@csperkins.org > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 11:01:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05147 for ; Wed, 16 Jul 2003 11:01:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnmW-0000A4-Kb for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 11:01:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GF1OT3000614 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 11:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnmW-00009l-GK for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:01:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05118 for ; Wed, 16 Jul 2003 11:01:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnmT-0000H7-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 11:01:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cnmN-0000Gl-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 11:01:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnm9-00005r-RJ; Wed, 16 Jul 2003 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnla-000058-CD for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 11:00:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05084 for ; Wed, 16 Jul 2003 11:00:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnlX-0000GX-00 for mmusic@ietf.org; Wed, 16 Jul 2003 11:00:23 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 19cnlH-0000Dr-00 for mmusic@ietf.org; Wed, 16 Jul 2003 11:00:08 -0400 Received: from vinland.uninett.no (vinland.uninett.no [IPv6:2001:700:1:4:290:27ff:fe2f:d17a] (may be forged)) by tyholt.uninett.no (8.12.9/8.12.6) with ESMTP id h6GEwUTY009280; Wed, 16 Jul 2003 16:58:30 +0200 Received: (from taliesin@localhost) by vinland.uninett.no (8.11.6/8.11.6) id h6GEwU814963; Wed, 16 Jul 2003 16:58:30 +0200 Date: Wed, 16 Jul 2003 16:58:30 +0200 From: Hanne Moa To: Colin Perkins Cc: mmusic@ietf.org Subject: Re: [MMUSIC] IESG comments on SDPnew Message-ID: <20030716165830.B14497@vinland.uninett.no> References: <20030716155745.0998862c.csp@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030716155745.0998862c.csp@csperkins.org>; from csp@csperkins.org on Wed, Jul 16, 2003 at 03:57:45PM +0200 X-No-Archive: Yes X-Disclaimer: I speak for myself. Beware of humor. Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , * On 2003-07-16 15:57:45 +0200 Colin Perkins wrote: > The IESG recently review the SDPnew draft, and sent the following comments. > I'll be talking about these in MMUSIC tomorrow. > > Colin > > >Steve: > >k= strikes me as almost useless. It doesn't have enough information > >(such as algorithm) to really be usable. I see no protection against > >replay prevention, nor any mention of that as a requirement for secure > >transport of SDP announcements. In fact, nothing is said about channel > >requirements in this context other than "secure and trusted". Is k= > >really used? I've been monitoring SAP-packets for over a year now and never seen it. Ditto for z= (time zone adjustments). Furthermore, more than 90% of sdp over sap is unspecified for time, that is: t=0 0. It is used for just about anything: on-demand, 24/7 webcams, conferences... It is so vague as to be useless. Here's one from today: v=0 o=- 12157 2 IN IP4 128.223.83.33 s=IETF 57 Channel-1 MPEG-4 i=IETF57 - Channel-1 MPEG-4 e=multicast@lists.uoregon.edu <--- wow, one of the 5% valid ones! b=AS:500 t=0 0 <--- a-hum a=tool:IP/TV Content Manager 3.4.14 a=type:broadcast a=live:capture:1 m=video 49470 RTP/AVP 31 32 96 97 c=IN IP4 224.2.195.59/127 a=x-iptv-videoheight:240 a=x-iptv-videowidth:320 a=x-iptv-svr:video 81.160.32.4 live a=quality:8 a=framerate:30 a=fmtp:96 profile-level-id=1;config=000001B001000001B50EE04040AF0000010000000120 00845D4C285020F0A31F a=rtpmap:96 MP4V-ES/90000 a=rtpmap:97 WBIH/90000 m=audio 19154 RTP/AVP 0 3 5 10 11 14 96 97 98 99 100 101 102 103 104 105 106 c=IN IP4 224.2.166.105/127 a=x-iptv-svr:audio 81.160.32.4 live a=fmtp:14 layer=3; samplerate=11025; mode=stereo; a=rtpmap:96 X-WAVE/8000 a=rtpmap:97 L8/8000/2 a=rtpmap:98 L8/8000 a=rtpmap:99 L8/22050/2 a=rtpmap:100 L8/22050 a=rtpmap:101 L8/11025/2 a=rtpmap:102 L8/11025 a=rtpmap:103 L16/22050/2 a=rtpmap:104 L16/22050 a=rtpmap:105 L16/11025/2 a=rtpmap:106 L16/11025 If t= *is* used, there's very rarely an r= (repetitions) in the same sdp, and often an almost, but not quite identical message (+n seconds in the second field of t= will be sent, with a slightly modified identifier (o=) every n seconds, overlapping with another similarly almost-clone message every n+m seconds. In these situations t=0 0 actually would have made sense!) Oh, and e= (email-address) and p= (phone number) are used for the strangest things. I should have saved the haiku... HM. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 11:31:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06098 for ; Wed, 16 Jul 2003 11:31:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coFI-0001r6-Fu for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 11:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFV8HV007132 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 11:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coFI-0001qx-D7 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06078 for ; Wed, 16 Jul 2003 11:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coFH-0000Y6-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 11:31:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19coFB-0000Y3-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 11:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coFB-0001pI-W9; Wed, 16 Jul 2003 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coEN-0001nv-MS for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 11:30:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06059; Wed, 16 Jul 2003 11:30:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coEM-0000Y0-00; Wed, 16 Jul 2003 11:30:10 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19coEB-0000Xw-00; Wed, 16 Jul 2003 11:29:59 -0400 Received: from nmh.informatik.uni-bremen.de (smmsp@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h6GFTThY004746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2003 17:29:29 +0200 (MEST) Received: (from jo@localhost) by nmh.informatik.uni-bremen.de (8.12.9/8.12.8/Submit) id h6GFTP7Y004745; Wed, 16 Jul 2003 17:29:25 +0200 (MEST) From: Joerg Ott Message-Id: <200307161529.h6GFTP7Y004745@nmh.informatik.uni-bremen.de> To: mmusic@ietf.org Date: Wed, 16 Jul 2003 17:29:25 +0200 (MEST) Cc: jo@informatik.uni-bremen.de (Joerg Ott), csp@csperkins.org, agenda@ietf.org X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Updated MMUSIC Agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit An updated revision of the agenda is available at http://www.dmn.tzi.org/ietf/mmusic/57/agenda.html included below as text version. Cheers, Joerg 57th IETF: Draft MMUSIC Agenda ============================== Thursday, 17 July 2003, 0900 - 1130, Hall IK -------------------------------------------- 0900 Agenda Bashing and Status Update (chairs, 10) Recent RFCs - draft-ietf-mmusic-reservation-flows-01.txt -> RFC 3524 With RFC editor - draft-ietf-mmusic-sdp4nat-05.txt - draft-ietf-mmusic-sdpng-trans-04.txt With IESG - draft-ietf-mmusic-sdp-new-13.txt - draft-rajeshkumar-mmusic-gpmd-03.txt With AD - draft-ietf-mmusic-sdp-comedia-05.txt - draft-ietf-mmusic-srcfilter-05.txt WG Last Call - draft-ietf-mmusic-sdp-bwparam-04.txt Misc Updates - draft-camarillo-mmusic-alt-01.txt - draft-ietf-mmusic-kmgmt-ext-07.txt - draft-ietf-mmusic-sdp-implem-00.txt 0910 Revised SDP (Perkins, 10) - draft-ietf-mmusic-sdp-new-13.txt 0930 SDP Security Descriptions for Media Streams (Wing, 10) - draft-ietf-mmusic-sdescriptions-01.txt 0940 SDP Offer Answer Examples (Johnston, 10) - draft-ietf-mmusic-offer-answer-examples-01.txt 0950 SDPng Update (Kutscher, 20) - draft-ietf-mmusic-sdpng-06.txt 1010 RTP DoS Attack (Rosenberg, 10) - draft-rosenberg-mmusic-rtp-denialofservice-00.txt 1020 Interactive Connectivity Establishment (ICE) (Rosenberg, 10) - draft-rosenberg-sipping-ice-01.txt 1030 RTSP Update (Westerlund, 30) - draft-ietf-mmusic-rfc2326bis-04.txt - draft-ietf-mmusic-rtsp-nat-01.txt 1100 Internet Media Guides (Manyfolks, 30) - draft-nomura-mmusic-img-requirements-01.txt - draft-nomura-mmusic-img-framework-01.txt - draft-luoma-mmusic-img-muppet-02.txt - draft-luoma-mmusic-img-metadata-01.txt - draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt 1130 Close Second (formal) meeting still to be scheduled for RTSP ------------------------------------------------------ Tentatively Wednesday night over dinner RTSP spec editing and bug fixing (Westerlund/Lanphier, 120) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 13:50:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10295 for ; Wed, 16 Jul 2003 13:50:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqQ1-0001hc-Aq for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 13:50:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHoLSw006538 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 13:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqQ0-0001hN-Nb for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 13:50:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10281 for ; Wed, 16 Jul 2003 13:50:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqPy-0001dQ-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 13:50:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cqPs-0001dK-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 13:50:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqPi-0001gL-Fq; Wed, 16 Jul 2003 13:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqPN-0001Zf-1K for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 13:49:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10265 for ; Wed, 16 Jul 2003 13:49:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqPK-0001d9-00 for mmusic@ietf.org; Wed, 16 Jul 2003 13:49:38 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19cqP9-0001cZ-00 for mmusic@ietf.org; Wed, 16 Jul 2003 13:49:28 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h6GHmNcs063250; Wed, 16 Jul 2003 10:48:24 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 16 Jul 2003 10:55:32 -0700 (PDT) From: Stephen Casner To: Hanne Moa cc: Colin Perkins , Subject: Re: [MMUSIC] IESG comments on SDPnew In-Reply-To: <20030716165830.B14497@vinland.uninett.no> Message-ID: <20030716105127.K8445-100000@oak.packetdesign.com> 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: , On Wed, 16 Jul 2003, Hanne Moa wrote: > I've been monitoring SAP-packets for over a year now and never seen it. > Ditto for z= (time zone adjustments). > > Furthermore, more than 90% of sdp over sap is unspecified for time, > that is: t=0 0. It is used for just about anything: on-demand, 24/7 > webcams, conferences... It is so vague as to be useless. The IP/TV product, initially from Precept Software then later and still from Cisco, uses both t= and z= but (to my recollection) not k=. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 16:24:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16029 for ; Wed, 16 Jul 2003 16:24:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19csoJ-0003KF-PH for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 16:23:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GKNZIm012777 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 16:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19csoJ-0003K0-KZ for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 16:23:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16020 for ; Wed, 16 Jul 2003 16:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19csnl-0003Cu-6D; Wed, 16 Jul 2003 16:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19csn6-0003CI-Bc for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 16:22:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15948 for ; Wed, 16 Jul 2003 16:22:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19csn4-0002pi-00 for mmusic@ietf.org; Wed, 16 Jul 2003 16:22:18 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19csmo-0002pD-00 for mmusic@ietf.org; Wed, 16 Jul 2003 16:22:02 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.9) with ESMTP id h6GKJ6np087863; Wed, 16 Jul 2003 13:20:21 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.9/Submit) id h6GKJ6vI087862; Wed, 16 Jul 2003 13:19:06 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20030716131507.00b5aaf0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 16 Jul 2003 13:17:22 -0700 To: Mark Baugher From: Ross Finlayson Subject: Re: [MMUSIC] IESG comments on SDPnew Cc: Colin Perkins , mmusic@ietf.org, Russ Housley , oran@cisco.com, mat@cisco.com In-Reply-To: <5.1.1.5.2.20030716072453.0650ec80@mira-sjc5-6.cisco.com> References: <20030716155745.0998862c.csp@csperkins.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: , Because of the known limitations/problems with "k=", plus the fact that we now have a better way of describing keying information (i.e., "ietf-mmusic-sdescriptions"), I think that the "SDPnew" document should just get rid of "k=" (or, at the very least, note that it's deprecated). Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 18:39:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21593 for ; Wed, 16 Jul 2003 18:39:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuvX-00032G-8k for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 18:39:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GMdBmg011664 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 18:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuvX-000323-4P for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 18:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21549 for ; Wed, 16 Jul 2003 18:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cuvU-0004FD-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 18:39:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cuvO-0004FA-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 18:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuvM-0002yv-Rt; Wed, 16 Jul 2003 18:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuuZ-0002y9-9D for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 18:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21528 for ; Wed, 16 Jul 2003 18:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cuuW-0004Ew-00 for mmusic@ietf.org; Wed, 16 Jul 2003 18:38:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cuuL-0004Er-00 for mmusic@ietf.org; Wed, 16 Jul 2003 18:37:57 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6GMbAiB011368; Wed, 16 Jul 2003 18:37:11 -0400 (EDT) Message-ID: <3F15D390.80506@dynamicsoft.com> Date: Wed, 16 Jul 2003 18:37:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTP denial of service References: <3F026A96.5000907@dynamicsoft.com> <3F095C79.7070109@ericsson.com> In-Reply-To: <3F095C79.7070109@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the delay in responding, Magnus. Responses inline. Magnus Westerlund wrote: > Hi Jonathan, > > I have now had time to read your draft. It summaries the problem of the > attack fairly well. However I think one can elaborate a bit more on some > use cases and in relation to NAT traversal. > > First, the problem of destination addresses in combination with NATs > that use multiple addresses. If a NAT would assign different NAT > mappings to different external addresses there is a problem with the > limiting text that RTSP has. This also is present for a single RTP > session where RTP and RTCP will be separate flows. This leads to that > simple limitations can't be used while still NAT traversal or TURN > servers are in use. Yes, I agree. That is a general RTSP issue. > > Secondly the RTCP prevention that you mention in chapter 3 has more > flaws then you describe, but not one of them you describe I would say. OK, well I'm glad we agree even though its for the wrong reasons... > I > don't see a reason to force the sending side to have this stop and go > behaviour you describe. I would more work in the terms of how TFRC > behave, I think. If no RTCP reports are received the sending bit-rate is > throttled back, to almost non existing levels. This will limit the > severity of the attack. However with using many sessions it might still > be possible to achieve enough force amplification. I'm not that familiar with TFRC. How is the initial rate set? That could make a big difference too. > > The flaw you missed in your description of using RTCP as limiting factor > is first that if the attacker directs a RTCP stream to itself and only > the RTP stream to the target, it can simple generate false RTCP reports. Ah - good point. I hadnt thought of that. Normally its not possible, but draft-ietf-mmusic-sdp4nat will allow this. > The senders RTCP reports contains the number of packets sent, which > makes it easy to increase the RTCP receiver reports extended counter. > The initial RTP sequence number are usually transmitted in RTSP's > RTP-Info header. Therefore all necessary information for faking a > perfect reception pattern exist, keeping any congestion control based on > RTCP reports happy. Right. > > Third, the solution space. As you mention an alternative to using STUN > in this requesting mechanism would be to develop a RTP payload format > and RTCP packet type to contain necessary information of granting a > media stream. What may be missing in STUN is the possibility to provide > information about the media stream that the receiver accepts. That information is conveyed in the signaling protocol. Clearly this information is only useful when there is NOT an attack, so the recipient would be privy to the signaling. > > However I don't know if such a solution would be any better. Maybe on > the paper it would have a clearer demultiplexing than between STUN and > RTP. However STUN can be used with any media protocol that can be > differentiated on the first byte, while a RTP/RTCP solution would be > limited to that protocol. Right. > > Fourth, have you looked at what solutions DCCP would provide to this > problem? I think that the session establishment could ensure that the > client accepts the media stream. Yes, I believe it would. However, we have some time to go before that really becomes deployable. > > Fifth, what is the current status of ICE? Can we expect any progress for > ICE within the IETF. We will be discussing this today in mmusic. Yesterday, sipping re-affirmed its desire to move forward with ICE. We agreed that there are really two documents. One is the actual ICE mechanism, which is not sip specific at all. The other is use cases that show how ICE is used with SIP. THe latter will be happening in sipping, as an alternative to the current draft-ietf-sipping-nat-scenarios document. The former, however, appeared to be more of an mmusic issue. So, the sipping group wants mmusic to take ICE as a work item, in fact. > > Sixth, doesn't one need to use STUN with authentication to prevent other > security attacks that based on falsifying STUN responses, even when the > session establisher is not an attacker? Yes, and thats why there is authentication in stun. Mostly the authenticaiton is of the SERVER - the client identity is not that important. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 18:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21825 for ; Wed, 16 Jul 2003 18:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cv3D-0003ba-RO for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 18:47:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GMl7Ut013853 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 18:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cv3D-0003bM-OZ for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 18:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21820 for ; Wed, 16 Jul 2003 18:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cv3A-0004Lo-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 18:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cv35-0004Ll-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 18:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cv37-0003Zn-7p; Wed, 16 Jul 2003 18:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cv2s-0003Za-6q for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 18:46:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21816 for ; Wed, 16 Jul 2003 18:46:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cv2p-0004Lc-00 for mmusic@ietf.org; Wed, 16 Jul 2003 18:46:43 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cv2e-0004LU-00 for mmusic@ietf.org; Wed, 16 Jul 2003 18:46:32 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6GMjniB011374; Wed, 16 Jul 2003 18:45:51 -0400 (EDT) Message-ID: <3F15D597.5050406@dynamicsoft.com> Date: Wed, 16 Jul 2003 18:45:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTP denial of service References: <72263E8E8622D611975C0002B32C19D84A7C56@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D84A7C56@misty.packetvideo.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 Sorry for the delay in responding. Responses inline. Thomas Zeng wrote: > Jonathan: > > Thanks for this timely work. I finally got a chance to review it, along with > the email trail. > > Magnus asked a good question: doesn't STUN (RFC3489) require TLS ? See > section 9.2: > In order to ensure interoperability, this > specification describes a TLS-based mechanism. This mechanism, > described in this section, MUST be implemented by clients and > servers. TLS is not needed in the peer-to-peer usage. Thats because there is an alternate mechanism being used for obtaining the shared secret - namely the signaling protocol, which has its own security mechanisms. The words above are aimed at the case where the client is contacting a public server. There, yes it is needed. > > I suspect that some RTSP thin clients (those embedded in low-power devices) > may not have enough resources (CPU and/or bandwidth) to run TLS... at the > minimal, it adds more work to implementors of RTSP. I would imagine TLS would be there for other reasons. > > > Now, in section 5 of: > http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservi > ce-00.txt > > You seem to imply that RTSP already follows Offer/Answer exchanges? I'd like > to hear more on this subject... No, clearly it doesn't. I'm being loose with my terms here. It follows an offer-answer like exchange in that there are two entities, and both tell each other IP addresses. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 16 23:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29193 for ; Wed, 16 Jul 2003 23:31:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czU6-0000zQ-5t for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 23:31:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H3VAfB003803 for mmusic-archive@odin.ietf.org; Wed, 16 Jul 2003 23:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czU4-0000yh-M4 for mmusic-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 23:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29163 for ; Wed, 16 Jul 2003 23:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19czU2-0006wQ-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 23:31:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19czTx-0006wN-00 for mmusic-web-archive@ietf.org; Wed, 16 Jul 2003 23:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czTx-0000rh-3g; Wed, 16 Jul 2003 23:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czTN-0000qy-2R for mmusic@optimus.ietf.org; Wed, 16 Jul 2003 23:30:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29084 for ; Wed, 16 Jul 2003 23:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19czTL-0006vn-00 for mmusic@ietf.org; Wed, 16 Jul 2003 23:30:23 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19czTA-0006v0-00 for mmusic@ietf.org; Wed, 16 Jul 2003 23:30:12 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 16 Jul 2003 20:17:24 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Wed, 16 Jul 2003 20:17:23 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Wed, 16 Jul 2003 20:27:25 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19czQy-00052V-00 for ; Wed, 16 Jul 2003 20:27:56 -0700 Date: Wed, 16 Jul 2003 20:25:51 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_10,KNOWN_MAILING_LIST,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #84 - 2 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session (SourceForge.net) 2. [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 16 Jul 2003 07:09:52 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session Bugs item #772330, was opened at 2003-07-16 16:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 Category: None Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify that RTCP shall be sent during whole session Initial Comment: Appendix B should be clarified to point out that RTCP is expected to be sent from succesful response of SETUP until TEARDOWN. During PAUSE the server and client should both continue to send RTCP as normal. Motivations to this behavior is: - to avoid timing out SSRC, - ensure detection of packet loss at the end of stream. - ensure that RTCP syncrhonization can work (necessary for multiple SSRC). - Ensure that RTP stream work prior to PLAY if there is some delay between them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 16 Jul 2003 07:12:35 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session Bugs item #772330, was opened at 2003-07-16 16:09 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 Category: None Group: Fix DS - Needs clarificiation Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify that RTCP shall be sent during whole session Initial Comment: Appendix B should be clarified to point out that RTCP is expected to be sent from succesful response of SETUP until TEARDOWN. During PAUSE the server and client should both continue to send RTCP as normal. Motivations to this behavior is: - to avoid timing out SSRC, - ensure detection of packet loss at the end of stream. - ensure that RTCP syncrhonization can work (necessary for multiple SSRC). - Ensure that RTP stream work prior to PLAY if there is some delay between them. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-07-16 16:12 Message: Logged In: YES user_id=302620 At the same time it should be made clear the RTCP BYE is sent when the session is terminated, i.e. at the time of teardown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 17 02:23:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17171 for ; Thu, 17 Jul 2003 02:23:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d29x-0003Dh-HD for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 02:22:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H6MXff012371 for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 02:22:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d29x-0003DO-4v for mmusic-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 02:22:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17116 for ; Thu, 17 Jul 2003 02:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d29R-0002yx-MT; Thu, 17 Jul 2003 02:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d28V-0002w0-TC for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 02:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16995 for ; Thu, 17 Jul 2003 02:20:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d28S-0001Op-00 for mmusic@ietf.org; Thu, 17 Jul 2003 02:21:00 -0400 Received: from [81.160.158.191] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19d28H-0001O2-00 for mmusic@ietf.org; Thu, 17 Jul 2003 02:20:49 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6H6IxZ4000343; Thu, 17 Jul 2003 07:19:06 +0100 (BST) (envelope-from csp@csperkins.org) Date: Thu, 17 Jul 2003 08:18:59 +0200 From: Colin Perkins To: Ross Finlayson Cc: mbaugher@cisco.com, mmusic@ietf.org, housley@vigilsec.com, oran@cisco.com, mat@cisco.com Subject: Re: [MMUSIC] IESG comments on SDPnew Message-Id: <20030717081859.3a51189f.csp@csperkins.org> In-Reply-To: <4.3.1.1.20030716131507.00b5aaf0@laptop-localhost> References: <20030716155745.0998862c.csp@csperkins.org> <4.3.1.1.20030716131507.00b5aaf0@laptop-localhost> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Ross Finlayson writes: > Because of the known limitations/problems with "k=", plus the fact that > we now have a better way of describing keying information (i.e., > "ietf-mmusic-sdescriptions"), I think that the "SDPnew" document should > just get rid of "k=" (or, at the very least, note that it's deprecated). Certainly we should note that it's deprecated. But, we need to determine if there are any implementations before deciding if we can remove "k="... -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 17 04:46:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23553 for ; Thu, 17 Jul 2003 04:46:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4ON-0006CV-O8 for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 04:45:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8jZSq023834 for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 04:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4ON-0006CL-JP for mmusic-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:45:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23499 for ; Thu, 17 Jul 2003 04:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Nq-00065q-9l; Thu, 17 Jul 2003 04:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Nk-00065P-Cb for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 04:44:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23471; Thu, 17 Jul 2003 04:44:51 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4Nh-0003Nb-00; Thu, 17 Jul 2003 04:44:53 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19d4NW-0003K1-00; Thu, 17 Jul 2003 04:44:42 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id F23F4613B9; Thu, 17 Jul 2003 10:42:44 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA16008; Thu, 17 Jul 2003 10:42:44 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA04079; Thu, 17 Jul 2003 10:42:42 +0200 (MEST) To: Colin Perkins Cc: dccp@ietf.org, mmusic@ietf.org, floyd@icir.org, jpanderson@sonusnet.com, "Phelan, Tom" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 17 Jul 2003 10:33:20 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 17/07/2003 10:43:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] stream switching (was: Using DCCP for VoIP) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 wrote: >Do the ideas in draft-gentric-mmusic-stream-switching-req-00.txt help any >here? I confirm the problems you report are the same ones the "stream switching" proposal aims to solve, see below for details. --> "Phelan, Tom" writes: > Hi Sally, > > Thanks for the response. See inline ... > > Tom P. > > [clipped] > > >The DCCP documents talk about VoIP being one of the main > > applications for > > >DCCP. I've been trying to figure out a reasonable way for a VoIP > > >application to use DCCP. Here's what I've come up with so > > far. Corrections > > >and comments would be appreciated. > > > Apart from the fact that my original concern was for "media delivery" i.e. an application where -contrary to VoIP- end to end delay is not critical, the problems are exactly the same for *all* media traffic, be it voice, video, text, etc audio is a very good case for study since it is so critical in terms of *gaps* in the stream. however the case of *multiple* streams (A+V to start with) must be considered (see end of the mail)! [clipped] > > >Now assume the network becomes congested and one (at least) > > of my packets > > >get dropped. DCCP decides it must back off the transmission > > rate, so one of > > >my 'send's fails with EWOULDBLOCK. This is clearly not very rich feedback, a blocking send is so very drastic! I would love to see the DCCP stack give earlier feedback something in the spirit of: "hey, be ready to change your rate because the connection state seems to indicate that the available bandwidth is decreasing" and then something like: "hey, the available bandwidth has reduced to xxx kb/s, change your rate ASAP" and in case of "emmergencies" (which definition would actually depend on the congestion control that has been chosen) if the DCCP stack has the impression that the available rate is extremely rapidly decreasing it would send: "hey reduce your rate to yyy kb/s NOW" and for increases: "hey, you can increase your rate up to zzz kb/s" (the codec can take its time then, there is never any emmergency) [clipped] > > We would also like to understand better how DCCP would or would not > > work for a VoIP flow that did not have an adaptive codec, but we > > have not worked this through. (E.g., under congestion, some fraction > > of the packets from the codec would be dropped by the DCCP sender.) > > > > >If the codec family can support this change on the fly, > > that's great. But > > >if it requires renegotiation, I'll need to wait for that. > > If I renegotiate > > >in band, then my change request packet will get queued until > > DCCP decides it > > >can transmit again. If I renegotiate out of band, then that > > channel might > > >be having it's problems too. At any rate, there will be a > > round-trip delay > > >or so before I can start sending packets again. > > stream switching is *exactly* about solving this: how to change the rate by switching *codecs* (and/or codec config since a lot of recent codec have wide ranges of parameters/profiles/rates etc) deployed (streaming) products show that it is not only possible, it works fine. the assumption is that the negociation takes time, also the instanciation of the ressources -especially on thin client- also takes time so it *must* take place "before". This before could be at session start, but it could also be at anytime during the session, but then not on short notice, (especially not with a blocking write!?-) So -again- it is very important that the DCCP stack gives early feedback so as to have time to "setup" (RTSP-wise) the required codecs. > > If negotiation is required, this is about the codec, not about DCCP, > > right? > > Right. This was meant to indicate that the app probably can't > immediately change its sending rate. > if the app "cannot change its rate" DCCP will be a very little use *anyway* no? I think you must assume that either the codec rate can be changed (true for most video codecs and a lot of recent audio codecs) and if the change of rate goes beyond the flexibility of a given codec you must change the codec and/or its configuration. [In the stream switching drafts the former is described as "transparent" and the latter as "non transparent"] Note that for coding efficiency reasons it is a *very bad idea* to try to drive a video codec with rapid instantaneous changes of rate. anyway the key issue is that DCCP *and* the codec(s) must have a way to talk, be configured etc ... work together hand in hand > > It's also not clear why you need to stay quiet until the codec change > > request is acknowledged. DCCP has reduced its allowable send > > rate, but not > > to zero. the codecs need to know the exact target rate, DCCP must give this as output (the rate of that feedback could be configurable ?) the "contract" between the codecs and the DCCP stack is very simple: the chosen configuration MUST have a rate smaller (or equal) to the target. > That is probably true, but I'm not sure how the other end would react to > receiving old-codec packets while the new codec is half-negotiated. It cannot (see above). Another problem is the ability to distinguish between the packet containing data of one codec or the other since for most decoder feeding the wrong type of syntax can be very bad (can even lead to crashes etc) This issue is addressed in the stream switching proposal: typically with RTP the "old codec" uses one (dymamically attributed) PT and the new one uses another one. There was the possibility to use another "port", but with DCCP this would be stupid no? this leads me to the following question: Can we assume that a given DCCP *connection* will be used to transport each media e.g. "audio" (i.e. eventually with codec changes on the fly, indicated by changes in PT of RTP packets)? Then for audio+video there will be 2 DCCP connections right? How is the DCCP feedback going to work then? Indeed in stream swithing I always assumed that the target is the *pair* A+V i.e. the target rate can be obtained using SEVERAL combination, examples: 5 kb/s AMR audio + 245 kb/s video = 250 kb/s, basic audio 40 kb/s AAC audio + 210 kb/s video = 250 kb/s, better audio 80 kb/s AAC stereo + 170 kb/s video = 250 kb/s, good audio ****************** regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 17 04:53:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24031 for ; Thu, 17 Jul 2003 04:53:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4W4-0007Cg-OF for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 04:53:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8rW6c027685 for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 04:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4W4-0007CS-LO for mmusic-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:53:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24008 for ; Thu, 17 Jul 2003 04:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4VZ-00075z-E0; Thu, 17 Jul 2003 04:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Uu-00073X-R6 for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 04:52:20 -0400 Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23889; Thu, 17 Jul 2003 04:52:15 -0400 (EDT) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id CFA545B40D; Thu, 17 Jul 2003 10:47:12 +0200 (MET DST) Received: from smtprelay-nl2.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 KAA06595; Thu, 17 Jul 2003 10:47:11 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA06525; Thu, 17 Jul 2003 10:47:10 +0200 (MEST) To: "Phelan, Tom" Cc: dccp@ietf.org, mmusic@ietf.org, "'Reiner Ludwig'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 17 Jul 2003 10:37:47 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 17/07/2003 10:48:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RE: [dccp] Using DCCP for VoIP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, IMHO this issue is related to my question in the other mail about managing audio AND video at the same time: probably DCCP should have a way to handle "collectively" a bunch of streams, be it audio plus video or two-way audio! regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: "'Reiner Ludwig'" dccp@ietf.org cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: RE: [dccp] Using DCCP for VoIP "Phelan, Tom" Classification: Sent by: dccp-admin@ietf.org 17/07/2003 09:17 Hi Reiner, I guess I missed this when you sent it on tsvwg, thanks for resending. To me it seems to say that the thought of using TRFC for two-way telephony is fundamentally broken, so DCCP isn't usable for that until there's a new CCID. Tom P. > -----Original Message----- > From: Reiner Ludwig [mailto:Reiner.Ludwig@ericsson.com] > Sent: Wednesday, July 16, 2003 3:06 AM > To: dccp@ietf.org > Subject: RE: [dccp] Using DCCP for VoIP > > > I'm forwarding this mail since I believe it relates to the currrent > discussion about DCCP for VoIP. I had sent this mail to the > tsvwg mailing > list a few weeks ago ... > > ///einer > > > >X-Sender: eedrel@mailhost.eed.ericsson.se > >X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 > >Date: Fri, 04 Apr 2003 10:52:58 +0200 > >To: tsvwg@ietf.org > >From: Reiner Ludwig > >Subject: Re: [Tsvwg] redundant data - A TFRC Example > >Sender: tsvwg-admin@ietf.org > >X-BeenThere: tsvwg@ietf.org > >X-Mailman-Version: 2.0.12 > >List-Unsubscribe: , > > > >List-Id: Transport Area Working Group > >List-Post: > >List-Help: > >List-Subscribe: , > > > > > >I'd like to add an example for people to think about ... > > > >If you try to run VoIP over TFRC, you'll most likely be > disappointed by > >the quality. The reason is that when A talks, then (usually) > B is silent, > >and vice versa. I.e., a talkspurt A>B is followed by a > talkspurt B>A is > >followed by a talkspurt A>B, .... > > > >While B is silent and if the talkspurt from A is long enough > then B's TFRC > >send rate will decay to zero (or at least often enough below > the required > >coder rate). Andrei Gurtov did this experiment and told me > how 'broken' > >such a voice conversation becomes. > > > >The "easy fix" is for B to send dummy data (or even > potentially useful > >data like pictures, ads, calendar sync data, etc.) for the > sole purpose of > >maintain the TFRC rate above the required coder rate. B > would be a good > >Internet citizen in the sense that it is always TCP > friendly. Still, B is > >sending data it does't have to send necessarily. > > > >Should the IETF set up rules that would limit the sending of such > >potentially useless data? Do we have hope that such rules > would be obeyed > >by application and protocol designers? > > > >I could imagine VoIP application designers that would let > themselves be > >convinced to move away from uncontrolled UDP to RTP/DCCP, > but probably not > >much further. I.e., their view could be: "We ensure that our > flows behave > >TCP friendly, but what we do with the available bandwidth is > our business." > > > >I'm not saying that I agree to that, but I would understand > that view. > > > >///Reiner > > > >_______________________________________________ > >tsvwg mailing list > >tsvwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/tsvwg > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 17 14:02:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15636 for ; Thu, 17 Jul 2003 14:02:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD4Q-0007w7-VZ for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 14:01:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HI1Ys1030503 for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 14:01:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD4Q-0007vu-SO for mmusic-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:01:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15613 for ; Thu, 17 Jul 2003 14:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD3s-0007tu-Mh; Thu, 17 Jul 2003 14:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD3K-0007sn-QZ for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 14:00:26 -0400 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15460 for ; Thu, 17 Jul 2003 14:00:21 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6HHxRIi024758 for ; Thu, 17 Jul 2003 19:59:27 +0200 (MEST) Received: from ericsson.com (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366CMJHW; Thu, 17 Jul 2003 19:59:41 +0200 Message-ID: <3F16E3FB.1010804@ericsson.com> Date: Thu, 17 Jul 2003 19:59:23 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Summary of Wednesday's RTSP discussion Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, This is a summary of the discussion during wednesday's RTSP dinner (2003-07-16, 17.30 - 19.30). Participants: Magnus Westerlund, Anders Klemets, David Singer, Geetha S, Aravind N, Henning Schulzrinne, Thomas Zeng, Philippe Gentric, Patrik ?, Joerg Ott, Colin Perkins, Tom Marshall + 2 (sorry I can't remember your names). Issue: Missing session level control URI in SDP. IF the session control URI is missing, should we allow the client to try to to aggregate these? If aggregated which session control URI must be used. Discussion: This needs to be resolved. Tom Marshall did not thought that we should prevent the use case to aggregate unless necessary for interoperability. One possible resolution is to say that any media description missing session level control URI must be setup with individual RTSP session for each media stream and any synchronization between media be done on the receiver side. A practical resolution resolution could be: A client SHOULD follow the above statement but MAY try to aggregate. The server MAY allow this aggregation but MAY also refuse it using 4xx (Only non aggregated operation allowed). Resolution?: Session declarations lacking a session level control URL, MUST be used in non-aggregated control. Further discussion needed? Issue: Need to clarify that how a=range can be interpreted to indicate Live signalling. Discussion: The basic idea was that any a=range time format that are open ended, e.g. npt=0- or npt=now-, should be interpreted as a live media. However Live media is not well defined and may not be sharing the same properties for all use cases. For example a proxy could actually work as one of these TiVo boxes and record media during PAUSED live streams. The media stream would be unbound but not share the properties for a live only stream as it will be seekable in the already played parts. Need for a attribute specifying stream properties seem useful. Possible attributes are: Non-seekable, seekable backwards in time, muted. Resolution: A open ended range format shall be interpreted as an infinite or unbound session. Further properties needs to define a separate (common) attribute to declare these things. Issue: Possible methods for signalling end of stream/media (not session) in RTP. Discussion: Need to signal that a stream/media has ended exist mostly in unbound sessions. Proposal brought up to indicate this is RTCP BYE when the sender stops sending and has waited some time it can remove the SSRC of that source and send the BYE to indicate this. Another proposal was to send this information in RTSP methods. One could use sever to client TEARDOWN to indicate this session really are over, nothing more can be done. PAUSE can be sent when the media has been served but the client may rewind do other operations. The TEARDOWN idea was not liked as certain applications require session data to be sent from client to server using SET_PARAMETER. A new method should be evaluated. There might also exist significant synchronization problems in this. Resolution: Propose a RTSP extension with a new method. Thomas Zeng to write strawman proposal for evaluation to mailing list. Issue: Should REDIRECT automatically close session. Discussion: This does not concern 3rr responses. As a connection related REDIRECT will terminate the session on the server side it is reasonable the same thing happens for REDIRECT request directed at the session. The exception to this is timed REDIRECTS that will continue exist until the specified time. The client should do TEARDOWN prior to this point to move the session to the alternative session. Resolution: Clarify that session will be terminated by a successful REDIRECT, independently of its connection or session. Issue: How to handle implicit redirection through session description protocol. Discussion: Seems to be desired functionality to have an optimized way for saving a RTT when you perform load balance. There where also the issue that if a server would give a content-base or other base URL. A client should not reconnect unless explicitly redirected. This may result in different behaviour depending if the client are behind a proxy or not. First it was proposed that a new 200 code can be used to indicate that you get the SDP but are redirected. However this seem to have backwards problem. To optimize this in a efficient way you can use a new 350 code to indicate redirection but the client does receive a SDP. This way a old client will do the redirect as it interprets is as 3xx code, while a new client can avoid wasting a extra describe. There are also a need to clarify that a server should not change the host address of the control in regards to the describe URI. Resolution: Create a 350 code for this plus clarify the SHOULD NOT change the host address. Seems reasonable to put into the core specification. Issue: Request to Response time-out. The time a request takes until any response is received is not bound. Look at SIP solution? Discussion: The time for a request to be processed is not defined. IF a server is taking long time to process a request it could send a 1xx response to indicate what it is doing. There may be soon need for this, especially if one uses STUN to validate connectivity. Concerns to backwards compatibility that a client will not expect a 1xx response even if this has been defined in RFC 2326. A couple to 10 seconds seem to be a reasonable time for a time-out. Does not seem appropriate to use without a feature tag. However a clarification on the issue is probably not a bad thing. There where also some concerns about the CSeq. Resolution: Not resolved, Aravind to write to the list. Issue: How to detect the updated spec? Version number change 1.1 or 2.0, or only use require and tag when necessary. Discussion: Should be further discussed with through analysis of the so far made changes and see if they are backwards compatible. The initial goal has been to not be other than backwards compatible. A version number of 2.0 does completely change the picture for RTSP. Resolution: Try to write up the change list properly with backwards analysis. End of issues. Reporting Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 17 14:03:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15764 for ; Thu, 17 Jul 2003 14:03:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD6K-000843-7H for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 14:03:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HI3WWc030993 for mmusic-archive@odin.ietf.org; Thu, 17 Jul 2003 14:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD6K-00083o-35 for mmusic-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:03:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15745 for ; Thu, 17 Jul 2003 14:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD5p-00081z-57; Thu, 17 Jul 2003 14:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD5K-0007yN-6U for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 14:02:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15673 for ; Thu, 17 Jul 2003 14:02:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dD5H-0000KB-00 for mmusic@ietf.org; Thu, 17 Jul 2003 14:02:27 -0400 Received: from [81.160.158.191] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19dD56-0000Jb-00 for mmusic@ietf.org; Thu, 17 Jul 2003 14:02:16 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6HI1IZ4007474; Thu, 17 Jul 2003 19:01:19 +0100 (BST) (envelope-from csp@csperkins.org) Date: Thu, 17 Jul 2003 20:01:18 +0200 From: Colin Perkins To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de Message-Id: <20030717200118.53ac3346.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG Last call: draft-ietf-mmusic-sdp-bwparam-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As announced in the MMUSIC session this morning, the SDP bandwidth parameters draft is now in working group last call. Please send any final comments on this draft to the mailing list by 28th July. 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. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 18 09:39:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29954 for ; Fri, 18 Jul 2003 09:39:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dVS7-0006sl-J8 for mmusic-archive@odin.ietf.org; Fri, 18 Jul 2003 09:39:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IDdFLs026451 for mmusic-archive@odin.ietf.org; Fri, 18 Jul 2003 09:39:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dVS7-0006sY-G6 for mmusic-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 09:39:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29925 for ; Fri, 18 Jul 2003 09:39:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dVS4-00012v-00 for mmusic-web-archive@ietf.org; Fri, 18 Jul 2003 09:39:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dVRy-00012l-00 for mmusic-web-archive@ietf.org; Fri, 18 Jul 2003 09:39:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dVRt-0006po-L8; Fri, 18 Jul 2003 09:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dVQz-0006lo-6g for mmusic@optimus.ietf.org; Fri, 18 Jul 2003 09:38:05 -0400 Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29895; Fri, 18 Jul 2003 09:38:00 -0400 (EDT) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id B68AD5AC83; Fri, 18 Jul 2003 15:33:00 +0200 (MET DST) Received: from smtprelay-nl2.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 PAA20011; Fri, 18 Jul 2003 15:32:59 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA00859; Fri, 18 Jul 2003 15:32:58 +0200 (MEST) To: Damon Lanphear Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 18 Jul 2003 15:23:32 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/07/2003 15:34:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] blocking API (was: stream switching (was: Using DCCP for VoIP)) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Damon Lanphear wrote: >Philippe, > >Can you explain the assumptions that inform your assertion that a >blocked write attempt is "drastic" for an A/V application? I understand >how this may be the case for VoIP. But for streaming A/V I have very >sincere doubts. > Let me explain, then. My assumption is that the most efficient existing media encoders are all carefully optimized to operate at maximum efficiency for a "known in advance" target rate. In all cases best coding efficiency is achieved through the maintenance of a relatively long context (several seconds typical). Rate control -especially in video- is obtained thanks to computations taking into account as many frames as possible so as to distribute the available bandwidth on many frames etc... Specifically I am expressing the concern that driving a modern codec "by the frame" i.e. by giving a number of bits for each frame without taking any account of analysis of the media content is "drastically" sub-optimal. Preventing -without warning- an encoder from writing out an encoded frame for an -a priori undetermined- amount of time looks even worse to me in the sense that I dont know how to drive *efficiently* a media encoder of recent technology in a context where such a desesperate thing can occur. (I say recent but was this not by the way the whole idea of using UDP for RTP instead of TCP?) I would propose that the idea would rather be that DCCP should provide *the application* (which in the case of stream switching, encapsulates several codecs) a target rate. In all cases optimal results will be obtained if rate changes are signaled *as soon in advance* as possible. And the question is: why would we not do it since DCCP can provide such rate information very easily anyway? (TFRC does that very nicely) > >I am guessing that the difference between explicitly stating the rate to >the application and socket blocking is that DCCP is providing reaction >time to the application for whatever adaptation the app may need to do >to fulfill DCCPs transmission requirements. > Exactly ! >I submit that an application can achieve the same ends with socket >blocking semantics. That you *can* do some sort of regulation, I agree, that it is optimal in all cases I have to disagree. [clipped] >I also assume that if a codec requires lead time for rate switching, >negotiation, etc., then its the wrong codec for this type of >application. Such a codec is possibly the wrong codec for telephony or conferencing but I would be totally frustrated to see DCCP limited to this type of applications! BTW how are we going to convince the industry to deploy a full new bona fide *IP protocol* for *streaming media* if it does not leverage the best out of *media codecs* ? >At the very least, the codec should not require setting up >a new decoder in response to a dynamic switch. Then you will be limited by the rate range: there is simply no standard codec of any type (speech, music, video) that covers the full possible range in all cases... Let us reverse the argument: if the bandwidth variation requires a different codec one could be (I am) ready to pay that price. >Inter-key frame time for >video should be the longest time lag over which a switch should have to >take place. Allow me to translate this as: "the minimum forewarning time for a video codec is an Intra frame period" and then we agree!-) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 18 14:19:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07296 for ; Fri, 18 Jul 2003 14:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZoS-0008JC-RG for mmusic-archive@odin.ietf.org; Fri, 18 Jul 2003 14:18:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IIIaWj031934 for mmusic-archive@odin.ietf.org; Fri, 18 Jul 2003 14:18:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZoR-0008Iu-A3 for mmusic-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 14:18:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07270 for ; Fri, 18 Jul 2003 14:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZnt-0008EL-1C; Fri, 18 Jul 2003 14:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZmz-0008C6-JT for mmusic@optimus.ietf.org; Fri, 18 Jul 2003 14:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07221; Fri, 18 Jul 2003 14:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dZmw-0002RL-00; Fri, 18 Jul 2003 14:17:02 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19dZmm-0002Qz-00; Fri, 18 Jul 2003 14:16:52 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Fri, 18 Jul 2003 11:16:02 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: dccp@ietf.org, mmusic@ietf.org In-Reply-To: References: Message-Id: <1058552001.20495.692.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 18 Jul 2003 11:13:22 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] blocking API (was: stream switching (was: Using DCCP for VoIP)) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 relevance of this discussion to DCCP is such that there is an expressed need for immediate/advanced notification of DCCP rate changes to the application through the DCCP API. There is also an expressed need for an DCCP API that supports conventional socket blocking semantics. Both of these requirements, and their rationale should be placed in the DCCP User Guide for future reference. We can further discuss stream switching issues on the mmusic list. On Fri, 2003-07-18 at 06:23, philippe.gentric@philips.com wrote: > Damon Lanphear wrote: > > >Philippe, > > > >Can you explain the assumptions that inform your assertion that a > >blocked write attempt is "drastic" for an A/V application? I understand > >how this may be the case for VoIP. But for streaming A/V I have very > >sincere doubts. > > > > Let me explain, then. > > My assumption is that the most efficient existing media encoders > are all carefully optimized to operate at maximum efficiency for a > "known in advance" target rate. In all cases best coding > efficiency is achieved through the maintenance of a relatively > long context (several seconds typical). Rate control -especially > in video- is obtained thanks to computations taking into account > as many frames as possible so as to distribute the available > bandwidth on many frames etc... > > Specifically I am expressing the concern that driving a modern > codec "by the frame" i.e. by giving a number of bits for each > frame without taking any account of analysis of the media content > is "drastically" sub-optimal. > > Preventing -without warning- an encoder from writing out an > encoded frame for an -a priori undetermined- amount of time looks > even worse to me in the sense that I dont know how to drive > *efficiently* a media encoder of recent technology in a context > where such a desesperate thing can occur. (I say recent but was > this not by the way the whole idea of using UDP for RTP instead of > TCP?) > > I would propose that the idea would rather be that DCCP should > provide *the application* (which in the case of stream switching, > encapsulates several codecs) a target rate. > > In all cases optimal results will be obtained if rate changes are > signaled *as soon in advance* as possible. > > And the question is: why would we not do it since DCCP can provide > such rate information very easily anyway? (TFRC does that very nicely) > > > > >I am guessing that the difference between explicitly stating the rate to > >the application and socket blocking is that DCCP is providing reaction > >time to the application for whatever adaptation the app may need to do > >to fulfill DCCPs transmission requirements. > > > > Exactly ! > > >I submit that an application can achieve the same ends with socket > >blocking semantics. > > That you *can* do some sort of regulation, I agree, that it is > optimal in all cases I have to disagree. > > [clipped] > > >I also assume that if a codec requires lead time for rate switching, > >negotiation, etc., then its the wrong codec for this type of > >application. > > Such a codec is possibly the wrong codec for telephony or > conferencing but I would be totally frustrated to see DCCP limited > to this type of applications! > > BTW how are we going to convince the industry to deploy a full > new bona fide *IP protocol* for *streaming media* if it does not > leverage the best out of *media codecs* ? > > >At the very least, the codec should not require setting up > >a new decoder in response to a dynamic switch. > > Then you will be limited by the rate range: there is simply no > standard codec of any type (speech, music, video) that covers the > full possible range in all cases... > > Let us reverse the argument: if the bandwidth variation requires a > different codec one could be (I am) ready to pay that price. > > >Inter-key frame time for > >video should be the longest time lag over which a switch should have to > >take place. > > Allow me to translate this as: > > "the minimum forewarning time for a video codec is an Intra frame > period" > > and then we agree!-) > > > > regards, > > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jul 19 02:33:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06961 for ; Sat, 19 Jul 2003 02:33:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dlHK-00053K-Ha for mmusic-archive@odin.ietf.org; Sat, 19 Jul 2003 02:33:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6J6XAD8019423 for mmusic-archive@odin.ietf.org; Sat, 19 Jul 2003 02:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dlHK-00053C-4Q for mmusic-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 02:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06938 for ; Sat, 19 Jul 2003 02:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dlHG-00078x-00 for mmusic-web-archive@ietf.org; Sat, 19 Jul 2003 02:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dlHA-00078u-00 for mmusic-web-archive@ietf.org; Sat, 19 Jul 2003 02:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dlHB-00052f-AS; Sat, 19 Jul 2003 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dlGf-000522-2V for mmusic@optimus.ietf.org; Sat, 19 Jul 2003 02:32:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06922 for ; Sat, 19 Jul 2003 02:32:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dlGb-00078n-00 for mmusic@ietf.org; Sat, 19 Jul 2003 02:32:25 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19dlGL-00078W-00 for mmusic@ietf.org; Sat, 19 Jul 2003 02:32:09 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.9) with ESMTP id h6J6UT7d066511 for ; Fri, 18 Jul 2003 23:31:44 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.9/Submit) id h6J6UTDe066503; Fri, 18 Jul 2003 23:30:29 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20030718231407.00baf310@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 18 Jul 2003 23:25:44 -0700 To: mmusic@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] SDPnew: Why not allow "s=" at the media-level? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , According to the SDP specification (currently: ) "i=" is allowed at both the session level and the media level. At the session level, it is called "session information"; at the media level, it is called "media title". On the other hand, "s=" - which is called "session name" - is allowed at only the session level. This seems inconsistent to me. Why not also allow "s=" to appear at the media level? And also, could we use more consistent names for these - e.g., At the session level: - call "s=" the "session name" (no change) - call "i=" the "session information" (no change) At the media level: - call "s=" the "media name" or "media title" - call "i=" the "media information". I.e., the intention here is that, at each level, "i=" - if present - would contain more detailed information than "s=". Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jul 19 11:19:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16597 for ; Sat, 19 Jul 2003 11:19:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtUS-0002BG-6i for mmusic-archive@odin.ietf.org; Sat, 19 Jul 2003 11:19:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JFJGf7008378 for mmusic-archive@odin.ietf.org; Sat, 19 Jul 2003 11:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtUS-0002B3-2k for mmusic-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 11:19:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16579 for ; Sat, 19 Jul 2003 11:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dtUR-0002kQ-00 for mmusic-web-archive@ietf.org; Sat, 19 Jul 2003 11:19:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dtUL-0002kJ-00 for mmusic-web-archive@ietf.org; Sat, 19 Jul 2003 11:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtUD-0002AP-NJ; Sat, 19 Jul 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtTT-00028G-MQ for mmusic@optimus.ietf.org; Sat, 19 Jul 2003 11:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16561 for ; Sat, 19 Jul 2003 11:18:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dtTS-0002k5-00 for mmusic@ietf.org; Sat, 19 Jul 2003 11:18:14 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19dtTI-0002jy-00 for mmusic@ietf.org; Sat, 19 Jul 2003 11:18:04 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn4-417.cisco.com [10.21.81.161]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6JFHBpq000833; Sat, 19 Jul 2003 08:17:12 -0700 (PDT) Message-Id: <5.1.1.5.2.20030719081607.04fda048@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 19 Jul 2003 08:17:10 -0700 To: Ross Finlayson From: Mark Baugher Subject: Re: [MMUSIC] SDPnew: Why not allow "s=" at the media-level? Cc: mmusic@ietf.org In-Reply-To: <4.3.1.1.20030718231407.00baf310@laptop-localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Ross I don't understand the requirement for a "media name" or "media title." What is the need that you are addressing? Mark At 11:25 PM 7/18/2003 -0700, Ross Finlayson wrote: >According to the SDP specification (currently: >) "i=" is allowed at both the session >level and the media level. At the session level, it is called "session >information"; at the media level, it is called "media title". > >On the other hand, "s=" - which is called "session name" - is allowed at >only the session level. > >This seems inconsistent to me. Why not also allow "s=" to appear at the >media level? And also, could we use more consistent names for these - e.g., > >At the session level: > - call "s=" the "session name" (no change) > - call "i=" the "session information" (no change) >At the media level: > - call "s=" the "media name" or "media title" > - call "i=" the "media information". > >I.e., the intention here is that, at each level, "i=" - if present - would >contain more detailed information than "s=". > > Ross. > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Jul 19 12:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17927 for ; Sat, 19 Jul 2003 12:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dv0C-0004y6-Ml for mmusic-archive@odin.ietf.org; Sat, 19 Jul 2003 12:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JGu88v019092 for mmusic-archive@odin.ietf.org; Sat, 19 Jul 2003 12:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dv0C-0004xr-Ir for mmusic-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 12:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17921 for ; Sat, 19 Jul 2003 12:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dv0A-00037a-00 for mmusic-web-archive@ietf.org; Sat, 19 Jul 2003 12:56:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dv05-00037X-00 for mmusic-web-archive@ietf.org; Sat, 19 Jul 2003 12:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dv04-0004xP-VN; Sat, 19 Jul 2003 12:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duza-0004x4-NW for mmusic@optimus.ietf.org; Sat, 19 Jul 2003 12:55:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17915 for ; Sat, 19 Jul 2003 12:55:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duzZ-00037N-00 for mmusic@ietf.org; Sat, 19 Jul 2003 12:55:29 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19duzJ-000378-00 for mmusic@ietf.org; Sat, 19 Jul 2003 12:55:13 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.9) with ESMTP id h6JGrK7d070997; Sat, 19 Jul 2003 09:54:35 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.9/Submit) id h6JGrKuh070992; Sat, 19 Jul 2003 09:53:20 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20030719094843.00b1b350@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 19 Jul 2003 09:53:18 -0700 To: Mark Baugher From: Ross Finlayson Subject: Re: [MMUSIC] SDPnew: Why not allow "s=" at the media-level? Cc: mmusic@ietf.org In-Reply-To: <5.1.1.5.2.20030719081607.04fda048@mira-sjc5-6.cisco.com> References: <4.3.1.1.20030718231407.00baf310@laptop-localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 08:17 AM 7/19/03, Mark Baugher wrote: >Ross > I don't understand the requirement for a "media name" or "media > title." What is the need that you are addressing? Mark, Note that "media title" is *already* specified in SDP (as a media-level "i="). Quoting from the existing specification: "A single "i=" field can also be used for each media definition. In media definitions, "i=" fields are primarily intended for labeling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions." All I'm proposing is that "s=" also be allowed at the media level, and that *this* be called "media title" (with "i=" at the media level called something else, e.g., "media information"). Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 21 05:03:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21441 for ; Mon, 21 Jul 2003 05:03:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWZj-00052G-7V for mmusic-archive@odin.ietf.org; Mon, 21 Jul 2003 05:03:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L93JWh019355 for mmusic-archive@odin.ietf.org; Mon, 21 Jul 2003 05:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWZj-000526-4H for mmusic-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 05:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21431 for ; Mon, 21 Jul 2003 05:03:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWZb-00016W-00 for mmusic-web-archive@ietf.org; Mon, 21 Jul 2003 05:03:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eWZV-00016O-00 for mmusic-web-archive@ietf.org; Mon, 21 Jul 2003 05:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWZR-00050A-Cv; Mon, 21 Jul 2003 05:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWZ4-0004zb-Un for mmusic@optimus.ietf.org; Mon, 21 Jul 2003 05:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21416 for ; Mon, 21 Jul 2003 05:02:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWZ1-00016A-00 for mmusic@ietf.org; Mon, 21 Jul 2003 05:02:35 -0400 Received: from [62.146.145.71] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19eWYq-00015z-00 for mmusic@ietf.org; Mon, 21 Jul 2003 05:02:25 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6L927Ll023326; Mon, 21 Jul 2003 10:02:09 +0100 (BST) (envelope-from csp@csperkins.org) Date: Mon, 21 Jul 2003 11:02:07 +0200 From: Colin Perkins To: Ross Finlayson Cc: mbaugher@cisco.com, mmusic@ietf.org Subject: Re: [MMUSIC] SDPnew: Why not allow "s=" at the media-level? Message-Id: <20030721110207.25d38f68.csp@csperkins.org> In-Reply-To: <4.3.1.1.20030719094843.00b1b350@laptop-localhost> References: <4.3.1.1.20030718231407.00baf310@laptop-localhost> <4.3.1.1.20030719094843.00b1b350@laptop-localhost> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ross, The aim of SDPnew is to be backwards compatible where possible, so I'm reluctant to do this unless there is a strong need. Colin --> Ross Finlayson writes: > At 08:17 AM 7/19/03, Mark Baugher wrote: > >Ross > > I don't understand the requirement for a "media name" or "media > > title." What is the need that you are addressing? > > Mark, > > Note that "media title" is *already* specified in SDP (as a media-level > "i="). Quoting from the existing specification: > > "A single "i=" field can also be used for each media definition. > In media definitions, "i=" fields are primarily intended for > labeling media streams. As such, they are most likely to be > useful when a single session has more than one distinct media > stream of the same media type. An example would be two different > whiteboards, one for slides and one for feedback and questions." > > All I'm proposing is that "s=" also be allowed at the media level, and > that *this* be called "media title" (with "i=" at the media level called > something else, e.g., "media information"). > > Ross. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 21 11:53:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01519 for ; Mon, 21 Jul 2003 11:53:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecyM-0001zn-9S for mmusic-archive@odin.ietf.org; Mon, 21 Jul 2003 11:53:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LFrAQi007634 for mmusic-archive@odin.ietf.org; Mon, 21 Jul 2003 11:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecyM-0001yH-4B for mmusic-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 11:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01488 for ; Mon, 21 Jul 2003 11:53:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecyK-000418-00 for mmusic-web-archive@ietf.org; Mon, 21 Jul 2003 11:53:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ecyE-000412-00 for mmusic-web-archive@ietf.org; Mon, 21 Jul 2003 11:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecyD-0001xm-6k; Mon, 21 Jul 2003 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecxh-0001xD-Fh for mmusic@optimus.ietf.org; Mon, 21 Jul 2003 11:52:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01384 for ; Mon, 21 Jul 2003 11:52:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecxg-0003zz-00 for mmusic@ietf.org; Mon, 21 Jul 2003 11:52:28 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ecxV-0003z4-00 for mmusic@ietf.org; Mon, 21 Jul 2003 11:52:17 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2003 08:57:16 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn3-22.cisco.com [10.21.64.22]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6LFpEuH017753; Mon, 21 Jul 2003 08:51:15 -0700 (PDT) Message-Id: <5.1.1.5.2.20030721084727.04fd9390@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 21 Jul 2003 08:51:13 -0700 To: Ross Finlayson From: Mark Baugher Subject: Re: [MMUSIC] SDPnew: Why not allow "s=" at the media-level? Cc: mmusic@ietf.org In-Reply-To: <4.3.1.1.20030719094843.00b1b350@laptop-localhost> References: <5.1.1.5.2.20030719081607.04fda048@mira-sjc5-6.cisco.com> <4.3.1.1.20030718231407.00baf310@laptop-localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Ross I don't see what is gained by doing this renaming. We would lose some interoperability. It would be worse, I suppose, if we then re-purposed the i=. Mark At 09:53 AM 7/19/2003 -0700, Ross Finlayson wrote: >At 08:17 AM 7/19/03, Mark Baugher wrote: >>Ross >> I don't understand the requirement for a "media name" or "media >> title." What is the need that you are addressing? > >Mark, > >Note that "media title" is *already* specified in SDP (as a media-level >"i="). Quoting from the existing specification: > > "A single "i=" field can also be used for each media definition. > In media definitions, "i=" fields are primarily intended for > labeling media streams. As such, they are most likely to be > useful when a single session has more than one distinct media > stream of the same media type. An example would be two different > whiteboards, one for slides and one for feedback and questions." > >All I'm proposing is that "s=" also be allowed at the media level, and >that *this* be called "media title" (with "i=" at the media level called >something else, e.g., "media information"). > > Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 02:36:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03336 for ; Tue, 22 Jul 2003 02:36:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eqks-0007sh-4d for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 02:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M6aAtY030293 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 02:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eqkr-0007sW-Mr for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 02:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03330 for ; Tue, 22 Jul 2003 02:36:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eqkn-0001u2-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 02:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eqki-0001tz-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 02:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eqkj-0007rl-O1; Tue, 22 Jul 2003 02:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eqk8-0007r5-Ab for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 02:35:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03324 for ; Tue, 22 Jul 2003 02:35:20 -0400 (EDT) From: hoerdt@clarinet.u-strasbg.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eqk4-0001tu-00 for mmusic@ietf.org; Tue, 22 Jul 2003 02:35:20 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19eqjt-0001th-00 for mmusic@ietf.org; Tue, 22 Jul 2003 02:35:09 -0400 Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6M6YSnY026969; Tue, 22 Jul 2003 08:34:28 +0200 Date: Tue, 22 Jul 2003 08:39:28 +0200 (CEST) To: Beau Williamson cc: Leonard Giuliano , David Meyer , John Meylor , Brian Haberman , mboned@network-services.uoregon.edu, fenner@research.att.com, mjh@icir.org, randy@psg.com, mmusic@ietf.org In-Reply-To: <4.3.2.7.2.20030721155738.056b4260@mail1.cisco.com> Message-ID: References: <20030721125049.A26221@1-4-5.net> <200307211510.h6LFAVUJ023552@sith.maoz.com> <3F1C0AAE.5090909@innovationslab.net> <20030721090607.A24078@1-4-5.net> <3F1C13E6.10702@innovationslab.net> <20030721093323.A24613@1-4-5.net> <3F1C35DB.20402@cisco.com> <20030721125049.A26221@1-4-5.net> <4.3.2.7.2.20030721155738.056b4260@mail1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-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: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Yes, I am very curious of how to achieve ASM at the end hosts using SIP and sdp. Maybe some people from mmusic could give us some hints ? Hoerdt Micka=EBl > IMO, you'll never get a consensus on depricating ASM until all of the > pieces are in place for SSM to accomplish the same thing. I think that > what you will get a consensus on is a document that identifies the missin= g > pieces and provides recommendations on how these pieces could be provided > both at the protocol level, hardware level (MLDv2 Snooping??) and most > importantly, at the application or session level to achieve the same > many-to-many ASM behavior. > > Respectfully, > > Beau Williamson > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 10:43:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15976 for ; Tue, 22 Jul 2003 10:43:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMG-0001WH-Gk for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEhGCR005835 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMG-0001W2-DV for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15940 for ; Tue, 22 Jul 2003 10:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyMD-00056h-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyM6-00056J-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyM1-0001Tg-Cp; Tue, 22 Jul 2003 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDWN-0001G1-Og for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 14:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16837; Thu, 17 Jul 2003 14:30:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDWK-0000VT-00; Thu, 17 Jul 2003 14:30:24 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19dDW9-0000Uc-00; Thu, 17 Jul 2003 14:30:14 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Thu, 17 Jul 2003 11:27:36 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: Colin Perkins , dccp@ietf.org, mmusic@ietf.org, floyd@icir.org, jpanderson@sonusnet.com, "Phelan, Tom" In-Reply-To: References: Message-Id: <1058466296.20494.622.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 17 Jul 2003 11:24:57 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] stream switching (was: Using DCCP for VoIP) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, Can you explain the assumptions that inform your assertion that a blocked write attempt is "drastic" for an A/V application? I understand how this may be the case for VoIP. But for streaming A/V I have very sincere doubts. I am guessing that the difference between explicitly stating the rate to the application and socket blocking is that DCCP is providing reaction time to the application for whatever adaptation the app may need to do to fulfill DCCPs transmission requirements. I submit that an application can achieve the same ends with socket blocking semantics. I maintain that trigger points for codec adaptaion aka "stream switching" should be based on the state of the post network buffer, not changes in rate. A streaming A/V client application will have some amount of post-network buffer. As we know, the purpose of this buffer is to trade end-to-end delay for the ability to mitigate fluctuations in delivery rate. If this buffer runs dry, then the media decoding stalls. And the user experience is no longer seamless. The rate may vary a lot, but the buffer may never drain to dangerous levels. Decreases in codec quality in such cases are completely avoidable. To illustrate how my notion of stream adaptation would work with DCCP: In my model of an A/V application using DCCP, the application reads data from the recipient DCCP end point at the rate required to fill its post-network buffer. If the rate is not fast enough to fill the buffer, the buffer drains, if it fills all the way, it stops reading. In either case, rate decrease due to congestion or rate decrease due to app slow down, the DCCP rate will slow and the sending DCCP end point will block. At this point the transmitting DCCP will admit data either at the rate permitted by congestion control or the rate permitted by the read rate of the receiving application. The transmitting application has knowledge of the time line of the media. It therefore knows how the time line of the media shifts relative to the delivery time line. If the media time line is ahead of the delivery timeline, then the buffer is filling, else the buffer is draining. We can even estimate the state of the buffer with this information. We therefore have enough information to determine trigger points for media rate adaptations ("stream switching"). The DCCP never has to signal the app with a rate, since the app knows the rate at which it is sending AND it knows the rate it would need to achieve the required timeline shift to maintain the state of the post network buffer at a healthy level. The idea of a blocking socket need to be limited to just BSD sockets. The k/u shared buffer concept that the ICIR interns are driving can provide the same semantics. Either you have space to write into the transmit queue or you don't. I also assume that if a codec requires lead time for rate switching, negotiation, etc., then its the wrong codec for this type of application. At the very least, the codec should not require setting up a new decoder in response to a dynamic switch. Inter-key frame time for video should be the longest time lag over which a switch should have to take place. On Thu, 2003-07-17 at 01:33, philippe.gentric@philips.com wrote: > colin perkins wrote: > > >Do the ideas in draft-gentric-mmusic-stream-switching-req-00.txt help any > >here? > > I confirm the problems you report are the same ones the > "stream switching" proposal aims to solve, see below for details. > > --> "Phelan, Tom" writes: > > Hi Sally, > > > > Thanks for the response. See inline ... > > > > Tom P. > > > > [clipped] > > > >The DCCP documents talk about VoIP being one of the main > > > applications for > > > >DCCP. I've been trying to figure out a reasonable way for a VoIP > > > >application to use DCCP. Here's what I've come up with so > > > far. Corrections > > > >and comments would be appreciated. > > > > > > Apart from the fact that my original concern was for "media delivery" > i.e. an application where -contrary to VoIP- end to end delay is > not critical, the problems are exactly the same for *all* > media traffic, be it voice, video, text, etc > > audio is a very good case for study since it > is so critical in terms of *gaps* in the stream. > however the case of *multiple* streams (A+V to start with) > must be considered (see end of the mail)! > > [clipped] > > > > >Now assume the network becomes congested and one (at least) > > > of my packets > > > >get dropped. DCCP decides it must back off the transmission > > > rate, so one of > > > >my 'send's fails with EWOULDBLOCK. > > > This is clearly not very rich feedback, a blocking send is so very drastic! > I would love to see the DCCP stack give earlier feedback something in the spirit of: > > "hey, be ready to change your rate because the connection state > seems to indicate that the available bandwidth is decreasing" > > and then something like: > > "hey, the available bandwidth has reduced to xxx kb/s, change your rate ASAP" > > and in case of "emmergencies" (which definition would actually depend > on the congestion control that has been chosen) if the DCCP stack has > the impression that the available rate is extremely rapidly decreasing > it would send: > > "hey reduce your rate to yyy kb/s NOW" > > and for increases: > > "hey, you can increase your rate up to zzz kb/s" (the codec > can take its time then, there is never any emmergency) > > > > We would also like to understand better how DCCP would or would not > > > work for a VoIP flow that did not have an adaptive codec, but we > > > have not worked this through. (E.g., under congestion, some fraction > > > of the packets from the codec would be dropped by the DCCP sender.) > > > > > > >If the codec family can support this change on the fly, > > > that's great. But > > > >if it requires renegotiation, I'll need to wait for that. > > > If I renegotiate > > > >in band, then my change request packet will get queued until > > > DCCP decides it > > > >can transmit again. If I renegotiate out of band, then that > > > channel might > > > >be having it's problems too. At any rate, there will be a > > > round-trip delay > > > >or so before I can start sending packets again. > > > > > stream switching is *exactly* about solving this: how to change > the rate by switching *codecs* (and/or codec config since a lot > of recent codec have wide ranges of parameters/profiles/rates etc) > > deployed (streaming) products show that it is not only possible, it works fine. > > the assumption is that the negociation takes time, > also the instanciation of the ressources -especially on thin client- also takes time > so it *must* take place "before". This before could be at session start, > but it could also be at anytime during the session, but then not on short notice, > (especially not with a blocking write!?-) > > So -again- it is very important that the DCCP stack gives early feedback > so as to have time to "setup" (RTSP-wise) the required codecs. > > > > If negotiation is required, this is about the codec, not about DCCP, > > > right? > > > > Right. This was meant to indicate that the app probably can't > > immediately change its sending rate. > > > > if the app "cannot change its rate" DCCP will be a very little use *anyway* no? > > > I think you must assume that either the codec rate can be changed (true for > most video codecs and a lot of recent audio codecs) and if the change of rate > goes beyond the flexibility of a given codec you must change the codec and/or its configuration. > [In the stream switching drafts the former is described as "transparent" > and the latter as "non transparent"] > > Note that for coding efficiency reasons it is a *very bad idea* > to try to drive a video codec with rapid instantaneous changes of rate. > > anyway the key issue is that DCCP *and* the codec(s) must have a way to > talk, be configured etc ... work together hand in hand > > > > It's also not clear why you need to stay quiet until the codec change > > > request is acknowledged. DCCP has reduced its allowable send > > > rate, but not > > > to zero. > > the codecs need to know the exact target rate, DCCP must give this as output > (the rate of that feedback could be configurable ?) > > the "contract" between the codecs and the DCCP stack is very simple: > the chosen configuration MUST have a rate smaller (or equal) to the target. > > > That is probably true, but I'm not sure how the other end would react to > > receiving old-codec packets while the new codec is half-negotiated. > > It cannot (see above). > > Another problem is the ability to distinguish between the packet containing data of one codec > or the other since for most decoder feeding the wrong type > of syntax can be very bad (can even lead to crashes etc) > > This issue is addressed in the stream switching proposal: > typically with RTP the "old codec" uses one (dymamically attributed) > PT and the new one uses another one. > > There was the possibility to use another "port", > but with DCCP this would be stupid no? > > this leads me to the following question: > > Can we assume that a given DCCP *connection* will be used > to transport each media e.g. "audio" (i.e. eventually with codec changes > on the fly, indicated by changes in PT of RTP packets)? > > Then for audio+video there will be 2 DCCP connections right? > > How is the DCCP feedback going to work then? > > Indeed in stream swithing I always assumed that the target > is the *pair* A+V i.e. the target rate can be obtained > using SEVERAL combination, examples: > > 5 kb/s AMR audio + 245 kb/s video = 250 kb/s, basic audio > 40 kb/s AAC audio + 210 kb/s video = 250 kb/s, better audio > 80 kb/s AAC stereo + 170 kb/s video = 250 kb/s, good audio > > > ****************** > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 10:43:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15991 for ; Tue, 22 Jul 2003 10:43:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMG-0001W1-69 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEhGMg005819 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMG-0001Vl-0b for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15933 for ; Tue, 22 Jul 2003 10:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyMD-00056e-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyM6-00056H-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyM2-0001U6-00; Tue, 22 Jul 2003 10:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erV9-0001Na-FX for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 03:23:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04166 for ; Tue, 22 Jul 2003 03:23:56 -0400 (EDT) From: hoerdt@clarinet.u-strasbg.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19erV7-0002B1-00 for mmusic@ietf.org; Tue, 22 Jul 2003 03:23:57 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19erUw-0002Ay-00 for mmusic@ietf.org; Tue, 22 Jul 2003 03:23:46 -0400 Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6M7NYnY027372; Tue, 22 Jul 2003 09:23:34 +0200 Date: Tue, 22 Jul 2003 09:28:34 +0200 (CEST) To: Colin Perkins cc: bwilliam@cisco.com, lenny@juniper.net, dmm@1-4-5.net, jmeylor@cisco.com, brian@innovationslab.net, mboned@network-services.uoregon.edu, fenner@research.att.com, mjh@icir.org, randy@psg.com, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt In-Reply-To: <20030722085903.1eb9f5cc.csp@csperkins.org> Message-ID: References: <20030721125049.A26221@1-4-5.net> <200307211510.h6LFAVUJ023552@sith.maoz.com> <3F1C0AAE.5090909@innovationslab.net> <20030721090607.A24078@1-4-5.net> <3F1C13E6.10702@innovationslab.net> <20030721093323.A24613@1-4-5.net> <3F1C35DB.20402@cisco.com> <20030721125049.A26221@1-4-5.net> <4.3.2.7.2.20030721155738.056b4260@mail1.cisco.com> <20030722085903.1eb9f5cc.csp@csperkins.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 22 Jul 2003, Colin Perkins wrote: > The question "how to achieve ASM at the end hosts" is pretty vague, given > that the end hosts already support ASM natively. And that ASM for IPv4 is not supported in the network at large scale today. > > If you mean, how to use SSM in applications, then the SDP source filter > extensions allow you to signal > SSM sessions in SDP (and hence in SIP). This draft is in AD review for > Proposed Standard. As far as I know This is a grammar to describe SSM channel and do not gives any protocol to announce them. > > If the aim is to emulate many-to-many multicast with multiple SSM channel= s, > then an application that knows its peers could, for example, signal a ful= l In my hypothesis, an application do not always knows its peers. You signal a full mesh of SSM channels, OK but how ? which transport protocol ? http over tcp / udp / multicast SSM/ ASM / soft state/hard state ? how do you resolve the prob of high source dynamics ? I mean If I only want to announce IP channels, what is the minimal protocol requirement= to achieve it ? If this is SIP, I would be glad to have to pointer to documents describing it, and it should exist as you mention it in the last mboned session. Thanks, Hoerdt Micka=EBl > mesh of SSM channels using SIP. I'm not aware of any applications that do > this, since a central server architecture is easier and scales to the siz= es > most people are considering, but it doesn't seem outside the realm of wha= t > is possible. The question is better suited for the SIPPING working group, > though. > > Colin > > > --> hoerdt@clarinet.u-strasbg.fr writes: > > Yes, I am very curious of how to achieve ASM at the end hosts using > > SIP and sdp. Maybe some people from mmusic could give us some hints ? > > > > Hoerdt Micka=EBl > > > > > IMO, you'll never get a consensus on depricating ASM until all of the > > > pieces are in place for SSM to accomplish the same thing. I think th= at > > > what you will get a consensus on is a document that identifies the > > > missing pieces and provides recommendations on how these pieces could > > > be provided both at the protocol level, hardware level (MLDv2 > > > Snooping??) and most importantly, at the application or session level > > > to achieve the same many-to-many ASM behavior. > > > > > > Respectfully, > > > > > > Beau Williamson > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > -- > Colin Perkins > csp@csperkins.org > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 10:43:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16020 for ; Tue, 22 Jul 2003 10:43:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMM-0001e8-7n for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEhMfc006324 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMM-0001dv-2v for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15941 for ; Tue, 22 Jul 2003 10:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyMD-00056m-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyM6-00056I-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyM1-0001TT-2M; Tue, 22 Jul 2003 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d1Tj-0007eA-4C for mmusic@optimus.ietf.org; Thu, 17 Jul 2003 01:38:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03125 for ; Thu, 17 Jul 2003 01:38:51 -0400 (EDT) From: musicnetwork@violino.dsi.unifi.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d1Tg-0000uB-00 for mmusic@ietf.org; Thu, 17 Jul 2003 01:38:52 -0400 Received: from violino.dsi.unifi.it ([150.217.15.208]) by ietf-mx with esmtp (Exim 4.12) id 19d1TP-0000u7-00 for mmusic@ietf.org; Thu, 17 Jul 2003 01:38:36 -0400 Received: (from musicnetwork@localhost) by violino.dsi.unifi.it (8.8.7/8.8.7) id HAA28346 for mmusic@ietf.org; Thu, 17 Jul 2003 07:20:30 +0200 Date: Thu, 17 Jul 2003 07:20:30 +0200 Message-Id: <200307170520.HAA28346@violino.dsi.unifi.it> X-Authentication-Warning: violino.dsi.unifi.it: Processed from queue /var/spool/bulkmail/musicnetwork/mqueue To: mmusic@ietf.org Subject: [MMUSIC] MUSICNETWORK Workshop & WEDELMUSIC Conference, Leeds, UK, September 2003 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Dear MUSICNETWORK and WEDELMUSIC Friend All the most recent innovations and hot topics related to music and multimedia will be discussed in Leeds, UK, 15-18 September, 2003, Open to all You are invited to attend the work of the second MUSICNETWORK open workshop. A lot of interesting topics will be addressed: Digital right management, music notation (XML and non), optical music recognition, restoring, audio processing, personalisation, indexing, retrieval, libraries and archives, music publication, internet publication, cross media distribution and protection, MPEG standards, music and standards, etc. Innovative applications, case studies tutorials, demonstrators, etc. http://www.interactivemusicnetwork.org for the FINAL program see: http://www.interactivemusicnetwork.org/events/Second_OpenWorkshop_2003/programme_openworkshop_2003.html The workshop is colocated with the WEDELMUSIC conference innovative aspects of multimedia, DRM technologies, http://www.wedelmusic.org/wedelmusic2003/index.html The final program of the WEDELMUSIC conference will be ready in the next days. The general arrangements and schedule of all the events is reported in the above page. The registration pages are available on line for both events, the registration for the MUSICNETWORK is free of charge. cheers, Paolo Nesi (MUSICNETWORK, Thematic Network of the European Commission) Kia Ng (General Chair of WEDELMUSIC2003 conference, UNIV. Leeds) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 10:57:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16311 for ; Tue, 22 Jul 2003 10:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyZg-00025T-FL for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:57:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEv83h008018 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyZg-00025F-Az for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16303 for ; Tue, 22 Jul 2003 10:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyZd-0005CR-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:57:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyZY-0005CO-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyZZ-00023R-Tn; Tue, 22 Jul 2003 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyWg-0001ue-Pb for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 10:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16263 for ; Tue, 22 Jul 2003 10:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyWe-0005BW-00 for mmusic@ietf.org; Tue, 22 Jul 2003 10:54:00 -0400 Received: from smtp4.wanadoo.fr ([193.252.22.26] helo=mwinf0503.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 19eyWT-0005At-00 for mmusic@ietf.org; Tue, 22 Jul 2003 10:53:49 -0400 Received: from purple.nge.isi.edu (AStrasbourg-206-1-12-233.w80-14.abo.wanadoo.fr [80.14.240.233]) by mwinf0503.wanadoo.fr (SMTP Server) with ESMTP id 0398C680004A for ; Tue, 22 Jul 2003 16:52:12 +0200 (CEST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6MEptAN051972; Tue, 22 Jul 2003 15:52:01 +0100 (BST) (envelope-from csp@csperkins.org) Date: Tue, 22 Jul 2003 16:51:55 +0200 From: Colin Perkins To: hoerdt@clarinet.u-strasbg.fr Cc: bwilliam@cisco.com, lenny@juniper.net, dmm@1-4-5.net, jmeylor@cisco.com, brian@innovationslab.net, mboned@network-services.uoregon.edu, fenner@research.att.com, mjh@icir.org, randy@psg.com, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt Message-Id: <20030722165155.7bb0a189.csp@csperkins.org> In-Reply-To: References: <20030721125049.A26221@1-4-5.net> <200307211510.h6LFAVUJ023552@sith.maoz.com> <3F1C0AAE.5090909@innovationslab.net> <20030721090607.A24078@1-4-5.net> <3F1C13E6.10702@innovationslab.net> <20030721093323.A24613@1-4-5.net> <3F1C35DB.20402@cisco.com> <20030721125049.A26221@1-4-5.net> <4.3.2.7.2.20030721155738.056b4260@mail1.cisco.com> <20030722085903.1eb9f5cc.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> hoerdt@clarinet.u-strasbg.fr writes: > > If you mean, how to use SSM in applications, then the SDP source filter > > extensions allow you to signal > > SSM sessions in SDP (and hence in SIP). This draft is in AD review for > > Proposed Standard. > > As far as I know This is a grammar to describe SSM channel and do not > gives any protocol to announce them. Correct. SDP is used by other protocols, such as RTSP, SIP or SAP, which do the actual setup. > > If the aim is to emulate many-to-many multicast with multiple SSM > > channels, then an application that knows its peers could, for example, > > signal a full > > In my hypothesis, an application do not always knows its peers. You > signal a full mesh of SSM channels, OK but how ? which transport > protocol ? http over tcp / udp / multicast SSM/ ASM / soft state/hard > state ? how do you resolve the prob of high source dynamics ? I mean If I > only want to announce IP channels, what is the minimal protocol > requirement to achieve it ? If this is SIP, I would be glad to have to > pointer to documents describing it, and it should exist as you mention it > in the last mboned session. If you know the peers, I would expect standard SIP signalling to work with minimal - if any - extensions. This would let you build a conferencing app above a mesh of SSM channels, for example. The SIPPING working group would be the correct place to discuss this. I suspect, however, that you wish to fully emulate an ASM service over SSM, including the rendezvous and discovery aspects of ASM, rather than building an application that uses the SSM service in a novel way to provide many-to- many multicast. I question what problem you are trying to solve by doing this. -- Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 11:22:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17191 for ; Tue, 22 Jul 2003 11:22:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyxs-0003F1-NA for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 11:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MFM8uI012445 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 11:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyxs-0003Ee-Jt for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 11:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17178 for ; Tue, 22 Jul 2003 11:22:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyxr-0005Qs-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 11:22:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyxm-0005Qp-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 11:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyxl-0003Ba-HW; Tue, 22 Jul 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eywr-0003AF-NJ for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 11:21:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17163 for ; Tue, 22 Jul 2003 11:21:02 -0400 (EDT) From: hoerdt@clarinet.u-strasbg.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eywq-0005QA-00 for mmusic@ietf.org; Tue, 22 Jul 2003 11:21:04 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19eywf-0005PP-00 for mmusic@ietf.org; Tue, 22 Jul 2003 11:20:53 -0400 Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6MFJcnY004710; Tue, 22 Jul 2003 17:19:38 +0200 Date: Tue, 22 Jul 2003 17:24:44 +0200 (CEST) To: Colin Perkins cc: dmm@1-4-5.net, mboned@network-services.uoregon.edu, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt In-Reply-To: <20030722165155.7bb0a189.csp@csperkins.org> Message-ID: References: <20030721125049.A26221@1-4-5.net> <200307211510.h6LFAVUJ023552@sith.maoz.com> <3F1C0AAE.5090909@innovationslab.net> <20030721090607.A24078@1-4-5.net> <3F1C13E6.10702@innovationslab.net> <20030721093323.A24613@1-4-5.net> <3F1C35DB.20402@cisco.com> <20030721125049.A26221@1-4-5.net> <4.3.2.7.2.20030721155738.056b4260@mail1.cisco.com> <20030722085903.1eb9f5cc.csp@csperkins.org> <20030722165155.7bb0a189.csp@csperkins.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE =2E.. > including the rendezvous and discovery aspects of ASM, rather than buildi= ng > an application that uses the SSM service in a novel way to provide many-t= o- > many multicast. I question what problem you are trying to solve by doing > this. You didn't answered my question but you answered your own: to fully emulated an ASM service over SSM. Many applications do not know the peers before the application start and may require a lightweight mechanism to do source discovery and Group managment at IP level instead of have the full machinery of SIP. Is there a working group for that ? Read : I don't want to do an HTTP GET on some overloaded web server only to know that there are no new sources in my highly dynamic session. I prefer to open an SSM control channel on my Host, and to manage my Group on with my application requirement at IP level. If some higher session level requirement are required by the application, then I will use SIP/RTSCP/RTP etc... Then you may ask : why emulate ASM over SSM as we already have ASM ? Answer : At this moment, ASM for IPv4 is not scalable in interdomain but SSM is, and if you want to have something else than TV on the large-scale Internet it would be good to have some IP level mechanism to still have an ASM behaviour at the interdomain scale. Hoerdt Micka=EBl > > -- > Colin Perkins > csp@csperkins.org > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 11:33:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15992 for ; Tue, 22 Jul 2003 10:43:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMH-0001dP-Ml for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEhHEt006284 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 10:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyMG-0001Vm-2y for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15935 for ; Tue, 22 Jul 2003 10:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyMD-00056n-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyM6-00056L-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 10:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyM1-0001Tt-My; Tue, 22 Jul 2003 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19er7Z-0000LK-9Y for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 02:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03649 for ; Tue, 22 Jul 2003 02:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19er7V-00020x-00 for mmusic@ietf.org; Tue, 22 Jul 2003 02:59:33 -0400 Received: from [62.146.145.71] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19er7K-00020u-00 for mmusic@ietf.org; Tue, 22 Jul 2003 02:59:22 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6M6x3Ll049880; Tue, 22 Jul 2003 07:59:04 +0100 (BST) (envelope-from csp@csperkins.org) Date: Tue, 22 Jul 2003 08:59:03 +0200 From: Colin Perkins To: hoerdt@clarinet.u-strasbg.fr Cc: bwilliam@cisco.com, lenny@juniper.net, dmm@1-4-5.net, jmeylor@cisco.com, brian@innovationslab.net, mboned@network-services.uoregon.edu, fenner@research.att.com, mjh@icir.org, randy@psg.com, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt Message-Id: <20030722085903.1eb9f5cc.csp@csperkins.org> In-Reply-To: References: <20030721125049.A26221@1-4-5.net> <200307211510.h6LFAVUJ023552@sith.maoz.com> <3F1C0AAE.5090909@innovationslab.net> <20030721090607.A24078@1-4-5.net> <3F1C13E6.10702@innovationslab.net> <20030721093323.A24613@1-4-5.net> <3F1C35DB.20402@cisco.com> <20030721125049.A26221@1-4-5.net> <4.3.2.7.2.20030721155738.056b4260@mail1.cisco.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The question "how to achieve ASM at the end hosts" is pretty vague, given that the end hosts already support ASM natively.=20 If you mean, how to use SSM in applications, then the SDP source filter extensions allow you to signal SSM sessions in SDP (and hence in SIP). This draft is in AD review for Proposed Standard. If the aim is to emulate many-to-many multicast with multiple SSM channels, then an application that knows its peers could, for example, signal a full mesh of SSM channels using SIP. I'm not aware of any applications that do this, since a central server architecture is easier and scales to the sizes most people are considering, but it doesn't seem outside the realm of what is possible. The question is better suited for the SIPPING working group, though. Colin --> hoerdt@clarinet.u-strasbg.fr writes: > Yes, I am very curious of how to achieve ASM at the end hosts using > SIP and sdp. Maybe some people from mmusic could give us some hints ? >=20 > Hoerdt Micka=EBl >=20 > > IMO, you'll never get a consensus on depricating ASM until all of the > > pieces are in place for SSM to accomplish the same thing. I think that > > what you will get a consensus on is a document that identifies the > > missing pieces and provides recommendations on how these pieces could > > be provided both at the protocol level, hardware level (MLDv2 > > Snooping??) and most importantly, at the application or session level > > to achieve the same many-to-many ASM behavior. > > > > Respectfully, > > > > Beau Williamson > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Colin Perkins csp@csperkins.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 11:56:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18005 for ; Tue, 22 Jul 2003 11:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezUo-0004Cc-Aj for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 11:56:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MFuAxR016148 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 11:56:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezUn-0004CN-T1 for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 11:56:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17986 for ; Tue, 22 Jul 2003 11:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezUm-0005dV-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 11:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ezUh-0005dS-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 11:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezUg-0004Av-2j; Tue, 22 Jul 2003 11:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezUB-0004AL-OM for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 11:55:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17979; Tue, 22 Jul 2003 11:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezUA-0005dL-00; Tue, 22 Jul 2003 11:55:30 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ezTz-0005cy-00; Tue, 22 Jul 2003 11:55:19 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6MFsujG018276; Tue, 22 Jul 2003 17:54:56 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6K47F4; Tue, 22 Jul 2003 17:58:06 +0200 Message-ID: <3F1D5E4F.2080609@ericsson.com> Date: Tue, 22 Jul 2003 17:54:55 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damon Lanphear CC: philippe.gentric@philips.com, dccp@ietf.org, mmusic@ietf.org References: <1058466296.20494.622.camel@poesis.dev.prognet.com> In-Reply-To: <1058466296.20494.622.camel@poesis.dev.prognet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] stream switching (was: Using DCCP for VoIP) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Damon and Philippe, I agree with you Damon that there shouldn't be a large problem for a streaming server to use a blocking socket as long some time-out of fairly short time (100-500 ms) is available. Then a streaming server can maintain its relation to the expected transmission schedule. When falling to much behind the server can simply switch to a lower bit-rate version and see if that enables it to catch up with the transmission schedule. However to make such a mechanism to provide decent performance some limitations are needed, like client buffer sizes, initial buffering. I think that as long as you have some receiver buffer to enable the sender side to have time to decide on what the appropriate response is to a blocking operation this can work. However in applications that does not have this behaviour, like VoIP as you mention, that only have a receiver buffer to remove network jitter and which desire a end-to-end delay below 400 ms. However for the control model that I think Philippe is having in mind the blocking socket does not work very well. My understanding of the model Philippe is using in his proposal for stream switching control for RTSP is that the server will basically send according to transmission schedule for the current rate. Then when the client detects that the network buffers builds up for that rate and that media is not delivered fast enough the client will signal the server to drop to lower rate. The new rate will then allow the network buffers to drain and the client buffer to refill in time sense. That way the server has no need to maintain close control over the receiver buffers as this is monitored and controlled by the client. I think that one major issue around the stream switching is what control models one envision to use. The second question is then how this relates to any congestion control mechanism in use. It seams to me that having a client controlled stream switching model may not work that well with the suggested congestion control models provided by DCCP. Further comments to your reply. Damon Lanphear wrote: > Philippe, > > Can you explain the assumptions that inform your assertion that a > blocked write attempt is "drastic" for an A/V application? I understand > how this may be the case for VoIP. But for streaming A/V I have very > sincere doubts. > > I am guessing that the difference between explicitly stating the rate to > the application and socket blocking is that DCCP is providing reaction > time to the application for whatever adaptation the app may need to do > to fulfill DCCPs transmission requirements. > > I submit that an application can achieve the same ends with socket > blocking semantics. > > I maintain that trigger points for codec adaptaion aka "stream > switching" should be based on the state of the post network buffer, not > changes in rate. A streaming A/V client application will have some > amount of post-network buffer. As we know, the purpose of this buffer is > to trade end-to-end delay for the ability to mitigate fluctuations in > delivery rate. If this buffer runs dry, then the media decoding stalls. > And the user experience is no longer seamless. The rate may vary a lot, > but the buffer may never drain to dangerous levels. Decreases in codec > quality in such cases are completely avoidable. > > To illustrate how my notion of stream adaptation would work with DCCP: > > In my model of an A/V application using DCCP, the application reads data > from the recipient DCCP end point at the rate required to fill its > post-network buffer. If the rate is not fast enough to fill the buffer, > the buffer drains, if it fills all the way, it stops reading. In either > case, rate decrease due to congestion or rate decrease due to app slow > down, the DCCP rate will slow and the sending DCCP end point will > block. At this point the transmitting DCCP will admit data either at > the rate permitted by congestion control or the rate permitted by the > read rate of the receiving application. I don't think using app slow signalling is appropriate for a streaming session, I think that a bit more flow control is actually required to prevent wasting bandwidth on packets that get dropped on the receiver side due to overflowing buffers. However this can be accomplished at application layer for those application that needs this. > > The transmitting application has knowledge of the time line of the > media. It therefore knows how the time line of the media shifts > relative to the delivery time line. If the media time line is ahead of > the delivery timeline, then the buffer is filling, else the buffer is > draining. We can even estimate the state of the buffer with this > information. We therefore have enough information to determine trigger > points for media rate adaptations ("stream switching"). The DCCP never > has to signal the app with a rate, since the app knows the rate at which > it is sending AND it knows the rate it would need to achieve the > required timeline shift to maintain the state of the post network buffer > at a healthy level. > > The idea of a blocking socket need to be limited to just BSD sockets. > The k/u shared buffer concept that the ICIR interns are driving can > provide the same semantics. Either you have space to write into the > transmit queue or you don't. > > I also assume that if a codec requires lead time for rate switching, > negotiation, etc., then its the wrong codec for this type of > application. At the very least, the codec should not require setting up > a new decoder in response to a dynamic switch. Inter-key frame time for > video should be the longest time lag over which a switch should have to > take place. Due to how media codecs work there are switching points that will result in optimal quality and there are other points that will result in worse quality. However to my understanding switching down in rate can normally be achieved with very little degradation due to the simple fact that we are switching from a fuller codec state to a less complete state. For upswitches in rate there is usually more need for finding the optimal switch point or quality will suffer severely. However there is no time pressure when switching up so one can wait for these points in the presentation. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 12:09:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18415 for ; Tue, 22 Jul 2003 12:09:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezhL-0005IH-NF for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 12:09:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MG97D9020343 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 12:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezhL-0005I2-I2 for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 12:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18397 for ; Tue, 22 Jul 2003 12:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezhK-0005ji-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 12:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ezhE-0005jf-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 12:09:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezhE-0005GT-OQ; Tue, 22 Jul 2003 12:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezh5-0005GF-N7 for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 12:08:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18375 for ; Tue, 22 Jul 2003 12:08:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezh4-0005ja-00 for mmusic@ietf.org; Tue, 22 Jul 2003 12:08:50 -0400 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 19ezgt-0005jX-00 for mmusic@ietf.org; Tue, 22 Jul 2003 12:08:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3506B.ABDE594D" Date: Tue, 22 Jul 2003 18:09:47 +0200 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B90949B0610D@swing.cefriel.it> Thread-Topic: RTSP and mobility Thread-Index: AcNQa6pgY2LJsTmKTzWtVV87xFz8IA== From: "Enrico Balatti" To: Subject: [MMUSIC] RTSP and mobility Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3506B.ABDE594D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, =20 I've a question regarding to RTSP protocol an Mobility. =20 Let say we have a Mobile Host (MH) that starts an RTSP session. Now, the MH moves into a new "network domain" and it wants to continue with its RTSP session. My question is: what is the best way that it can use to continue with the session? It could do the following: - teardown the session in the old domain - restart the session in the new domain (from the exact "streaming = point" it was in the old domain) =20 Can it teardown the session in the new domain?(my doubt is that in the = new domain it is reachable via a different IPaddress...for example with MobileIP via a new = CareOfAddress). =20 Best Regards, =20 Ing. Enrico M. Balatti =20 Tel. 02-23954327 Fax. +39 02 23954527 < mailto:balatti@cefriel.it>=20 CEFRIEL -Network Systems Area=20 Via Fucini, 2=20 20133 Milano - Italy=20 < http://www.cefriel.it/>=20 =20 =20 ------_=_NextPart_001_01C3506B.ABDE594D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 All,
 
I've a = question=20 regarding to RTSP protocol an Mobility.
 
Let = say we have a=20 Mobile Host (MH) that starts an RTSP session.
Now, = the=20 MH moves into a new "network domain" and it wants to=20 continue
with = its RTSP=20 session.
My = question=20 is:
what = is the best way=20 that it can use to continue with the session?
It = could do the=20 following:
- = teardown the=20 session in the old domain
- = restart the=20 session in the new domain (from the exact "streaming point" it was in = the old=20 domain)
 
Can it = teardown the=20 session in the new domain?(my doubt is that in the new domain it is=20 reachable
via a = different=20 IPaddress...for example with MobileIP via a new=20 CareOfAddress).
 
Best=20 Regards,
 

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

Fax. +39 02 23954527

 <mailto:balatti@cefriel.it>=20

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

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

 

 
------_=_NextPart_001_01C3506B.ABDE594D-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 12:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18983 for ; Tue, 22 Jul 2003 12:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezzk-0005zi-3u for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 12:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MGS81t023036 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 12:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezzk-0005zT-0h for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 12:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18972 for ; Tue, 22 Jul 2003 12:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezzi-0005qz-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 12:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ezzc-0005qw-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 12:28:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezzc-0005xo-Vv; Tue, 22 Jul 2003 12:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezzR-0005xU-Ld for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 12:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18942 for ; Tue, 22 Jul 2003 12:27:45 -0400 (EDT) From: hoerdt@clarinet.u-strasbg.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezzQ-0005qp-00 for mmusic@ietf.org; Tue, 22 Jul 2003 12:27:48 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19ezzF-0005qa-00 for mmusic@ietf.org; Tue, 22 Jul 2003 12:27:37 -0400 Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6MGQLnY005611; Tue, 22 Jul 2003 18:26:21 +0200 Date: Tue, 22 Jul 2003 18:31:27 +0200 (CEST) To: David Meyer cc: mboned@network-services.uoregon.edu, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt In-Reply-To: <20030722082516.A3189@1-4-5.net> Message-ID: References: <20030722082516.A3189@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE I agree, and this type of statements could be supported by history (I will be short): 1984 : First IP stack. 1985 : Deering start his thesis (Internet size about 2000 hosts) December 1985 : RFC 966 "Host groups : a multicast extension to the Internet Protocol" September 1986 : start of implementation. May 1988 : First IP multicast ROUTING based on 4.3+ networking code (Internet size, about 30000 hosts). In the old times, when ASM over IP has been invented, Ethernet was pretty successfull and supported broadcast/multicast. So a natural way to do multicast over IP, was to deploy Broadcast and prune mechanisms, which works pretty well for small topologies (dvmrp, pim-dense). 1991 : Deering has finished his thesis, Holbrook start to work on Multicast 1992 : the First internet Audiocast at the IETF : what a wonderful new techno, but will it scale ? (Internet size : about 800 000 hosts). Broadcast && Prune is no more considered as a doable solution . 1993-94 : Receiver Initiated multicast protocol time. Achieves very good scalability but how do we achieve source discovery now ? The Internet start to become very complex, and now it can be fully considered as a complex system. Anyway, due to RFC1112 there must be some "broadcast and prune mechanism" somewhere due to the logical nature of an IP group (an class D IP multicast address is a Name, and do not gives any topological information on the group): MSDP. 1994-95 : Web explosion (about 6*10^6 hosts at the end of 1995). Hoolbrook may then still working on his thesis, looking at what is happening to the Internet (growing growing growing...) and asking himself : why putting source discovery in the network ? 2001 : (S,G) channel mode is out. it get rid of Source discovery and many multicast complex problems only by pushing complexity in the end hosts. No more multicast address allocation/collision, no more RP discovery, no more MSDP. It simply obey to a simple rule in any complex system : Core pieces must but simple, any other mechanisms should be considered at the ends hosts first, as changing these core pieces may take down the entire system. Well, this is just short history, and I am sure that we could write a pretty interesting document about "IP multicast history 1984-2003" and what I conclude from history is that : -Broadcast is OK for LANs -Broadcast and prune is OK for small domains. - Receiver driven only mechanisms is OK for big size topologies like the Internet that we have TODAY : it scale. It is ok too if we consider large domains (but small compared to the Internet size) with a few Rendez-vous point, for source discovery, if the number of RP becomes to high, we fall in the Broadcast and prune. - ASM model is not compatible with Receiver driven only technology because "Sources just send, and the group is open" - RFC1112. - SSM model is fully compatible with Receiver driven technology - To achieve ASM model in the interdomain we'll always need source discovery AND some broadcast (at least to the RP). Do not have source discovery or broadcast means having one RP per group, or having the RP serving a well known set of group : this is the case in the Embedded Rp solution, and this is the case with SSM over IP. Hoerdt Micka=EBl On Tue, 22 Jul 2003, David Meyer wrote: > > =09Folks, > > =09Here's something that would be productive: Let's talk > =09about facts, and stay away from statements such as > > ... ASM for IPv4 is not scalable in interdomain but SSM is ... > > =09We need to support this type of statement, otherwise it > =09is just marketing for SSM (maybe that is appropriate > =09somewhere, but not on the MBONED list). > > =09Let's stay away from marketing and speculating about what > =09might happen (or for that matter, what might have > =09happened), and spend our resources on multicast > =09deployment, which is the charter of MBONED. > > =09Thanks, > > =09Dave > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 12:51:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19401 for ; Tue, 22 Jul 2003 12:51:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0M0-0006hP-MQ for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 12:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MGp8MW025745 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 12:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0M0-0006hA-IZ for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 12:51:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19393 for ; Tue, 22 Jul 2003 12:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0Ly-0005wY-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 12:51:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f0Lt-0005wV-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 12:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0Lu-0006fT-6p; Tue, 22 Jul 2003 12:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0L9-0006f1-5K for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 12:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19361 for ; Tue, 22 Jul 2003 12:50:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0L7-0005vm-00 for mmusic@ietf.org; Tue, 22 Jul 2003 12:50:13 -0400 Received: from breeze.research.telcordia.com ([192.4.6.9]) by ietf-mx with esmtp (Exim 4.12) id 19f0Kr-0005vT-00 for mmusic@ietf.org; Tue, 22 Jul 2003 12:49:57 -0400 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.12.8/8.12.1) with ESMTP id h6MGmkn6009358; Tue, 22 Jul 2003 12:48:47 -0400 (EDT) Message-Id: <200307221648.h6MGmkn6009358@breeze.research.telcordia.com> To: "Enrico Balatti" cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility In-reply-to: Your message of "Tue, 22 Jul 2003 18:09:47 +0200." <6F5FB8313FE82C4EA10DA4DA40B90949B0610D@swing.cefriel.it> Date: Tue, 22 Jul 2003 12:48:46 -0400 From: Ashutosh Dutta Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Enrico, please see the paper http://www.cs.columbia.edu/~hgs/papers/Schu0007_Application.pdf, it talks about some issues related to RTSP and mobility when IP address changes on the mobile because of subnet movement or domain movement. Thanks Ashutosh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 22 20:54:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02276 for ; Tue, 22 Jul 2003 20:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7tQ-0007tt-OA for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 20:54:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N0s8sN030365 for mmusic-archive@odin.ietf.org; Tue, 22 Jul 2003 20:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7tQ-0007tg-LU for mmusic-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 20:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02273 for ; Tue, 22 Jul 2003 20:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f7tO-0000e5-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 20:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f7tI-0000e2-00 for mmusic-web-archive@ietf.org; Tue, 22 Jul 2003 20:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7tI-0007t3-Vy; Tue, 22 Jul 2003 20:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7sX-0007sW-V6 for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 20:53:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02258 for ; Tue, 22 Jul 2003 20:53:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f7sV-0000dh-00 for mmusic@ietf.org; Tue, 22 Jul 2003 20:53:11 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19f7sK-0000dD-00 for mmusic@ietf.org; Tue, 22 Jul 2003 20:53:00 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6N0pT101817 for ; Tue, 22 Jul 2003 20:51:29 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NLVYYCT8; Tue, 22 Jul 2003 20:51:29 -0400 Received: from nortelnetworks.com (acart1dz.ca.nortel.com [47.129.129.108]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RVWPGF2; Tue, 22 Jul 2003 20:51:30 -0400 Message-ID: <3F1DDBFD.2050909@nortelnetworks.com> Date: Tue, 22 Jul 2003 20:51:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SDP Syntax vs. RFC 3108 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I took the action last week to compare RFC 3108 syntax against sdp-new, to see if any action was necessary to realign them. RFC 3108 documents the SDP conventions for ATM. It defines a lot of attributes, which should not be a problem for syntax. However, it also modifies the c= and m= lines. The c= line is not a problem; the m= line has a different grammar from SDP-new. m= line: ======== SDP-new syntax: media-field = "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF media = token port = 1*DIGIT proto = token "/" token / token fmt = token RFC 3108 syntax (most complicated form): m= ... media presents no problems -- same as in basic SDP. virtualConnectionId can have several forms, matching the patterns token token "/" token token "/" token "/" token token "/" token "/" token "/" token To fit this, you would need to substitute token *("/" token)) for the existing sub-rule port ["/" integer] transport always matches token "/" token matches 1*(SP fmt) The problem lies in the repetition. You would need to change SP proto 1*(SP fmt) to 1*(SP proto 1*(SP fmt)) So the complete m= line to accommodate RFC 3108 becomes media-field = "m=" media SP token *("/" token)) 1*(SP proto 1*(SP fmt)) CRLF Tom Taylor _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 08:10:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09202 for ; Wed, 23 Jul 2003 08:10:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fIRe-0006R2-2j for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 08:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NCAAVM024729 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 08:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fIRd-0006Qm-VZ for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 08:10:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09196 for ; Wed, 23 Jul 2003 08:10:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fIRc-000471-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 08:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fIRX-00046y-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 08:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fIRV-0006PK-AF; Wed, 23 Jul 2003 08:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fIRF-0006ML-6S for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 08:09:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09188; Wed, 23 Jul 2003 08:09:42 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fIR1-00046m-00; Wed, 23 Jul 2003 08:09:31 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19fIQq-00046h-00; Wed, 23 Jul 2003 08:09:20 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 4ADCA5484F; Wed, 23 Jul 2003 14:08:59 +0200 (MET DST) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 50C8019C55; Wed, 23 Jul 2003 14:08:58 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 7CC6C19C4B; Wed, 23 Jul 2003 14:08:56 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA17942; Wed, 23 Jul 2003 14:08:55 +0200 (MEST) To: Magnus Westerlund Cc: Damon Lanphear , dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 23 Jul 2003 13:59:17 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 23/07/2003 14:10:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus,Damon, let us forget a minute about the exact application, (because my point is *not* specific to stream switching) let us instead concentrate on the following problem: you write: "the server can simply switch to a lower bit-rate" This is an indication we are on agreement on one thing: DCCP is about rate-driven applications. This is why my concern has been from the very start: how is the sending application (what ever it is) going to know what rate it must use? The answers you gave so far seem to indicate you are confident the application can "compute" such a rate based on the behavior of a blocking API... (ok, allow me now to *also* put aside my humble opinion that trying to achieve that is not a good idea) I advocate that it would be a shame **because the information is already available**! Allow me to quote Section 3 of RFC 3448: " Generally speaking, TFRC's congestion control mechanism works as follows: o The receiver measures the loss event rate and feeds this information back to the sender. o The sender also uses these feedback messages to measure the round-trip time (RTT). o The loss event rate and RTT are then fed into TFRC's throughput equation, giving the acceptable transmit rate. o The sender then adjusts its transmit rate to match the calculated rate. " This seems to imply that a "natural" sender-side API for DCCP would explicitely inform the application ("sender") about this "acceptable transmit rate". It also happens to be the *best thing* that can be provided to an application designed to perform network adaptation. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 10:46:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15637 for ; Wed, 23 Jul 2003 10:46:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKsD-0005JX-PM for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 10:45:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NEjj7G020423 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 10:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKsD-0005JK-MQ for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 10:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15612 for ; Wed, 23 Jul 2003 10:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKsB-00059j-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 10:45:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fKs5-00059V-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 10:45:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKrW-0005Db-Ft; Wed, 23 Jul 2003 10:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKr2-0005CZ-0q for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 10:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15589; Wed, 23 Jul 2003 10:44:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKqz-00058t-00; Wed, 23 Jul 2003 10:44:29 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19fKqo-00058Q-00; Wed, 23 Jul 2003 10:44:18 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6NEhc04002164; Wed, 23 Jul 2003 10:43:38 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 23 Jul 2003 10:43:33 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 10:43:32 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB47D@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" , Magnus Westerlund Cc: Damon Lanphear , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Date: Wed, 23 Jul 2003 10:43:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Phillipe, In thinking about your draft on stream rate switching and this discussion on APIs I've come to the conclusion that there are actually three different applications being discussed, with three different sets of requirements. One of these applications can be reasonably satisfied with a blocking API (although there could be some efficiencies with other capabilities). For the other two I'm not sure yet what would work. Excuse me if I'm re-inventing something here, but the three applications I have in mind are: o One-way pre-recorded media o One-way live media o Two-way interactive media The relevant difference, as far as this discussion goes, between recorded and live media is that recorded media can be transmitted from the sender as fast as the network allows (assuming buffering at the receiver). Live media can only be transmitted at the rate that it's generated. The difference between one-way (live) and two-way is the size of the playout buffer. In one-way media you can use a playout buffer that's hundreds of times larger than the round trip time. In two-way media the playout buffer is on the same order of magnitude as the round trip time. So, it seems to me that one-way pre-recorded media can be reasonably served by DCCP with TFRC and a sockets-like (blocking) API. For example, assume that the sender has a media stream in two bit rates, high and low. Also assume that the sender is able to estimate the depth of the receiver's playout buffer (either via feedback from the receiver or some other means). Now set three thresholds in the playout buffer, a low threshold, a playback start threshold and a high threshold, in order of increasing depth. To start the connection, the sender begins transmitting data from the high bit rate stream as fast as TFRC allows (blocking the transmit thread for rate control). Since TFRC is in slow-start, this is probably too slow initially, but eventually the rate might increase to fast enough and past. The receiver buffers data until the playback start threshold is reached, and then begins playback. If the TFRC rate never gets fast enough, or a packet loss makes TFRC drop the rate, the receiver will drain the playout buffer faster than it's being filled. If the playout buffer drops below the low threshold, the sender switches to the low bit rate stream. Assuming that the network has a little bit more capacity than the low bit rate stream requires, the playout buffer will begin filling again. When the buffer crosses the high threshold the sender switches to the high bit rate stream. Assuming that the network still doesn't have enough capacity for the high bit rate stream, the playout buffer will drain. When it reaches the low threshold the sender switches back to the low bit rate. The sender will oscillate back and forth like this until the connection is terminated. So, in this scheme, the sender doesn't need to know the rate that TFRC has determined, it simply always sends as fast as TFRC allows. TFRC shapes the stream to the network's requirements, and the feedback about the playout buffer allows the sender to shape the stream to the application's requirements. I haven't been able to work out acceptable scenarios for the other two applications yet. It seems almost certain to me that TFRC and a blocking API is not at all suitable for two-way media. It might be suitable for one-way live media, but I haven't figured out how it could be yet. If anyone has ideas here I'd like to hear them :-). Tom P. > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Wednesday, July 23, 2003 7:59 AM > To: Magnus Westerlund > Cc: Damon Lanphear; dccp@ietf.org; mmusic@ietf.org > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > switching) > > > > Magnus,Damon, > > let us forget a minute about the exact application, > (because my point is *not* specific to stream switching) > let us instead concentrate on the following problem: > > you write: > > "the server can simply switch to a lower bit-rate" > > This is an indication we are on agreement on one thing: > DCCP is about rate-driven applications. > > This is why my concern has been from the very start: > how is the sending application (what ever it is) > going to know what rate it must use? > > The answers you gave so far seem to indicate you are confident > the application can "compute" such a rate based on the > behavior of a blocking API... > > (ok, allow me now to *also* put aside my humble opinion that > trying to achieve that is not a good idea) > > I advocate that it would be a shame **because the information > is already available**! > > Allow me to quote Section 3 of RFC 3448: > > " Generally speaking, TFRC's congestion control mechanism works as > follows: > > o The receiver measures the loss event rate and feeds this > information back to the sender. > > o The sender also uses these feedback messages to measure the > round-trip time (RTT). > > o The loss event rate and RTT are then fed into TFRC's throughput > equation, giving the acceptable transmit rate. > > o The sender then adjusts its transmit rate to match the > calculated > rate. > " > > This seems to imply that a "natural" sender-side API for DCCP > would explicitely > inform the application ("sender") about this "acceptable > transmit rate". > > It also happens to be the *best thing* that can be provided to > an application designed to perform network adaptation. > > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 13:47:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21097 for ; Wed, 23 Jul 2003 13:47:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNhl-0005lW-02 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 13:47:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHl8wh022158 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 13:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNhk-0005lF-Rp for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21065 for ; Wed, 23 Jul 2003 13:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNhi-0006Qq-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 13:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fNhc-0006Qn-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 13:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNhe-0005fB-EM; Wed, 23 Jul 2003 13:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNgw-0005VF-5j for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 13:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20983; Wed, 23 Jul 2003 13:46:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNgs-0006Pq-00; Wed, 23 Jul 2003 13:46:14 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19fNgh-0006Oz-00; Wed, 23 Jul 2003 13:46:03 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Wed, 23 Jul 2003 10:44:59 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org In-Reply-To: References: Message-Id: <1058982128.6255.45.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 23 Jul 2003 10:42:08 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Philippe, No one is really taking the position that a DCCP API should not make the transmission rate available to the application. This is quite a straightforward issue. DCCP can easily expose this key piece of information. I am more concerned with how an application meets DCCPs transmission limits (i.e. transmits at the required rate). Let's put the issue of adaptation aside for a moment and just concern ourselves with how an application paces data to the network. My view is that DCCP offers the application both congestion control AND the ability to manage the transmission schedule. I assume that DCCP will pace data to the lower layers at the rate required of the associated CCID spec. For the application to do this pacing as well would be redundant work. What I don't quite understand about your position is the role played by the application in pacing data. Do you maintain that the application should pace data, or DCCP or both? That is, is the use of the transmit rate to the application purely informative of a rate adaptation process, or of the transmit process as a whole? On Wed, 2003-07-23 at 04:59, philippe.gentric@philips.com wrote: > Magnus,Damon, > > let us forget a minute about the exact application, > (because my point is *not* specific to stream switching) > let us instead concentrate on the following problem: > > you write: > > "the server can simply switch to a lower bit-rate" > > This is an indication we are on agreement on one thing: > DCCP is about rate-driven applications. > > This is why my concern has been from the very start: > how is the sending application (what ever it is) > going to know what rate it must use? > > The answers you gave so far seem to indicate you are confident > the application can "compute" such a rate based on the behavior of a blocking API... > > (ok, allow me now to *also* put aside my humble opinion that trying to achieve that is not a good idea) > > I advocate that it would be a shame **because the information is already available**! > > Allow me to quote Section 3 of RFC 3448: > > " Generally speaking, TFRC's congestion control mechanism works as > follows: > > o The receiver measures the loss event rate and feeds this > information back to the sender. > > o The sender also uses these feedback messages to measure the > round-trip time (RTT). > > o The loss event rate and RTT are then fed into TFRC's throughput > equation, giving the acceptable transmit rate. > > o The sender then adjusts its transmit rate to match the calculated > rate. > " > > This seems to imply that a "natural" sender-side API for DCCP would explicitely > inform the application ("sender") about this "acceptable transmit rate". > > It also happens to be the *best thing* that can be provided to > an application designed to perform network adaptation. > > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 13:54:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21377 for ; Wed, 23 Jul 2003 13:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNoW-00064g-4M for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 13:54:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHs8CH023326 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 13:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNoW-000649-0z for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21332 for ; Wed, 23 Jul 2003 13:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNoT-0006Uj-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 13:54:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fNoO-0006Ug-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 13:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNoP-00060s-2z; Wed, 23 Jul 2003 13:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNnd-0005yw-O7 for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 13:53:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21303; Wed, 23 Jul 2003 13:53:10 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNnb-0006UI-00; Wed, 23 Jul 2003 13:53:11 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19fNnQ-0006UE-00; Wed, 23 Jul 2003 13:53:00 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 4F9A56131D; Wed, 23 Jul 2003 19:52:21 +0200 (MET DST) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id E0F0919C48; Wed, 23 Jul 2003 19:52:20 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 8C39F19C47; Wed, 23 Jul 2003 19:52:20 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA13546; Wed, 23 Jul 2003 19:52:20 +0200 (MEST) To: "Phelan, Tom" Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 23 Jul 2003 19:43:04 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 23/07/2003 19:53:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Tom, you write: >The relevant difference, as far as this discussion goes, between recorded >and live media is that recorded media can be transmitted from the sender as >fast as the network allows (assuming buffering at the receiver). and then latter (still about recorded media): >So, in this scheme, the sender doesn't need to know the rate that TFRC has >determined, it simply always sends as fast as TFRC allows. 1) I am sorry but *from a network point of view* I dont see a difference between this and "download"? Except that to my knowledge all the products doing that use HTTP since it solves a rather large number of other problems at the same time! 2) Now *from a user point of view* "download" has a flavor usually called "progressive download" whereby the downloaded media file has a structure enabling to start playback before download is finished. In this mode usually the slide bar that the player uses to display the media time has 2 colors, one displaying the current time in the media, the other the *received* time in the media, if this second mark stays ahead of the first mark playback is un-interrupted, otherwise the player stops and displays a message such as "please wait, rebufferring". So I dont see either, from a user point of view, how different a behavior the case you describe would have? **************** I conclude about this use case of the DCCP blocking API you described, that it is not very attractive at all. Surely DCCP has better assets to lure implementers?-)... I think an API providing a target rate would be a good starting point;-) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 13:56:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21434 for ; Wed, 23 Jul 2003 13:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNqS-0006DZ-MR for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 13:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHu8Hj023895 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 13:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNqS-0006DB-J9 for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21411 for ; Wed, 23 Jul 2003 13:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNqQ-0006Vu-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 13:56:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fNqK-0006Vr-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 13:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNqM-0006Ch-9S; Wed, 23 Jul 2003 13:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNpz-000692-4V for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 13:55:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21405; Wed, 23 Jul 2003 13:55:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNpw-0006Vc-00; Wed, 23 Jul 2003 13:55:36 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19fNpl-0006VH-00; Wed, 23 Jul 2003 13:55:25 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Wed, 23 Jul 2003 10:54:47 -0700 From: Damon Lanphear To: "Phelan, Tom" Cc: "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB47D@sonusdc3.sonusnet.com> References: <4CF48720B6E9D4118D040060CF2074E9082BB47D@sonusdc3.sonusnet.com> Message-Id: <1058982715.6255.56.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 23 Jul 2003 10:51:55 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom, Thank you for providing better structure to our discussion. This is precisely what we needed to speak more precisely on these matters! I haven't been able to work out acceptable scenarios for the other two > applications yet. It seems almost certain to me that TFRC and a blocking > API is not at all suitable for two-way media. It might be suitable for > one-way live media, but I haven't figured out how it could be yet. If > anyone has ideas here I'd like to hear them :-). I'd like to understand the alternative to a blocking API for two-way media. I assume that in this case the application is responsible for managing the transmission rate. I guess I get confused when I consider that some agent in the pipeline will have to block transmission when the transmission attempt oversteps the congestion control rate. What does it matter if this agent is DCCP or the application, particularly if we have access to the transmit queue in DCCP, as is the case in the ICIR implementation ? As regards unidirectional live, its differs from unidirectional on-demand in that there's no data sitting on disk with which to fill a post-network buffer to a point where an up shift seems appropriate. Downshifts are straightforward, however, since under sending can just as well happen with live streams. So we need a metric for up shifts that does not rely on buffer state. Perhaps some measure of the stability of the available congestion controlled throughput over time? On Wed, 2003-07-23 at 07:43, Phelan, Tom wrote: > Hi Phillipe, > > In thinking about your draft on stream rate switching and this discussion on > APIs I've come to the conclusion that there are actually three different > applications being discussed, with three different sets of requirements. > One of these applications can be reasonably satisfied with a blocking API > (although there could be some efficiencies with other capabilities). For > the other two I'm not sure yet what would work. > > Excuse me if I'm re-inventing something here, but the three applications I > have in mind are: > o One-way pre-recorded media > o One-way live media > o Two-way interactive media > > The relevant difference, as far as this discussion goes, between recorded > and live media is that recorded media can be transmitted from the sender as > fast as the network allows (assuming buffering at the receiver). Live media > can only be transmitted at the rate that it's generated. > > The difference between one-way (live) and two-way is the size of the playout > buffer. In one-way media you can use a playout buffer that's hundreds of > times larger than the round trip time. In two-way media the playout buffer > is on the same order of magnitude as the round trip time. > > So, it seems to me that one-way pre-recorded media can be reasonably served > by DCCP with TFRC and a sockets-like (blocking) API. For example, assume > that the sender has a media stream in two bit rates, high and low. Also > assume that the sender is able to estimate the depth of the receiver's > playout buffer (either via feedback from the receiver or some other means). > Now set three thresholds in the playout buffer, a low threshold, a playback > start threshold and a high threshold, in order of increasing depth. > > To start the connection, the sender begins transmitting data from the high > bit rate stream as fast as TFRC allows (blocking the transmit thread for > rate control). Since TFRC is in slow-start, this is probably too slow > initially, but eventually the rate might increase to fast enough and past. > The receiver buffers data until the playback start threshold is reached, and > then begins playback. > > If the TFRC rate never gets fast enough, or a packet loss makes TFRC drop > the rate, the receiver will drain the playout buffer faster than it's being > filled. If the playout buffer drops below the low threshold, the sender > switches to the low bit rate stream. Assuming that the network has a little > bit more capacity than the low bit rate stream requires, the playout buffer > will begin filling again. > > When the buffer crosses the high threshold the sender switches to the high > bit rate stream. Assuming that the network still doesn't have enough > capacity for the high bit rate stream, the playout buffer will drain. When > it reaches the low threshold the sender switches back to the low bit rate. > The sender will oscillate back and forth like this until the connection is > terminated. > > So, in this scheme, the sender doesn't need to know the rate that TFRC has > determined, it simply always sends as fast as TFRC allows. TFRC shapes the > stream to the network's requirements, and the feedback about the playout > buffer allows the sender to shape the stream to the application's > requirements. > > > Tom P. > > > > -----Original Message----- > > From: philippe.gentric@philips.com > > [mailto:philippe.gentric@philips.com] > > Sent: Wednesday, July 23, 2003 7:59 AM > > To: Magnus Westerlund > > Cc: Damon Lanphear; dccp@ietf.org; mmusic@ietf.org > > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > > switching) > > > > > > > > Magnus,Damon, > > > > let us forget a minute about the exact application, > > (because my point is *not* specific to stream switching) > > let us instead concentrate on the following problem: > > > > you write: > > > > "the server can simply switch to a lower bit-rate" > > > > This is an indication we are on agreement on one thing: > > DCCP is about rate-driven applications. > > > > This is why my concern has been from the very start: > > how is the sending application (what ever it is) > > going to know what rate it must use? > > > > The answers you gave so far seem to indicate you are confident > > the application can "compute" such a rate based on the > > behavior of a blocking API... > > > > (ok, allow me now to *also* put aside my humble opinion that > > trying to achieve that is not a good idea) > > > > I advocate that it would be a shame **because the information > > is already available**! > > > > Allow me to quote Section 3 of RFC 3448: > > > > " Generally speaking, TFRC's congestion control mechanism works as > > follows: > > > > o The receiver measures the loss event rate and feeds this > > information back to the sender. > > > > o The sender also uses these feedback messages to measure the > > round-trip time (RTT). > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > equation, giving the acceptable transmit rate. > > > > o The sender then adjusts its transmit rate to match the > > calculated > > rate. > > " > > > > This seems to imply that a "natural" sender-side API for DCCP > > would explicitely > > inform the application ("sender") about this "acceptable > > transmit rate". > > > > It also happens to be the *best thing* that can be provided to > > an application designed to perform network adaptation. > > > > > > regards, > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > > > > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 14:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22499 for ; Wed, 23 Jul 2003 14:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOKU-0007SB-6t for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 14:27:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NIRA4I028646 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 14:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOKU-0007Rx-3i for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 14:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22482 for ; Wed, 23 Jul 2003 14:27:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fOKR-0006k8-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 14:27:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fOKL-0006k5-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 14:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOKL-0007QR-OB; Wed, 23 Jul 2003 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOKD-0007Q1-Ll for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 14:26:53 -0400 Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22475; Wed, 23 Jul 2003 14:26:49 -0400 (EDT) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 1D7775DEB9; Wed, 23 Jul 2003 20:21:36 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id C28D819C45; Wed, 23 Jul 2003 20:21:35 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id DDBFC19C47; Wed, 23 Jul 2003 20:21:33 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id UAA16337; Wed, 23 Jul 2003 20:21:33 +0200 (MEST) To: Damon Lanphear Cc: dccp@ietf.org, Magnus Westerlund , mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 23 Jul 2003 20:12:18 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 23/07/2003 20:22:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Damon, you write: >I assume that DCCP will pace data >to the lower layers at the rate required of the associated CCID spec. >For the application to do this pacing as well would be redundant work. I am assuming it is a *different job*, they live on different planets, the DCCP stack cares about "real seconds", the application cares about "media seconds". >What I don't quite understand about your position is the role played by >the application in pacing data. Do you maintain that the application >should pace data, or DCCP or both? Both, but differently? Streaming means that 1 second of content MUST be sent for every elapsed "real time" second (at least on the average). So the application cannot "pace seconds"... but I am assuming the application job contract does not say how many bytes one second of media is. In short I am assuming that the sending application can change the media data rate in order to *follow* the network data rate. For conferencing -the media being encoded in real time- I assume that the DCCP stack will be used to pilot the encoder (tell it which rate to produce). For pre-recorded media delivery the solution is stream switching (or download! see the other mail) For live "TV" (very large number of receivers) changing the rate is either not relevant (e.g. end to end SSM) or it uses a relay server which folds the issue as being like pre-recorded media playback -each receiver maintaining a private server connection- then one should use stream switching, each stream "flavor" being simultaneously produced by a different encoder. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: Magnus Westerlund dccp@ietf.org mmusic@ietf.org Damon Lanphear Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) Classification: 23/07/2003 19:42 Philippe, No one is really taking the position that a DCCP API should not make the transmission rate available to the application. This is quite a straightforward issue. DCCP can easily expose this key piece of information. I am more concerned with how an application meets DCCPs transmission limits (i.e. transmits at the required rate). Let's put the issue of adaptation aside for a moment and just concern ourselves with how an application paces data to the network. My view is that DCCP offers the application both congestion control AND the ability to manage the transmission schedule. I assume that DCCP will pace data to the lower layers at the rate required of the associated CCID spec. For the application to do this pacing as well would be redundant work. What I don't quite understand about your position is the role played by the application in pacing data. Do you maintain that the application should pace data, or DCCP or both? That is, is the use of the transmit rate to the application purely informative of a rate adaptation process, or of the transmit process as a whole? On Wed, 2003-07-23 at 04:59, philippe.gentric@philips.com wrote: > Magnus,Damon, > > let us forget a minute about the exact application, > (because my point is *not* specific to stream switching) > let us instead concentrate on the following problem: > > you write: > > "the server can simply switch to a lower bit-rate" > > This is an indication we are on agreement on one thing: > DCCP is about rate-driven applications. > > This is why my concern has been from the very start: > how is the sending application (what ever it is) > going to know what rate it must use? > > The answers you gave so far seem to indicate you are confident > the application can "compute" such a rate based on the behavior of a blocking API... > > (ok, allow me now to *also* put aside my humble opinion that trying to achieve that is not a good idea) > > I advocate that it would be a shame **because the information is already available**! > > Allow me to quote Section 3 of RFC 3448: > > " Generally speaking, TFRC's congestion control mechanism works as > follows: > > o The receiver measures the loss event rate and feeds this > information back to the sender. > > o The sender also uses these feedback messages to measure the > round-trip time (RTT). > > o The loss event rate and RTT are then fed into TFRC's throughput > equation, giving the acceptable transmit rate. > > o The sender then adjusts its transmit rate to match the calculated > rate. > " > > This seems to imply that a "natural" sender-side API for DCCP would explicitely > inform the application ("sender") about this "acceptable transmit rate". > > It also happens to be the *best thing* that can be provided to > an application designed to perform network adaptation. > > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 15:40:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28281 for ; Wed, 23 Jul 2003 15:40:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPSZ-0002bV-UP for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 15:39:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJdZ3F010005 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 15:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPSZ-0002bI-Q0 for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 15:39:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28235 for ; Wed, 23 Jul 2003 15:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPS0-0002Xb-Se; Wed, 23 Jul 2003 15:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPR9-0002Wp-58 for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 15:38:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28082; Wed, 23 Jul 2003 15:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fPR7-0007Yt-00; Wed, 23 Jul 2003 15:38:05 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19fPQw-0007Rr-00; Wed, 23 Jul 2003 15:37:54 -0400 Received: from ktalreja1.real.com ([::ffff:172.23.108.223]) (AUTH: LOGIN kamlesh) by capefear.real.com with esmtp; Wed, 23 Jul 2003 12:34:26 -0700 Message-Id: <5.1.0.14.2.20030723122352.023a1700@mailone.real.com> X-Sender: kamlesh@mailone.real.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 23 Jul 2003 12:32:05 -0700 To: Damon Lanphear , philippe.gentric@philips.com From: Kamlesh Talreja Subject: Re: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Cc: Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org In-Reply-To: <1058982128.6255.45.camel@poesis.dev.prognet.com> References: Mime-Version: 1.0 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 Without discounting the need to convey the transmission rate available to the application, we also need to point out the immediacy of a socket block, as opposed to an intermittent reading of the transmission rate. Since the transmission rate would be changing at a much finer granularity, and the congestion control mechanism would make sure the application does not exceed. If the application intends to exactly track the transmission rate changes, it would end up spending too much time as part of an out-of-band notification process. A blocking API allows the application to pace its delivery in an integrated manner without the overhead of asynchronous callbacks or other mechanisms to notify it continuously of transmission rate changes. However, to prevent the kind of oscillatory behavior that Tom talked about, the application could read the available transmission rate at a much less frequency to make sure that the media rate does not exceed the available throughput over a longer period of time. Kamlesh At 10:42 AM 7/23/2003 -0700, Damon Lanphear wrote: >Philippe, > >No one is really taking the position that a DCCP API should not make the >transmission rate available to the application. This is quite a >straightforward issue. DCCP can easily expose this key piece of >information. > >I am more concerned with how an application meets DCCPs transmission >limits (i.e. transmits at the required rate). > >Let's put the issue of adaptation aside for a moment and just concern >ourselves with how an application paces data to the network. My view is >that DCCP offers the application both congestion control AND the ability >to manage the transmission schedule. I assume that DCCP will pace data >to the lower layers at the rate required of the associated CCID spec. >For the application to do this pacing as well would be redundant work. > >What I don't quite understand about your position is the role played by >the application in pacing data. Do you maintain that the application >should pace data, or DCCP or both? That is, is the use of the transmit >rate to the application purely informative of a rate adaptation process, >or of the transmit process as a whole? > >On Wed, 2003-07-23 at 04:59, philippe.gentric@philips.com wrote: > > Magnus,Damon, > > > > let us forget a minute about the exact application, > > (because my point is *not* specific to stream switching) > > let us instead concentrate on the following problem: > > > > you write: > > > > "the server can simply switch to a lower bit-rate" > > > > This is an indication we are on agreement on one thing: > > DCCP is about rate-driven applications. > > > > This is why my concern has been from the very start: > > how is the sending application (what ever it is) > > going to know what rate it must use? > > > > The answers you gave so far seem to indicate you are confident > > the application can "compute" such a rate based on the behavior of a > blocking API... > > > > (ok, allow me now to *also* put aside my humble opinion that trying to > achieve that is not a good idea) > > > > I advocate that it would be a shame **because the information is > already available**! > > > > Allow me to quote Section 3 of RFC 3448: > > > > " Generally speaking, TFRC's congestion control mechanism works as > > follows: > > > > o The receiver measures the loss event rate and feeds this > > information back to the sender. > > > > o The sender also uses these feedback messages to measure the > > round-trip time (RTT). > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > equation, giving the acceptable transmit rate. > > > > o The sender then adjusts its transmit rate to match the calculated > > rate. > > " > > > > This seems to imply that a "natural" sender-side API for DCCP would > explicitely > > inform the application ("sender") about this "acceptable transmit rate". > > > > It also happens to be the *best thing* that can be provided to > > an application designed to perform network adaptation. > > > > > > regards, > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > >-- >Damon Lanphear > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kamlesh T. Talreja E-mail: kamlesh@real.com Software Development Engineer Phone: 206-892-6193 HelixServer Product Development RealNetworks, Inc. http://www.real.com/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 15:44:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28568 for ; Wed, 23 Jul 2003 15:44:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPWS-0002lf-UX for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 15:43:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJhaGe010633 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 15:43:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPWO-0002l8-HU for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 15:43:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28525 for ; Wed, 23 Jul 2003 15:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPVt-0002gV-Ka; Wed, 23 Jul 2003 15:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPVr-0002es-Vl for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 15:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28461; Wed, 23 Jul 2003 15:42:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fPVl-0007eS-00; Wed, 23 Jul 2003 15:42:53 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19fPVa-0007dE-00; Wed, 23 Jul 2003 15:42:42 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by flawless.real.com with esmtp; Wed, 23 Jul 2003 12:41:37 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: dccp@ietf.org, Magnus Westerlund , mmusic@ietf.org In-Reply-To: References: Message-Id: <1058989126.6254.92.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 23 Jul 2003 12:38:47 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-07-23 at 11:12, philippe.gentric@philips.com wrote: > Damon, you write: > > >I assume that DCCP will pace data > >to the lower layers at the rate required of the associated CCID spec. > >For the application to do this pacing as well would be redundant work. > > I am assuming it is a *different job*, they live on different planets, > the DCCP stack cares about "real seconds", > the application cares about "media seconds". I don't share that assumption. Probably because the domain in which I work is on-demand and unidirectional live media delivery. I view the delivery time line in terms of a rate. That rate is determined by the attributes of the session: the state of the network, and the state of the client side buffer. The media time line may shift relative to the transmission time line. So my application cares about "media seconds" only to the extent that it needs that information to know when and how to adapt. > >What I don't quite understand about your position is the role played by > >the application in pacing data. Do you maintain that the application > >should pace data, or DCCP or both? > > Both, but differently? > > Streaming means that 1 second of content MUST be sent for > every elapsed "real time" second (at least on the average). I don't agree with the MUST. It MAY if the congestion control will allow it. Or it may send more if the congestion control, session type (i.e. on-demand), and buffer state allows. Or it may send less if there is too much buffer stored up at the client. The application should be constantly adapting its transmission pattern to meet a broad set of requirements, that include congestion control. > So the application cannot "pace seconds"... > but I am assuming the application job contract > does not say how many bytes one second of media is. > > In short I am assuming that the sending application > can change the media data rate in order to > *follow* the network data rate. I agree. But how closely you want to follow the network rate is determined by the application type, and the state of the client buffer. Oscillating the transmission pattern with congestion control fluctuations can be a really bad thing for the user. > > For conferencing -the media being encoded in real time- > I assume that the DCCP stack will be used to pilot > the encoder (tell it which rate to produce). > For pre-recorded media delivery the solution is stream switching > (or download! see the other mail) > For live "TV" (very large number of receivers) changing > the rate is either not relevant (e.g. end to end SSM) > or it uses a relay server which folds the issue as being > like pre-recorded media playback -each receiver maintaining > a private server connection- then one should use stream switching, > each stream "flavor" being simultaneously produced by a different encoder. > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > cc: Magnus Westerlund > dccp@ietf.org > mmusic@ietf.org > Damon Lanphear Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) > > Classification: > 23/07/2003 19:42 > > > > > > > Philippe, > > No one is really taking the position that a DCCP API should not make the > transmission rate available to the application. This is quite a > straightforward issue. DCCP can easily expose this key piece of > information. > > I am more concerned with how an application meets DCCPs transmission > limits (i.e. transmits at the required rate). > > Let's put the issue of adaptation aside for a moment and just concern > ourselves with how an application paces data to the network. My view is > that DCCP offers the application both congestion control AND the ability > to manage the transmission schedule. I assume that DCCP will pace data > to the lower layers at the rate required of the associated CCID spec. > For the application to do this pacing as well would be redundant work. > > What I don't quite understand about your position is the role played by > the application in pacing data. Do you maintain that the application > should pace data, or DCCP or both? That is, is the use of the transmit > rate to the application purely informative of a rate adaptation process, > or of the transmit process as a whole? > > On Wed, 2003-07-23 at 04:59, philippe.gentric@philips.com wrote: > > Magnus,Damon, > > > > let us forget a minute about the exact application, > > (because my point is *not* specific to stream switching) > > let us instead concentrate on the following problem: > > > > you write: > > > > "the server can simply switch to a lower bit-rate" > > > > This is an indication we are on agreement on one thing: > > DCCP is about rate-driven applications. > > > > This is why my concern has been from the very start: > > how is the sending application (what ever it is) > > going to know what rate it must use? > > > > The answers you gave so far seem to indicate you are confident > > the application can "compute" such a rate based on the behavior of a blocking API... > > > > (ok, allow me now to *also* put aside my humble opinion that trying to achieve that is not a good idea) > > > > I advocate that it would be a shame **because the information is already available**! > > > > Allow me to quote Section 3 of RFC 3448: > > > > " Generally speaking, TFRC's congestion control mechanism works as > > follows: > > > > o The receiver measures the loss event rate and feeds this > > information back to the sender. > > > > o The sender also uses these feedback messages to measure the > > round-trip time (RTT). > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > equation, giving the acceptable transmit rate. > > > > o The sender then adjusts its transmit rate to match the calculated > > rate. > > " > > > > This seems to imply that a "natural" sender-side API for DCCP would explicitely > > inform the application ("sender") about this "acceptable transmit rate". > > > > It also happens to be the *best thing* that can be provided to > > an application designed to perform network adaptation. > > > > > > regards, > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > > -- > Damon Lanphear > > > > > -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 15:48:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28848 for ; Wed, 23 Jul 2003 15:48:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPaJ-000331-LV for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 15:47:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJlZB9011709 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 15:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPaJ-00032e-IF for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 15:47:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28801 for ; Wed, 23 Jul 2003 15:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPZl-0002wB-Ex; Wed, 23 Jul 2003 15:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPZN-0002uk-9r for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 15:46:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28747; Wed, 23 Jul 2003 15:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fPZL-0007it-00; Wed, 23 Jul 2003 15:46:35 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19fPZA-0007iP-00; Wed, 23 Jul 2003 15:46:24 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by flawless.real.com with esmtp; Wed, 23 Jul 2003 12:45:45 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: "Phelan, Tom" , dccp@ietf.org, mmusic@ietf.org In-Reply-To: References: Message-Id: <1058989375.6255.97.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 23 Jul 2003 12:42:55 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-07-23 at 10:43, philippe.gentric@philips.com wrote: > Hi Tom, > > you write: > > >The relevant difference, as far as this discussion goes, between recorded > >and live media is that recorded media can be transmitted from the sender as > >fast as the network allows (assuming buffering at the receiver). > > and then latter (still about recorded media): > > >So, in this scheme, the sender doesn't need to know the rate that TFRC has > >determined, it simply always sends as fast as TFRC allows. > > 1) I am sorry but *from a network point of view* > I dont see a difference between this and "download"? The only substantive difference is that the transmitted data may not be stored statically on the device in the case of streaming. So if you have a small embedded device, with limited storage, you can experience media from the network without having the cache the whole thing on the device. The problem then becomes one of balancing the use of device storage (i.e. client buffer management) and congestion control. > > Except that to my knowledge all the products doing that use HTTP > since it solves a rather large number of other problems at the same time! > > 2) Now *from a user point of view* > > "download" has a flavor usually called "progressive download" > whereby the downloaded media file has a structure enabling > to start playback before download is finished. > > In this mode usually the slide bar that the player > uses to display the media time has 2 colors, > one displaying the current time in the media, > the other the *received* time in the media, > if this second mark stays ahead of the first mark playback is un-interrupted, > otherwise the player stops and displays a message such as "please wait, rebufferring". > > So I dont see either, from a user point of view, > how different a behavior the case you describe would have? > > **************** > > I conclude about this use case of the DCCP blocking API you described, > that it is not very attractive at all. > > Surely DCCP has better assets to lure implementers?-)... > I think an API providing a target rate would be a good starting point;-) > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 23 19:24:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07745 for ; Wed, 23 Jul 2003 19:24:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSxs-0005QV-V1 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 19:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NNO8Dw020853 for mmusic-archive@odin.ietf.org; Wed, 23 Jul 2003 19:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSxs-0005QG-52 for mmusic-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 19:24:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07740 for ; Wed, 23 Jul 2003 19:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fSxq-0001gg-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 19:24:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fSxk-0001gd-00 for mmusic-web-archive@ietf.org; Wed, 23 Jul 2003 19:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSxk-0005Pj-Nz; Wed, 23 Jul 2003 19:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSxW-0005P9-0u for mmusic@optimus.ietf.org; Wed, 23 Jul 2003 19:23:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07722; Wed, 23 Jul 2003 19:23:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fSxT-0001gO-00; Wed, 23 Jul 2003 19:23:43 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19fSxI-0001g3-00; Wed, 23 Jul 2003 19:23:32 -0400 Received: from batman ([::ffff:172.23.106.42]) (TLS: TLSv1/SSLv3,128bits,RC4-MD5) by goodfellas.real.com with esmtp; Wed, 23 Jul 2003 16:22:28 -0700 From: "Sean Robinson" To: "Damon Lanphear" , "Phelan, Tom" Cc: philippe.gentric@philips.com, "Magnus Westerlund" , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Subject: RE: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Date: Wed, 23 Jul 2003 16:22:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1058982715.6255.56.camel@poesis.dev.prognet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that Tom's contribution has provided a good basis for this discussion. The decision is further complicated by the inclusion of media composition. Consider we following media availablity constraints (which can be applied to each of the named media application, On demand, live and 2-way) - A single fixed rate media source - multiple discrete media encodings - a fully scalable media encoding (such as MPEG-4 FGS) Now, given that in the second case we could add as many rates as we desire and that the third case doesn't really exist (no codec is infitely scalable), we can treat these as the same for the purposes of this discussion. We can view this from the application level as a series of decision points in which the application concludes the best media data to send at a given moment given the current network conditions. The design of the media is obviously a critical factor in the succcess of the application as some media may work better in some application than others. It is assumed that low latency applicaiton will require more frequent decision points where an on-demand application may require fewer. We can think of the media transmitted between these decision points as a media unit. Here I would like to bring up a point that I feel has been neglected in the discussion to this point. That is the perspective of resource efficiency in the interaction between a user level media application and a kernel level protocol. From this perspective the frequency of interaction between the two sides should be minimized. Also we would further hope that the need for user level packet scheduling would also be minimized. If the 2 above points are agreed to, we can then conclude that in the ideal case we would want the interaction with the protocol to match as closely as possible with those media decision points. In other words, the application should only have to interact with the dataflow when there is some meaningful action to be taken. This seems to me to be the best method for evaluation of an API semantic. First, let's take the simple blocking semantic. The first question we should ask (which is not specified in the DCCP user manual) is what triggers that the block has cleared? If we take the naive assumption that the file descriptor is cleared for writing after the transmission of each datagram, then our interaction with the protocol will also be on every datagram (if we are instantly responsive to the signal). This is likely more than we would like in all but the very most scalable solutions. Keep in mind, however, that flow control through file descriptors is a well supported concept throughout different OSes and this is very attractive in the design of a protocol. Further, if we define parameters for when the desriptor is marked for writing we can get greater control over its scalability. It should also be noted that this mechanism is not really optional, since the prtocol must support blocking when the pre-netwqork buffer is full. Now the rate-signalling approach has also been proposed, but it implies a network-driven scheduling model over a media-driven model. TFRC will generate a new throughput claculation once per round trip time and if this is the frequency at which the rate would be signalled, then we could either find this to be too frequent or too sparse depending on the underlying network. Certainly an agrument could be made, media decision points should be syncronized with network condition and if this is possible, this is a more attractive solution. It is important to note, however, that at a fine grained level over delivery rate is not that relevant to the delivery characteristcs, but rather the data size of individual media units. So, if TFRC reports 20kbs at a given window, it doesn't necesicearily mean that the application should choose the 20kbs stream, but should evaluate the data to be transmitted for available streams at that decision point. Another option outside of direct feedback would be a polling approach, whereby the application set interupt timers to evaluate the dataflow at appropriate points in the application. This method could work well in stuations in which the throughput has a low degree of variance, since the evaluation interval could be tailored to the desired media. As the variance increases, the effectiveness of this approach decreases since the data in the pre-network queue may be delivered faster or slower than expected, causing an increased number of "wasted" check in which no action is taken. Another approach could be to tag specific datagrams for signalling on transmission. Then DCCP would signal (using some means) when a given datagram is transmitted. If one datagram per media unit, then we could get a notification at every media unit, which is what we want. The semantics of defining this within an API could be quite complex, however. Which brings me to a final important point. As mentioned in several points, we must consider the method in which the information is signalled. Some OSes have more advanced signalling mechanism than others and the more digression from standard mechanisms, the less integrated into the OS the protocol becomes. This is an extremely imprrtant factor in this discussion and should not be treated likely. S > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Damon Lanphear > Sent: Wednesday, July 23, 2003 10:52 AM > To: Phelan, Tom > Cc: 'philippe.gentric@philips.com'; Magnus Westerlund; dccp@ietf.org; > mmusic@ietf.org; Pasco Anderson, Jay > Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream > switching) > > > Tom, > > Thank you for providing better structure to our discussion. This is > precisely what we needed to speak more precisely on these matters! > > I haven't been able to work out acceptable scenarios for the other two > > applications yet. It seems almost certain to me that TFRC and > a blocking > > API is not at all suitable for two-way media. It might be suitable for > > one-way live media, but I haven't figured out how it could be yet. If > > anyone has ideas here I'd like to hear them :-). > > I'd like to understand the alternative to a blocking API for two-way > media. I assume that in this case the application is responsible for > managing the transmission rate. I guess I get confused when I consider > that some agent in the pipeline will have to block transmission when the > transmission attempt oversteps the congestion control rate. What does > it matter if this agent is DCCP or the application, particularly if we > have access to the transmit queue in DCCP, as is the case in the ICIR > implementation ? > > As regards unidirectional live, its differs from unidirectional > on-demand in that there's no data sitting on disk with which to fill a > post-network buffer to a point where an up shift seems appropriate. > Downshifts are straightforward, however, since under sending can just as > well happen with live streams. So we need a metric for up shifts that > does not rely on buffer state. Perhaps some measure of the stability of > the available congestion controlled throughput over time? > > On Wed, 2003-07-23 at 07:43, Phelan, Tom wrote: > > Hi Phillipe, > > > > In thinking about your draft on stream rate switching and this > discussion on > > APIs I've come to the conclusion that there are actually three different > > applications being discussed, with three different sets of requirements. > > One of these applications can be reasonably satisfied with a > blocking API > > (although there could be some efficiencies with other > capabilities). For > > the other two I'm not sure yet what would work. > > > > Excuse me if I'm re-inventing something here, but the three > applications I > > have in mind are: > > o One-way pre-recorded media > > o One-way live media > > o Two-way interactive media > > > > The relevant difference, as far as this discussion goes, > between recorded > > and live media is that recorded media can be transmitted from > the sender as > > fast as the network allows (assuming buffering at the > receiver). Live media > > can only be transmitted at the rate that it's generated. > > > > The difference between one-way (live) and two-way is the size > of the playout > > buffer. In one-way media you can use a playout buffer that's > hundreds of > > times larger than the round trip time. In two-way media the > playout buffer > > is on the same order of magnitude as the round trip time. > > > > So, it seems to me that one-way pre-recorded media can be > reasonably served > > by DCCP with TFRC and a sockets-like (blocking) API. For > example, assume > > that the sender has a media stream in two bit rates, high and low. Also > > assume that the sender is able to estimate the depth of the receiver's > > playout buffer (either via feedback from the receiver or some > other means). > > Now set three thresholds in the playout buffer, a low > threshold, a playback > > start threshold and a high threshold, in order of increasing depth. > > > > To start the connection, the sender begins transmitting data > from the high > > bit rate stream as fast as TFRC allows (blocking the transmit thread for > > rate control). Since TFRC is in slow-start, this is probably too slow > > initially, but eventually the rate might increase to fast > enough and past. > > The receiver buffers data until the playback start threshold is > reached, and > > then begins playback. > > > > If the TFRC rate never gets fast enough, or a packet loss makes > TFRC drop > > the rate, the receiver will drain the playout buffer faster > than it's being > > filled. If the playout buffer drops below the low threshold, the sender > > switches to the low bit rate stream. Assuming that the network > has a little > > bit more capacity than the low bit rate stream requires, the > playout buffer > > will begin filling again. > > > > When the buffer crosses the high threshold the sender switches > to the high > > bit rate stream. Assuming that the network still doesn't have enough > > capacity for the high bit rate stream, the playout buffer will > drain. When > > it reaches the low threshold the sender switches back to the > low bit rate. > > The sender will oscillate back and forth like this until the > connection is > > terminated. > > > > So, in this scheme, the sender doesn't need to know the rate > that TFRC has > > determined, it simply always sends as fast as TFRC allows. > TFRC shapes the > > stream to the network's requirements, and the feedback about the playout > > buffer allows the sender to shape the stream to the application's > > requirements. > > > > > > > Tom P. > > > > > > > -----Original Message----- > > > From: philippe.gentric@philips.com > > > [mailto:philippe.gentric@philips.com] > > > Sent: Wednesday, July 23, 2003 7:59 AM > > > To: Magnus Westerlund > > > Cc: Damon Lanphear; dccp@ietf.org; mmusic@ietf.org > > > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > > > switching) > > > > > > > > > > > > Magnus,Damon, > > > > > > let us forget a minute about the exact application, > > > (because my point is *not* specific to stream switching) > > > let us instead concentrate on the following problem: > > > > > > you write: > > > > > > "the server can simply switch to a lower bit-rate" > > > > > > This is an indication we are on agreement on one thing: > > > DCCP is about rate-driven applications. > > > > > > This is why my concern has been from the very start: > > > how is the sending application (what ever it is) > > > going to know what rate it must use? > > > > > > The answers you gave so far seem to indicate you are confident > > > the application can "compute" such a rate based on the > > > behavior of a blocking API... > > > > > > (ok, allow me now to *also* put aside my humble opinion that > > > trying to achieve that is not a good idea) > > > > > > I advocate that it would be a shame **because the information > > > is already available**! > > > > > > Allow me to quote Section 3 of RFC 3448: > > > > > > " Generally speaking, TFRC's congestion control mechanism works as > > > follows: > > > > > > o The receiver measures the loss event rate and feeds this > > > information back to the sender. > > > > > > o The sender also uses these feedback messages to measure the > > > round-trip time (RTT). > > > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > > equation, giving the acceptable transmit rate. > > > > > > o The sender then adjusts its transmit rate to match the > > > calculated > > > rate. > > > " > > > > > > This seems to imply that a "natural" sender-side API for DCCP > > > would explicitely > > > inform the application ("sender") about this "acceptable > > > transmit rate". > > > > > > It also happens to be the *best thing* that can be provided to > > > an application designed to perform network adaptation. > > > > > > > > > regards, > > > > > > Philippe Gentric > > > Software Architect > > > Philips MP4Net > > > philippe.gentric@philips.com > > > http://www.platform4.philips.com > > > > > > > > > > > > _______________________________________________ > > > dccp IETF mailing list: dccp@ietf.org > > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > -- > Damon Lanphear > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 10:05:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07063 for ; Thu, 24 Jul 2003 10:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgiJ-0006bu-UB for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 10:05:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OE4xGq025392 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 10:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgiJ-0006bP-P8 for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 10:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06972 for ; Thu, 24 Jul 2003 10:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgiH-0006F8-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 10:04:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fgiB-0006F2-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 10:04:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fghM-0006Sl-R2; Thu, 24 Jul 2003 10:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fggR-0006Rk-Kq for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 10:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06776; Thu, 24 Jul 2003 10:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fggP-0006EF-00; Thu, 24 Jul 2003 10:03:01 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19fggE-0006E9-00; Thu, 24 Jul 2003 10:02:50 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6OE29D7015025; Thu, 24 Jul 2003 10:02:09 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 10:02:06 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 10:02:05 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB481@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Damon Lanphear'" , "Phelan, Tom" Cc: "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Date: Thu, 24 Jul 2003 10:02:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Damon, See inline ... Tom P. > -----Original Message----- > From: Damon Lanphear [mailto:damonlan@real.com] > Sent: Wednesday, July 23, 2003 1:52 PM > To: Phelan, Tom > Cc: 'philippe.gentric@philips.com'; Magnus Westerlund; dccp@ietf.org; > mmusic@ietf.org; Pasco Anderson, Jay > Subject: RE: [dccp] natural DCCP sender-side API: (was stream > switching) > > > Tom, > > Thank you for providing better structure to our discussion. This is > precisely what we needed to speak more precisely on these matters! Thanks :-). > > I haven't been able to work out acceptable scenarios for the other two > > applications yet. It seems almost certain to me that TFRC > and a blocking > > API is not at all suitable for two-way media. It might be > suitable for > > one-way live media, but I haven't figured out how it could > be yet. If > > anyone has ideas here I'd like to hear them :-). > > I'd like to understand the alternative to a blocking API for two-way > media. I assume that in this case the application is responsible for > managing the transmission rate. I guess I get confused when > I consider > that some agent in the pipeline will have to block > transmission when the > transmission attempt oversteps the congestion control rate. What does > it matter if this agent is DCCP or the application, particularly if we > have access to the transmit queue in DCCP, as is the case in the ICIR > implementation ? Actually, my big worry here is TFRC, not the API. I'm baffled about how to map slow start plus mostly smooth changes but occasional abrupt changes and a small playout buffer into something workable. Another thing that concerns me (touched on in the paragraph above) is the disconnect between a transport protocol making rate decisions and an application making rate decisions. It seems to me that these particular applications are much better equipped to make the rate decisions - they know about what is possible. It also seems that the application can make at least as good a decision about what constitutes network congestion. The app will need feedback about the playout buffer state, and this is largely redundant with the DCCP acks. If the app is making rate decisions and detecting network congestion, what do we need DCCP for? > > As regards unidirectional live, its differs from unidirectional > on-demand in that there's no data sitting on disk with which to fill a > post-network buffer to a point where an up shift seems appropriate. > Downshifts are straightforward, however, since under sending > can just as > well happen with live streams. So we need a metric for up shifts that > does not rely on buffer state. Perhaps some measure of the > stability of > the available congestion controlled throughput over time? Yes, this is a problem - downshifts are straightforward, but under what conditions do you upshift? If your playout buffer is being depleted you can downshift at some threshold and stop the depletion. The problem is that your playout buffer will never get re-filled, and you're now stuck at the lower level. If you upshift and things go bad again, the playout buffer will go to an even lower level. Enough of these shifts and the playout buffer will run out - even if you could have maintained things at the lower bit rate. > > On Wed, 2003-07-23 at 07:43, Phelan, Tom wrote: > > Hi Phillipe, > > > > In thinking about your draft on stream rate switching and > this discussion on > > APIs I've come to the conclusion that there are actually > three different > > applications being discussed, with three different sets of > requirements. > > One of these applications can be reasonably satisfied with > a blocking API > > (although there could be some efficiencies with other > capabilities). For > > the other two I'm not sure yet what would work. > > > > Excuse me if I'm re-inventing something here, but the three > applications I > > have in mind are: > > o One-way pre-recorded media > > o One-way live media > > o Two-way interactive media > > > > The relevant difference, as far as this discussion goes, > between recorded > > and live media is that recorded media can be transmitted > from the sender as > > fast as the network allows (assuming buffering at the > receiver). Live media > > can only be transmitted at the rate that it's generated. > > > > The difference between one-way (live) and two-way is the > size of the playout > > buffer. In one-way media you can use a playout buffer > that's hundreds of > > times larger than the round trip time. In two-way media > the playout buffer > > is on the same order of magnitude as the round trip time. > > > > So, it seems to me that one-way pre-recorded media can be > reasonably served > > by DCCP with TFRC and a sockets-like (blocking) API. For > example, assume > > that the sender has a media stream in two bit rates, high > and low. Also > > assume that the sender is able to estimate the depth of the > receiver's > > playout buffer (either via feedback from the receiver or > some other means). > > Now set three thresholds in the playout buffer, a low > threshold, a playback > > start threshold and a high threshold, in order of increasing depth. > > > > To start the connection, the sender begins transmitting > data from the high > > bit rate stream as fast as TFRC allows (blocking the > transmit thread for > > rate control). Since TFRC is in slow-start, this is > probably too slow > > initially, but eventually the rate might increase to fast > enough and past. > > The receiver buffers data until the playback start > threshold is reached, and > > then begins playback. > > > > If the TFRC rate never gets fast enough, or a packet loss > makes TFRC drop > > the rate, the receiver will drain the playout buffer faster > than it's being > > filled. If the playout buffer drops below the low > threshold, the sender > > switches to the low bit rate stream. Assuming that the > network has a little > > bit more capacity than the low bit rate stream requires, > the playout buffer > > will begin filling again. > > > > When the buffer crosses the high threshold the sender > switches to the high > > bit rate stream. Assuming that the network still doesn't > have enough > > capacity for the high bit rate stream, the playout buffer > will drain. When > > it reaches the low threshold the sender switches back to > the low bit rate. > > The sender will oscillate back and forth like this until > the connection is > > terminated. > > > > So, in this scheme, the sender doesn't need to know the > rate that TFRC has > > determined, it simply always sends as fast as TFRC allows. > TFRC shapes the > > stream to the network's requirements, and the feedback > about the playout > > buffer allows the sender to shape the stream to the application's > > requirements. > > > > > > > Tom P. > > > > > > > -----Original Message----- > > > From: philippe.gentric@philips.com > > > [mailto:philippe.gentric@philips.com] > > > Sent: Wednesday, July 23, 2003 7:59 AM > > > To: Magnus Westerlund > > > Cc: Damon Lanphear; dccp@ietf.org; mmusic@ietf.org > > > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > > > switching) > > > > > > > > > > > > Magnus,Damon, > > > > > > let us forget a minute about the exact application, > > > (because my point is *not* specific to stream switching) > > > let us instead concentrate on the following problem: > > > > > > you write: > > > > > > "the server can simply switch to a lower bit-rate" > > > > > > This is an indication we are on agreement on one thing: > > > DCCP is about rate-driven applications. > > > > > > This is why my concern has been from the very start: > > > how is the sending application (what ever it is) > > > going to know what rate it must use? > > > > > > The answers you gave so far seem to indicate you are confident > > > the application can "compute" such a rate based on the > > > behavior of a blocking API... > > > > > > (ok, allow me now to *also* put aside my humble opinion that > > > trying to achieve that is not a good idea) > > > > > > I advocate that it would be a shame **because the information > > > is already available**! > > > > > > Allow me to quote Section 3 of RFC 3448: > > > > > > " Generally speaking, TFRC's congestion control > mechanism works as > > > follows: > > > > > > o The receiver measures the loss event rate and feeds this > > > information back to the sender. > > > > > > o The sender also uses these feedback messages to measure the > > > round-trip time (RTT). > > > > > > o The loss event rate and RTT are then fed into > TFRC's throughput > > > equation, giving the acceptable transmit rate. > > > > > > o The sender then adjusts its transmit rate to match the > > > calculated > > > rate. > > > " > > > > > > This seems to imply that a "natural" sender-side API for DCCP > > > would explicitely > > > inform the application ("sender") about this "acceptable > > > transmit rate". > > > > > > It also happens to be the *best thing* that can be provided to > > > an application designed to perform network adaptation. > > > > > > > > > regards, > > > > > > Philippe Gentric > > > Software Architect > > > Philips MP4Net > > > philippe.gentric@philips.com > > > http://www.platform4.philips.com > > > > > > > > > > > > _______________________________________________ > > > dccp IETF mailing list: dccp@ietf.org > > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > -- > Damon Lanphear > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 10:11:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08001 for ; Thu, 24 Jul 2003 10:11:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgoN-0007cr-1h for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 10:11:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OEBFke029309 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 10:11:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgoL-0007cM-I8 for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 10:11:13 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07902 for ; Thu, 24 Jul 2003 10:11:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgnC-0007OZ-SN; Thu, 24 Jul 2003 10:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgn8-0007NT-EC for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 10:09:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07721; Thu, 24 Jul 2003 10:09:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgn5-0006Iu-00; Thu, 24 Jul 2003 10:09:55 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19fgmj-0006H3-00; Thu, 24 Jul 2003 10:09:33 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6OE8TD7015420; Thu, 24 Jul 2003 10:08:29 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 10:08:27 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 10:08:25 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB482@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" , "Phelan, Tom" Cc: dccp@ietf.org, mmusic@ietf.org Date: Thu, 24 Jul 2003 10:08:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Phillipe, From your point below - I don't see much difference between this (one-way pre-recorded media) and file download either. Just that in "normal" file download it wouldn't be reasonable to consider changing the encoding scheme in mid-transfer in order to keep up with some real-time considerations. Note that to simplify things, my discussion assumed that the receiver could buffer the entire program if it needed to. I think it would be pretty easy to extend the scheme to handle receivers that couldn't buffer the whole program. Something like a fourth buffer threshold that if hit causes the sender to pause for a short time ... Tom P. > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Wednesday, July 23, 2003 1:43 PM > To: Phelan, Tom > Cc: dccp@ietf.org; mmusic@ietf.org > Subject: RE: [dccp] natural DCCP sender-side API: (was stream > switching) > > > Hi Tom, > > you write: > > >The relevant difference, as far as this discussion goes, > between recorded > >and live media is that recorded media can be transmitted > from the sender as > >fast as the network allows (assuming buffering at the receiver). > > and then latter (still about recorded media): > > >So, in this scheme, the sender doesn't need to know the rate > that TFRC has > >determined, it simply always sends as fast as TFRC allows. > > 1) I am sorry but *from a network point of view* > I dont see a difference between this and "download"? > > Except that to my knowledge all the products doing that use HTTP > since it solves a rather large number of other problems at > the same time! > > 2) Now *from a user point of view* > > "download" has a flavor usually called "progressive download" > whereby the downloaded media file has a structure enabling > to start playback before download is finished. > > In this mode usually the slide bar that the player > uses to display the media time has 2 colors, > one displaying the current time in the media, > the other the *received* time in the media, > if this second mark stays ahead of the first mark playback is > un-interrupted, > otherwise the player stops and displays a message such as > "please wait, rebufferring". > > So I dont see either, from a user point of view, > how different a behavior the case you describe would have? > > **************** > > I conclude about this use case of the DCCP blocking API you described, > that it is not very attractive at all. > > Surely DCCP has better assets to lure implementers?-)... > I think an API providing a target rate would be a good > starting point;-) > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 11:05:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10168 for ; Thu, 24 Jul 2003 11:05:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fheI-0002oM-Iq for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 11:04:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OF4sGJ010802 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 11:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fheG-0002o4-QX for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 11:04:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10133 for ; Thu, 24 Jul 2003 11:04:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fheD-0006k1-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 11:04:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fhe8-0006jp-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 11:04:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhdR-0002ec-AZ; Thu, 24 Jul 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhcY-0002as-0j for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 11:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10072; Thu, 24 Jul 2003 11:02:54 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fhcQ-0006id-00; Thu, 24 Jul 2003 11:02:58 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19fhcF-0006iB-00; Thu, 24 Jul 2003 11:02:47 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 3271D54F21; Thu, 24 Jul 2003 17:02:22 +0200 (MET DST) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id A550319C46; Thu, 24 Jul 2003 17:02:21 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 3AB4519C49; Thu, 24 Jul 2003 17:02:21 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA19555; Thu, 24 Jul 2003 17:02:20 +0200 (MEST) To: Damon Lanphear Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 24 Jul 2003 16:52:49 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 24/07/2003 17:03:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Damon, you write: >I view the >delivery time line in terms of a rate. That rate is determined by the >attributes of the session: the state of the network, and the state of >the client side buffer. Why do you want to monitor the receiver buffers? I though there was only 3 possibilities corresponding to the 3 protocols: A) you dont care about "streaming" i.e. about "sending media in real time" and then you should use HTTP progressive download (TCP) and monitor the buffer because it may run dry. or B) You stream "old fashion" i.e. push data into the network irrespective of the network status (UDP) and monitor the buffer because it may run dry. or C) you use DCCP and then your application should simply follow the rate indicated by DCCP because *if* the sender follows the rate indicated by DCCP then it *does not need* to monitor the client side buffers since the data will arrive on time thanks to DCCP and therefore the client buffers will always contain the same amount of media time... and playback will always be smooth. is not this what DCCP is all about? >The media time line may shift relative to the transmission time line you mean on purpose or jitter? regards Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: dccp@ietf.org Magnus Westerlund mmusic@ietf.org Damon Lanphear Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) Classification: Sent by: dccp-admin@ietf.org 23/07/2003 21:38 On Wed, 2003-07-23 at 11:12, philippe.gentric@philips.com wrote: > Damon, you write: > > >I assume that DCCP will pace data > >to the lower layers at the rate required of the associated CCID spec. > >For the application to do this pacing as well would be redundant work. > > I am assuming it is a *different job*, they live on different planets, > the DCCP stack cares about "real seconds", > the application cares about "media seconds". I don't share that assumption. Probably because the domain in which I work is on-demand and unidirectional live media delivery. I view the delivery time line in terms of a rate. That rate is determined by the attributes of the session: the state of the network, and the state of the client side buffer. The media time line may shift relative to the transmission time line. So my application cares about "media seconds" only to the extent that it needs that information to know when and how to adapt. > >What I don't quite understand about your position is the role played by > >the application in pacing data. Do you maintain that the application > >should pace data, or DCCP or both? > > Both, but differently? > > Streaming means that 1 second of content MUST be sent for > every elapsed "real time" second (at least on the average). I don't agree with the MUST. It MAY if the congestion control will allow it. Or it may send more if the congestion control, session type (i.e. on-demand), and buffer state allows. Or it may send less if there is too much buffer stored up at the client. The application should be constantly adapting its transmission pattern to meet a broad set of requirements, that include congestion control. > So the application cannot "pace seconds"... > but I am assuming the application job contract > does not say how many bytes one second of media is. > > In short I am assuming that the sending application > can change the media data rate in order to > *follow* the network data rate. I agree. But how closely you want to follow the network rate is determined by the application type, and the state of the client buffer. Oscillating the transmission pattern with congestion control fluctuations can be a really bad thing for the user. > > For conferencing -the media being encoded in real time- > I assume that the DCCP stack will be used to pilot > the encoder (tell it which rate to produce). > For pre-recorded media delivery the solution is stream switching > (or download! see the other mail) > For live "TV" (very large number of receivers) changing > the rate is either not relevant (e.g. end to end SSM) > or it uses a relay server which folds the issue as being > like pre-recorded media playback -each receiver maintaining > a private server connection- then one should use stream switching, > each stream "flavor" being simultaneously produced by a different encoder. > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > cc: Magnus Westerlund > dccp@ietf.org > mmusic@ietf.org > Damon Lanphear Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) > > Classification: > 23/07/2003 19:42 > > > > > > > Philippe, > > No one is really taking the position that a DCCP API should not make the > transmission rate available to the application. This is quite a > straightforward issue. DCCP can easily expose this key piece of > information. > > I am more concerned with how an application meets DCCPs transmission > limits (i.e. transmits at the required rate). > > Let's put the issue of adaptation aside for a moment and just concern > ourselves with how an application paces data to the network. My view is > that DCCP offers the application both congestion control AND the ability > to manage the transmission schedule. I assume that DCCP will pace data > to the lower layers at the rate required of the associated CCID spec. > For the application to do this pacing as well would be redundant work. > > What I don't quite understand about your position is the role played by > the application in pacing data. Do you maintain that the application > should pace data, or DCCP or both? That is, is the use of the transmit > rate to the application purely informative of a rate adaptation process, > or of the transmit process as a whole? > > On Wed, 2003-07-23 at 04:59, philippe.gentric@philips.com wrote: > > Magnus,Damon, > > > > let us forget a minute about the exact application, > > (because my point is *not* specific to stream switching) > > let us instead concentrate on the following problem: > > > > you write: > > > > "the server can simply switch to a lower bit-rate" > > > > This is an indication we are on agreement on one thing: > > DCCP is about rate-driven applications. > > > > This is why my concern has been from the very start: > > how is the sending application (what ever it is) > > going to know what rate it must use? > > > > The answers you gave so far seem to indicate you are confident > > the application can "compute" such a rate based on the behavior of a blocking API... > > > > (ok, allow me now to *also* put aside my humble opinion that trying to achieve that is not a good idea) > > > > I advocate that it would be a shame **because the information is already available**! > > > > Allow me to quote Section 3 of RFC 3448: > > > > " Generally speaking, TFRC's congestion control mechanism works as > > follows: > > > > o The receiver measures the loss event rate and feeds this > > information back to the sender. > > > > o The sender also uses these feedback messages to measure the > > round-trip time (RTT). > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > equation, giving the acceptable transmit rate. > > > > o The sender then adjusts its transmit rate to match the calculated > > rate. > > " > > > > This seems to imply that a "natural" sender-side API for DCCP would explicitely > > inform the application ("sender") about this "acceptable transmit rate". > > > > It also happens to be the *best thing* that can be provided to > > an application designed to perform network adaptation. > > > > > > regards, > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > > -- > Damon Lanphear > > > > > -- Damon Lanphear _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 11:11:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10451 for ; Thu, 24 Jul 2003 11:11:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhj7-0003OP-1C for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 11:09:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OF9q6e013035 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 11:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhj5-0003O8-Gm for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 11:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10348 for ; Thu, 24 Jul 2003 11:09:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fhj2-0006mx-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 11:09:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fhiw-0006mu-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 11:09:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhiH-0003Eq-45; Thu, 24 Jul 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhhS-0003D8-Bg for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 11:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10268; Thu, 24 Jul 2003 11:07:59 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fhhL-0006lf-00; Thu, 24 Jul 2003 11:08:03 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19fhhA-0006lW-00; Thu, 24 Jul 2003 11:07:52 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 13DFF550DF; Thu, 24 Jul 2003 17:07:45 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id AFEE319C48; Thu, 24 Jul 2003 17:07:44 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 5E75D19C46; Thu, 24 Jul 2003 17:07:44 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA21854; Thu, 24 Jul 2003 17:07:43 +0200 (MEST) Subject: Re: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) To: Damon Lanphear Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 24 Jul 2003 16:58:12 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 24/07/2003 17:08:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Damon, >> >So, in this scheme, the sender doesn't need to know the rate that TFRC has >> >determined, it simply always sends as fast as TFRC allows. >> >> 1) I am sorry but *from a network point of view* >> I dont see a difference between this and "download"? > >The only substantive difference is that the transmitted data may not be >stored statically on the device in the case of streaming. So if you >have a small embedded device, with limited storage, you can experience >media from the network without having the cache the whole thing on the >device. with progressive download if you have no room for storage you can garbage media as soon as it is decoded as well ... and slow down the sender if needed too ... regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: "Phelan, Tom" dccp@ietf.org mmusic@ietf.org Damon Lanphear Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sent by: Classification: mmusic-admin@ietf.org 23/07/2003 21:42 On Wed, 2003-07-23 at 10:43, philippe.gentric@philips.com wrote: > Hi Tom, > > you write: > > >The relevant difference, as far as this discussion goes, between recorded > >and live media is that recorded media can be transmitted from the sender as > >fast as the network allows (assuming buffering at the receiver). > > and then latter (still about recorded media): > > >So, in this scheme, the sender doesn't need to know the rate that TFRC has > >determined, it simply always sends as fast as TFRC allows. > > 1) I am sorry but *from a network point of view* > I dont see a difference between this and "download"? The only substantive difference is that the transmitted data may not be stored statically on the device in the case of streaming. So if you have a small embedded device, with limited storage, you can experience media from the network without having the cache the whole thing on the device. The problem then becomes one of balancing the use of device storage (i.e. client buffer management) and congestion control. > > Except that to my knowledge all the products doing that use HTTP > since it solves a rather large number of other problems at the same time! > > 2) Now *from a user point of view* > > "download" has a flavor usually called "progressive download" > whereby the downloaded media file has a structure enabling > to start playback before download is finished. > > In this mode usually the slide bar that the player > uses to display the media time has 2 colors, > one displaying the current time in the media, > the other the *received* time in the media, > if this second mark stays ahead of the first mark playback is un-interrupted, > otherwise the player stops and displays a message such as "please wait, rebufferring". > > So I dont see either, from a user point of view, > how different a behavior the case you describe would have? > > **************** > > I conclude about this use case of the DCCP blocking API you described, > that it is not very attractive at all. > > Surely DCCP has better assets to lure implementers?-)... > I think an API providing a target rate would be a good starting point;-) > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 11:38:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11204 for ; Thu, 24 Jul 2003 11:38:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fiA9-0004gt-Cb for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 11:37:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OFbnEA018025 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 11:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fiA9-0004gC-7T for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 11:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11188 for ; Thu, 24 Jul 2003 11:37:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fiA7-0006xf-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 11:37:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fiA2-0006xc-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 11:37:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fi9O-0004L0-0Z; Thu, 24 Jul 2003 11:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fi8c-0004K5-Py for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 11:36:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11165; Thu, 24 Jul 2003 11:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fi8Z-0006x6-00; Thu, 24 Jul 2003 11:36:11 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19fi8O-0006wz-00; Thu, 24 Jul 2003 11:36:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24606; Thu, 24 Jul 2003 11:35:07 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07672; Thu, 24 Jul 2003 11:35:07 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MZZGF>; Thu, 24 Jul 2003 11:35:07 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C47@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mark Handley'" , "Phelan, Tom" Cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Date: Thu, 24 Jul 2003 11:35:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , As someone who is presently making such a videophone, let me add just a couple of details, as I think Mark's observations are very close to what we need. Most video codecs cannot quickly change their encoding rates, and they often encounter a glitch when they do. Many are based on hardware implementations in the encoder which force you to stop the encoder, change a bunch of settings, and restart it. It's possible, and we'll do it, but not very often, please. Second, we have found that delay is not just a problem, it is a cliff. If you go over 150 ms or so, you fall off the cliff. The difference between, say 250 ms and 500 ms is about 2 orders of magnitude less that the difference between 150 ms and 200 ms (there is in fact some variation, because it's a human response thing, 150 ms is something like a 95% point for detecting delay). These are one way delays, and, as an aside, are actually a limit for the audio, but are determined by the video, because you need the audio to match the video (lip sync) the video delay is harder to control (codec complexity), but the limit is your ability to hear delay. So, generally, we have NO buffering (like less than 1ms) for any network related things. On the other hand, to make it work, we, unlike many, have relatively constant data rates out of the encoder without using buffering to accomplish it. So, we can tolerate a reasonable bound on TRFC rate variation, we'll always send at that rate, or less. In practice, you tend to quantize transmit rates, so we will have to send at the next lowest rate for a given TRFC limit. Some other codecs can be forced to an exact data rate by buffering peaks, and again, you often see quantization of rates. A small problem that arises is that the signalling (SIP) typically includes a negotiation of rates. There isn't a way to signal a dynamically changing rate. This is straightforward to address by us sip guys. If it changes slowly enough, we can just signal the change using the mechanisms we have. In VoIP, things are a little more complex. There are a variety of algorithms, and a few of them are defined to work on more than one data rate. In general, like the hardware encoder, you can't switch algorithms without a noticeable glitch. Some implementations of multirate codecs can switch reasonably smoothly, others can't. It's presently uncommon to find a VoIP phone with a variable data rate codec, but it is common to find VoIP phones with more than one algorithm, each algorithm having a different data rate. Switching algorithms is definitely a signalling problem. On the other hand, nearly all voice codecs are constant bit rate inherently. Brian > -----Original Message----- > From: Mark Handley [mailto:M.Handley@cs.ucl.ac.uk] > Sent: Thursday, July 24, 2003 10:46 AM > To: Phelan, Tom > Cc: 'Damon Lanphear'; 'philippe.gentric@philips.com'; Magnus > Westerlund; > dccp@ietf.org; mmusic@ietf.org; Pasco Anderson, Jay > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > switching) > > > > > >Actually, my big worry here is TFRC, not the API. I'm > baffled about how to > >map slow start plus mostly smooth changes but occasional > abrupt changes and > >a small playout buffer into something workable. > > > >Another thing that concerns me (touched on in the paragraph > above) is the > >disconnect between a transport protocol making rate decisions and an > >application making rate decisions. It seems to me that > these particular > >applications are much better equipped to make the rate > decisions - they know > >about what is possible. It also seems that the application > can make at > >least as good a decision about what constitutes network > congestion. The app > >will need feedback about the playout buffer state, and this > is largely > >redundant with the DCCP acks. If the app is making rate > decisions and > >detecting network congestion, what do we need DCCP for? > > [I'm just dropping back into a discussion I haven't been following, so > forgive me if this duplicates previous discussion] > > There seem to be two obvious sorts of apps that might use TFRC: > > - streaming media > - videotelephony > > That isn't to say that there are different apps, but these two typify > two classes of apps. Both are fine with variable packet rates. But > streaming media has significantly more playout buffer available. > > Streaming media apps can run the codec (or choice of pre-encoded > stream) at approximately constant bitrate, and send at variable > bitrate, using the playout buffer to deal with the temporary > mismatches. > > Videotelephony apps don't have sufficient delay budget to fix things > at the receiver, but they do have the luxury of encoding live, so they > can change the compression parameters on the fly. They usually don't > have luxury of re-encoding twice though, so if their choice of > quantization parameters gives a rate that is different from what is > expected (because the video content was unpredictable), then they > might be in trouble. Also, if the TFRC bandwidth envelope changes > unexpectedly, you can be in trouble. > > > So, why do I say all this? > > > My assumption is that streaming media apps will normally send at the > TFRC rate. What they need is sufficient advance warning that the > playout buffer is running low so that they can switch down to a lower > rate. And if the playout buffer is starting to get rather large, then > they can switch up to a higher rate. Assuming rate switching is not a > trivial operation, and that the rate can only be switched at certain > re-sync points, then there is some danger that if congestion suddently > gets really bad, then the playout buffer will be exhausted before the > codec can be switched. My assumption here is that a really good API > would allow the sender to send above the TFRC rate for a period of > time, so long as the rate mismatch isn't too bad. A factor of two > might be reasonable as an upper bound on the oversending rate. > > > Videotelephony apps probably can't send at precisely the TFRC rate > without sacrificing delay to an undesirable extent. This means two > things. First, the app needs to be allowed to send at rates above the > TFRC rate for a period of time (again, bounded to avoid extreme > unfairness). Second, if the app sends under the TFRC rate for a short > period, it shouldn't lose it's ability to send faster later, so long > as it didn't undersend by too much. For such apps, the TFRC rate is a > guide rate - the app should be capable of varying around the guide > rate, so long as it stays within reasonable bounds, and so long as the > long-term average is close to the TFRC rate. > > > Anyway, in both cases, if the kernel strictly enforces the TFRC rate, > app designers will either not use DCCP, or they'll pad their signal > with redundant data so they can operate within a more predictable > codec envelope. Both are undesirable. > > > I'm not sure how we best design an API to satisfy this, but I think > it's really important that we do think about how this can be achieved. > > > The general philosophy that the TFRC rate is a guide-rate to be > followed loosely will probably also apply with TFRC-PS and VoIP, but > we know a lot less about this space. > > Cheers, > Mark > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 14:16:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19545 for ; Thu, 24 Jul 2003 14:16:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkd2-0004Cc-CW for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 14:15:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIFmIY016148 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 14:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkd2-0004CN-8X for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 14:15:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19512 for ; Thu, 24 Jul 2003 14:15:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkcz-0000dd-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 14:15:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fkcu-0000da-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 14:15:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkcH-00045T-NB; Thu, 24 Jul 2003 14:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkbS-00042M-8s for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 14:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19434; Thu, 24 Jul 2003 14:14:05 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkbP-0000cX-00; Thu, 24 Jul 2003 14:14:07 -0400 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 19fkbE-0000cC-00; Thu, 24 Jul 2003 14:13:56 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 35AB35A475; Thu, 24 Jul 2003 20:13:20 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id B456C19C48; Thu, 24 Jul 2003 20:13:19 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 9881D19C51; Thu, 24 Jul 2003 20:13:18 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id UAA24411; Thu, 24 Jul 2003 20:13:17 +0200 (MEST) To: Mark Handley Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 24 Jul 2003 20:03:36 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 24/07/2003 20:14:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Mark, >My assumption is that streaming media apps will normally send at the >TFRC rate. Could it be "at a rate equal or inferior to the TFRC rate"? What will happen if an application "does not use" the bandwidth indicated by TFRC? Often there will be no other choice, for example if my application can do 200 kb/s and 400 kb/s and TFRC indicates 380 kb/s then I must still use the media at 200 kb/s and SEND it at 200 kb/s because if I try to send my 200 kb/s media at 380 kb/s I will simply explode the player buffers very rapidly? >What they need is sufficient advance warning that the >playout buffer is running low so that they can switch down to a lower >rate. yes on advance warning about the TFRC rate, but I see the need for the sender to monitor the playout buffer as unnecessary complexity: I think that if the application *generates* (and sends) data at (or below) the TFRC rate then data will arrive on time and the playout buffer will always remain stable? >And if the playout buffer is starting to get rather large, then >they can switch up to a higher rate. you are assuming that the application sends data at a data rate larger than the media data rate... then yes! if you play with this fire you will need to monitor the player side buffers very carefully! The only advantage I can see with that trick is that *if you are lucky* during the first minutes of streaming you can play this trick to build up your player-side buffer using the positive gaps between the TFRC rate and the highest available media rate smaller than the TFRC rate; which means that playback can be started with minimal lead time i.e. it shortens the time the user waits between the streaming request and movie starts to play...unfortunately if you are unlucky you will underflow... do you seen any other advantage? anyway it is a more complicated solution. I would simply stream at the first available media rate smaller than the TFRC rate. >Assuming rate switching is not a >trivial operation, and that the rate can only be switched at certain >re-sync points, then there is some danger that if congestion suddently >gets really bad, then the playout buffer will be exhausted before the >codec can be switched. Let us compare: if you switch "in a hurry" it maybe that the result for the end user does not look very good, however the alternative (keep on sending at the same rate) is not very attractive either for the end user, since the player will drain its buffers anyway. the difference is that it is worse for the network! >My assumption here is that a really good API >would allow the sender to send above the TFRC rate for a period of >time, so long as the rate mismatch isn't too bad. A factor of two >might be reasonable as an upper bound on the oversending rate. I though if you wanted to do that you would declare it as a new rate control policy (since it is one, no?) i.e. give it another CCID ? What would be the point of defining TFRC and then "cheat on it" ? How would you define "TFRC conformance" then? >Anyway, in both cases, if the kernel strictly enforces the TFRC rate, >app designers will either not use DCCP, or they'll pad their signal >with redundant data so they can operate within a more predictable >codec envelope. Do you mean send garbage? what kind of gain would that bring ? what is a predictable codec envelope? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: "Phelan, Tom" cc: "'Damon Lanphear'" Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 Magnus Westerlund Mark Handley dccp@ietf.org mmusic@ietf.org "Pasco Anderson, Jay" Sent by: Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) mjh@cs.ucl.ac.uk Classification: 24/07/2003 16:46 >Actually, my big worry here is TFRC, not the API. I'm baffled about how to >map slow start plus mostly smooth changes but occasional abrupt changes and >a small playout buffer into something workable. > >Another thing that concerns me (touched on in the paragraph above) is the >disconnect between a transport protocol making rate decisions and an >application making rate decisions. It seems to me that these particular >applications are much better equipped to make the rate decisions - they know >about what is possible. It also seems that the application can make at >least as good a decision about what constitutes network congestion. The app >will need feedback about the playout buffer state, and this is largely >redundant with the DCCP acks. If the app is making rate decisions and >detecting network congestion, what do we need DCCP for? [I'm just dropping back into a discussion I haven't been following, so forgive me if this duplicates previous discussion] There seem to be two obvious sorts of apps that might use TFRC: - streaming media - videotelephony That isn't to say that there are different apps, but these two typify two classes of apps. Both are fine with variable packet rates. But streaming media has significantly more playout buffer available. Streaming media apps can run the codec (or choice of pre-encoded stream) at approximately constant bitrate, and send at variable bitrate, using the playout buffer to deal with the temporary mismatches. Videotelephony apps don't have sufficient delay budget to fix things at the receiver, but they do have the luxury of encoding live, so they can change the compression parameters on the fly. They usually don't have luxury of re-encoding twice though, so if their choice of quantization parameters gives a rate that is different from what is expected (because the video content was unpredictable), then they might be in trouble. Also, if the TFRC bandwidth envelope changes unexpectedly, you can be in trouble. So, why do I say all this? My assumption is that streaming media apps will normally send at the TFRC rate. What they need is sufficient advance warning that the playout buffer is running low so that they can switch down to a lower rate. And if the playout buffer is starting to get rather large, then they can switch up to a higher rate. Assuming rate switching is not a trivial operation, and that the rate can only be switched at certain re-sync points, then there is some danger that if congestion suddently gets really bad, then the playout buffer will be exhausted before the codec can be switched. My assumption here is that a really good API would allow the sender to send above the TFRC rate for a period of time, so long as the rate mismatch isn't too bad. A factor of two might be reasonable as an upper bound on the oversending rate. Videotelephony apps probably can't send at precisely the TFRC rate without sacrificing delay to an undesirable extent. This means two things. First, the app needs to be allowed to send at rates above the TFRC rate for a period of time (again, bounded to avoid extreme unfairness). Second, if the app sends under the TFRC rate for a short period, it shouldn't lose it's ability to send faster later, so long as it didn't undersend by too much. For such apps, the TFRC rate is a guide rate - the app should be capable of varying around the guide rate, so long as it stays within reasonable bounds, and so long as the long-term average is close to the TFRC rate. Anyway, in both cases, if the kernel strictly enforces the TFRC rate, app designers will either not use DCCP, or they'll pad their signal with redundant data so they can operate within a more predictable codec envelope. Both are undesirable. I'm not sure how we best design an API to satisfy this, but I think it's really important that we do think about how this can be achieved. The general philosophy that the TFRC rate is a guide-rate to be followed loosely will probably also apply with TFRC-PS and VoIP, but we know a lot less about this space. Cheers, Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 14:18:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19646 for ; Thu, 24 Jul 2003 14:18:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkf1-0004Zs-VA for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 14:17:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIHpqL017591 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 14:17:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkf1-0004Ze-Qs for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 14:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19623 for ; Thu, 24 Jul 2003 14:17:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkez-0000fX-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 14:17:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fket-0000fU-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 14:17:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkeH-0004HS-Gu; Thu, 24 Jul 2003 14:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkdp-0004Fh-9d for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 14:16:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19599; Thu, 24 Jul 2003 14:16:32 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkdm-0000ee-00; Thu, 24 Jul 2003 14:16:34 -0400 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 19fkdb-0000eO-00; Thu, 24 Jul 2003 14:16:23 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl4.philips.com (Postfix) with ESMTP id BB2A75A475; Thu, 24 Jul 2003 20:16:16 +0200 (MET DST) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 0E36B19C46; Thu, 24 Jul 2003 20:16:16 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id B4EBE19C45; Thu, 24 Jul 2003 20:16:15 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id UAA24616; Thu, 24 Jul 2003 20:16:15 +0200 (MEST) To: "Rosen, Brian" Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 24 Jul 2003 20:06:44 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 24/07/2003 20:17:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Brian, >we'll always send at that [TFRC] rate, or less. In practice, you tend to >quantize transmit rates, so we will have to send at the next lowest >rate for a given TRFC limit. I am glad to see that we reach exactly the same conclusion ... it is funny that it seems to be for reasons that look so different ! regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: "'Mark Handley'" "Phelan, Tom" cc: "'Damon Lanphear'" Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 "Rosen, Brian" Magnus Westerlund mmusic@ietf.org "Pasco Anderson, Jay" Sent by: Subject: RE: [dccp] natural DCCP sender-side API: (was stream switching) dccp-admin@ietf.org Classification: 24/07/2003 17:35 As someone who is presently making such a videophone, let me add just a couple of details, as I think Mark's observations are very close to what we need. Most video codecs cannot quickly change their encoding rates, and they often encounter a glitch when they do. Many are based on hardware implementations in the encoder which force you to stop the encoder, change a bunch of settings, and restart it. It's possible, and we'll do it, but not very often, please. Second, we have found that delay is not just a problem, it is a cliff. If you go over 150 ms or so, you fall off the cliff. The difference between, say 250 ms and 500 ms is about 2 orders of magnitude less that the difference between 150 ms and 200 ms (there is in fact some variation, because it's a human response thing, 150 ms is something like a 95% point for detecting delay). These are one way delays, and, as an aside, are actually a limit for the audio, but are determined by the video, because you need the audio to match the video (lip sync) the video delay is harder to control (codec complexity), but the limit is your ability to hear delay. So, generally, we have NO buffering (like less than 1ms) for any network related things. On the other hand, to make it work, we, unlike many, have relatively constant data rates out of the encoder without using buffering to accomplish it. So, we can tolerate a reasonable bound on TRFC rate variation, we'll always send at that rate, or less. In practice, you tend to quantize transmit rates, so we will have to send at the next lowest rate for a given TRFC limit. Some other codecs can be forced to an exact data rate by buffering peaks, and again, you often see quantization of rates. A small problem that arises is that the signalling (SIP) typically includes a negotiation of rates. There isn't a way to signal a dynamically changing rate. This is straightforward to address by us sip guys. If it changes slowly enough, we can just signal the change using the mechanisms we have. In VoIP, things are a little more complex. There are a variety of algorithms, and a few of them are defined to work on more than one data rate. In general, like the hardware encoder, you can't switch algorithms without a noticeable glitch. Some implementations of multirate codecs can switch reasonably smoothly, others can't. It's presently uncommon to find a VoIP phone with a variable data rate codec, but it is common to find VoIP phones with more than one algorithm, each algorithm having a different data rate. Switching algorithms is definitely a signalling problem. On the other hand, nearly all voice codecs are constant bit rate inherently. Brian > -----Original Message----- > From: Mark Handley [mailto:M.Handley@cs.ucl.ac.uk] > Sent: Thursday, July 24, 2003 10:46 AM > To: Phelan, Tom > Cc: 'Damon Lanphear'; 'philippe.gentric@philips.com'; Magnus > Westerlund; > dccp@ietf.org; mmusic@ietf.org; Pasco Anderson, Jay > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > switching) > > > > > >Actually, my big worry here is TFRC, not the API. I'm > baffled about how to > >map slow start plus mostly smooth changes but occasional > abrupt changes and > >a small playout buffer into something workable. > > > >Another thing that concerns me (touched on in the paragraph > above) is the > >disconnect between a transport protocol making rate decisions and an > >application making rate decisions. It seems to me that > these particular > >applications are much better equipped to make the rate > decisions - they know > >about what is possible. It also seems that the application > can make at > >least as good a decision about what constitutes network > congestion. The app > >will need feedback about the playout buffer state, and this > is largely > >redundant with the DCCP acks. If the app is making rate > decisions and > >detecting network congestion, what do we need DCCP for? > > [I'm just dropping back into a discussion I haven't been following, so > forgive me if this duplicates previous discussion] > > There seem to be two obvious sorts of apps that might use TFRC: > > - streaming media > - videotelephony > > That isn't to say that there are different apps, but these two typify > two classes of apps. Both are fine with variable packet rates. But > streaming media has significantly more playout buffer available. > > Streaming media apps can run the codec (or choice of pre-encoded > stream) at approximately constant bitrate, and send at variable > bitrate, using the playout buffer to deal with the temporary > mismatches. > > Videotelephony apps don't have sufficient delay budget to fix things > at the receiver, but they do have the luxury of encoding live, so they > can change the compression parameters on the fly. They usually don't > have luxury of re-encoding twice though, so if their choice of > quantization parameters gives a rate that is different from what is > expected (because the video content was unpredictable), then they > might be in trouble. Also, if the TFRC bandwidth envelope changes > unexpectedly, you can be in trouble. > > > So, why do I say all this? > > > My assumption is that streaming media apps will normally send at the > TFRC rate. What they need is sufficient advance warning that the > playout buffer is running low so that they can switch down to a lower > rate. And if the playout buffer is starting to get rather large, then > they can switch up to a higher rate. Assuming rate switching is not a > trivial operation, and that the rate can only be switched at certain > re-sync points, then there is some danger that if congestion suddently > gets really bad, then the playout buffer will be exhausted before the > codec can be switched. My assumption here is that a really good API > would allow the sender to send above the TFRC rate for a period of > time, so long as the rate mismatch isn't too bad. A factor of two > might be reasonable as an upper bound on the oversending rate. > > > Videotelephony apps probably can't send at precisely the TFRC rate > without sacrificing delay to an undesirable extent. This means two > things. First, the app needs to be allowed to send at rates above the > TFRC rate for a period of time (again, bounded to avoid extreme > unfairness). Second, if the app sends under the TFRC rate for a short > period, it shouldn't lose it's ability to send faster later, so long > as it didn't undersend by too much. For such apps, the TFRC rate is a > guide rate - the app should be capable of varying around the guide > rate, so long as it stays within reasonable bounds, and so long as the > long-term average is close to the TFRC rate. > > > Anyway, in both cases, if the kernel strictly enforces the TFRC rate, > app designers will either not use DCCP, or they'll pad their signal > with redundant data so they can operate within a more predictable > codec envelope. Both are undesirable. > > > I'm not sure how we best design an API to satisfy this, but I think > it's really important that we do think about how this can be achieved. > > > The general philosophy that the TFRC rate is a guide-rate to be > followed loosely will probably also apply with TFRC-PS and VoIP, but > we know a lot less about this space. > > Cheers, > Mark > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 15:14:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24653 for ; Thu, 24 Jul 2003 15:14:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flXJ-0007Pj-Kg for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:13:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OJDv5D028493 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flXI-0007PU-MM for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 15:13:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24529 for ; Thu, 24 Jul 2003 15:13:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19flXH-00018y-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 15:13:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19flXB-00018t-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 15:13:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flWO-0007Fe-OL; Thu, 24 Jul 2003 15:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flVl-0007Eh-QB for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 15:12:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24060; Thu, 24 Jul 2003 15:12:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19flVi-00016q-00; Thu, 24 Jul 2003 15:12:18 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19flVX-00015b-00; Thu, 24 Jul 2003 15:12:07 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Thu, 24 Jul 2003 12:10:53 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: dccp@ietf.org, mmusic@ietf.org In-Reply-To: References: Message-Id: <1059073681.6255.193.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 24 Jul 2003 12:08:01 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-07-24 at 07:52, philippe.gentric@philips.com wrote: > Hi Damon, > > you write: > > >I view the > >delivery time line in terms of a rate. That rate is determined by the > >attributes of the session: the state of the network, and the state of > >the client side buffer. > > Why do you want to monitor the receiver buffers? Because the buffer state is the best indicator of the continuity of the presentation. > I though there was only 3 possibilities corresponding to the 3 protocols: > > A) you dont care about "streaming" i.e. about "sending media in real time" > and then you should use HTTP progressive download (TCP) > and monitor the buffer because it may run dry. > or I don't think of streaming as "sending media in real time", I think of streaming as sending data while adhering to real time constraints. This is not the same as progressive download. I also happen to think that TCP _streaming_ is the correct solution for certain application deployments. > B) You stream "old fashion" i.e. push data into the network > irrespective of the network status (UDP) > and monitor the buffer because it may run dry. > or > C) you use DCCP and then your application should simply follow the rate indicated by DCCP > because *if* the sender follows the rate indicated by DCCP > then it *does not need* to monitor the client side buffers > since the data will arrive on time thanks to DCCP ?!? How does DCCP guarantee on time delivery? DCCP's transmission rate may vary over time. I understand that you assume the sender will follow the rate indicated by DCCP as closely as possible. But as you point out, this requires that DCCP tell the app "in advance" of rate changes. I submit that there can be no such thing as advanced rate change warnings. DCCP changes it rate in response to stimuli that it receives in the immediate moment. We can not expect DCCP to predict the amount of loss or change in RTT in the next N window durations. > and therefore the client buffers will always contain the same > amount of media time... and playback will always be smooth. Perhaps that will be the case in a perfect world where there is no such thing as transient congestion or our codecs provide use with infinite granularity of scalability. > is not this what DCCP is all about? DCCP is about providing congestion control to applications that wouldn't otherwise use congestion control. The benefit of DCCP to such applications is the offloading of congestion response to a robust and correct solution, rather than having to re-invent the wheel. > >The media time line may shift relative to the transmission time line > > you mean on purpose or jitter? I mean on purpose, and due to congestion events. > > > regards > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > cc: dccp@ietf.org > Magnus Westerlund > mmusic@ietf.org > Damon Lanphear Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) > > Classification: > Sent by: > dccp-admin@ietf.org > > 23/07/2003 21:38 > > > > > > > On Wed, 2003-07-23 at 11:12, philippe.gentric@philips.com wrote: > > Damon, you write: > > > > >I assume that DCCP will pace data > > >to the lower layers at the rate required of the associated CCID spec. > > >For the application to do this pacing as well would be redundant work. > > > > I am assuming it is a *different job*, they live on different planets, > > the DCCP stack cares about "real seconds", > > the application cares about "media seconds". > > I don't share that assumption. Probably because the domain in which I > work is on-demand and unidirectional live media delivery. I view the > delivery time line in terms of a rate. That rate is determined by the > attributes of the session: the state of the network, and the state of > the client side buffer. The media time line may shift relative to the > transmission time line. So my application cares about "media seconds" > only to the extent that it needs that information to know when and how > to adapt. > > > >What I don't quite understand about your position is the role played by > > >the application in pacing data. Do you maintain that the application > > >should pace data, or DCCP or both? > > > > Both, but differently? > > > > Streaming means that 1 second of content MUST be sent for > > every elapsed "real time" second (at least on the average). > > I don't agree with the MUST. It MAY if the congestion control will > allow it. Or it may send more if the congestion control, session type > (i.e. on-demand), and buffer state allows. Or it may send less if there > is too much buffer stored up at the client. The application should be > constantly adapting its transmission pattern to meet a broad set of > requirements, that include congestion control. > > > So the application cannot "pace seconds"... > > but I am assuming the application job contract > > does not say how many bytes one second of media is. > > > > In short I am assuming that the sending application > > can change the media data rate in order to > > *follow* the network data rate. > > I agree. But how closely you want to follow the network rate is > determined by the application type, and the state of the client buffer. > Oscillating the transmission pattern with congestion control > fluctuations can be a really bad thing for the user. > > > > > For conferencing -the media being encoded in real time- > > I assume that the DCCP stack will be used to pilot > > the encoder (tell it which rate to produce). > > > For pre-recorded media delivery the solution is stream switching > > (or download! see the other mail) > > > For live "TV" (very large number of receivers) changing > > the rate is either not relevant (e.g. end to end SSM) > > or it uses a relay server which folds the issue as being > > like pre-recorded media playback -each receiver maintaining > > a private server connection- then one should use stream switching, > > each stream "flavor" being simultaneously produced by a different encoder. > > > > regards, > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > > > > > > > > > To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > > cc: Magnus Westerlund > > dccp@ietf.org > > mmusic@ietf.org > > Damon Lanphear Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) > > > > Classification: > > 23/07/2003 19:42 > > > > > > > > > > > > > > Philippe, > > > > No one is really taking the position that a DCCP API should not make the > > transmission rate available to the application. This is quite a > > straightforward issue. DCCP can easily expose this key piece of > > information. > > > > I am more concerned with how an application meets DCCPs transmission > > limits (i.e. transmits at the required rate). > > > > Let's put the issue of adaptation aside for a moment and just concern > > ourselves with how an application paces data to the network. My view is > > that DCCP offers the application both congestion control AND the ability > > to manage the transmission schedule. I assume that DCCP will pace data > > to the lower layers at the rate required of the associated CCID spec. > > For the application to do this pacing as well would be redundant work. > > > > What I don't quite understand about your position is the role played by > > the application in pacing data. Do you maintain that the application > > should pace data, or DCCP or both? That is, is the use of the transmit > > rate to the application purely informative of a rate adaptation process, > > or of the transmit process as a whole? > > > > On Wed, 2003-07-23 at 04:59, philippe.gentric@philips.com wrote: > > > Magnus,Damon, > > > > > > let us forget a minute about the exact application, > > > (because my point is *not* specific to stream switching) > > > let us instead concentrate on the following problem: > > > > > > you write: > > > > > > "the server can simply switch to a lower bit-rate" > > > > > > This is an indication we are on agreement on one thing: > > > DCCP is about rate-driven applications. > > > > > > This is why my concern has been from the very start: > > > how is the sending application (what ever it is) > > > going to know what rate it must use? > > > > > > The answers you gave so far seem to indicate you are confident > > > the application can "compute" such a rate based on the behavior of a blocking API... > > > > > > (ok, allow me now to *also* put aside my humble opinion that trying to achieve that is not a good idea) > > > > > > I advocate that it would be a shame **because the information is already available**! > > > > > > Allow me to quote Section 3 of RFC 3448: > > > > > > " Generally speaking, TFRC's congestion control mechanism works as > > > follows: > > > > > > o The receiver measures the loss event rate and feeds this > > > information back to the sender. > > > > > > o The sender also uses these feedback messages to measure the > > > round-trip time (RTT). > > > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > > equation, giving the acceptable transmit rate. > > > > > > o The sender then adjusts its transmit rate to match the calculated > > > rate. > > > " > > > > > > This seems to imply that a "natural" sender-side API for DCCP would explicitely > > > inform the application ("sender") about this "acceptable transmit rate". > > > > > > It also happens to be the *best thing* that can be provided to > > > an application designed to perform network adaptation. > > > > > > > > > regards, > > > > > > Philippe Gentric > > > Software Architect > > > Philips MP4Net > > > philippe.gentric@philips.com > > > http://www.platform4.philips.com > > > > > -- > > Damon Lanphear > > > > > > > > > > > -- > Damon Lanphear > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 15:22:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25524 for ; Thu, 24 Jul 2003 15:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flfD-0007nY-2c for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OJM7kF029970 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flfC-0007n3-VX for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 15:22:06 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25474 for ; Thu, 24 Jul 2003 15:22:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flaH-0007U0-GI; Thu, 24 Jul 2003 15:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flZm-0007ST-Hs for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 15:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24974; Thu, 24 Jul 2003 15:16:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19flZl-0001Cs-00; Thu, 24 Jul 2003 15:16:29 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19flZZ-0001Aw-00; Thu, 24 Jul 2003 15:16:18 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by goodfellas.real.com with esmtp; Thu, 24 Jul 2003 12:14:54 -0700 Subject: Re: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) From: Damon Lanphear To: philippe.gentric@philips.com Cc: dccp@ietf.org, mmusic@ietf.org In-Reply-To: References: Message-Id: <1059073922.6254.198.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 24 Jul 2003 12:12:02 -0700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-07-24 at 07:58, philippe.gentric@philips.com wrote: > Hi Damon, > > >> >So, in this scheme, the sender doesn't need to know the rate that TFRC has > >> >determined, it simply always sends as fast as TFRC allows. > >> > >> 1) I am sorry but *from a network point of view* > >> I dont see a difference between this and "download"? > > > >The only substantive difference is that the transmitted data may not be > >stored statically on the device in the case of streaming. So if you > >have a small embedded device, with limited storage, you can experience > >media from the network without having the cache the whole thing on the > >device. > > with progressive download if you have no room for storage > you can garbage media as soon as it is decoded as well ... > and slow down the sender if needed too ... At this point, then why bother creating a differentiation between progressive download and streaming? If you are tossing data you just received from the network and decoded, you haven't actually downloaded anything in the traditional sense of the word. > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > cc: "Phelan, Tom" > dccp@ietf.org > mmusic@ietf.org > Damon Lanphear Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream > switching) > > Sent by: Classification: > mmusic-admin@ietf.org > > 23/07/2003 21:42 > > > > > > > On Wed, 2003-07-23 at 10:43, philippe.gentric@philips.com wrote: > > Hi Tom, > > > > you write: > > > > >The relevant difference, as far as this discussion goes, between recorded > > >and live media is that recorded media can be transmitted from the sender as > > >fast as the network allows (assuming buffering at the receiver). > > > > and then latter (still about recorded media): > > > > >So, in this scheme, the sender doesn't need to know the rate that TFRC has > > >determined, it simply always sends as fast as TFRC allows. > > > > 1) I am sorry but *from a network point of view* > > I dont see a difference between this and "download"? > > The only substantive difference is that the transmitted data may not be > stored statically on the device in the case of streaming. So if you > have a small embedded device, with limited storage, you can experience > media from the network without having the cache the whole thing on the > device. The problem then becomes one of balancing the use of device > storage (i.e. client buffer management) and congestion control. > > > > > Except that to my knowledge all the products doing that use HTTP > > since it solves a rather large number of other problems at the same time! > > > > 2) Now *from a user point of view* > > > > "download" has a flavor usually called "progressive download" > > whereby the downloaded media file has a structure enabling > > to start playback before download is finished. > > > > In this mode usually the slide bar that the player > > uses to display the media time has 2 colors, > > one displaying the current time in the media, > > the other the *received* time in the media, > > if this second mark stays ahead of the first mark playback is un-interrupted, > > otherwise the player stops and displays a message such as "please wait, rebufferring". > > > > So I dont see either, from a user point of view, > > how different a behavior the case you describe would have? > > > > **************** > > > > I conclude about this use case of the DCCP blocking API you described, > > that it is not very attractive at all. > > > > Surely DCCP has better assets to lure implementers?-)... > > I think an API providing a target rate would be a good starting point;-) > > > > regards, > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > > > > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > -- > Damon Lanphear > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 15:24:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25727 for ; Thu, 24 Jul 2003 15:24:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flhG-0007wh-67 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:24:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OJOE7V030537 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flhF-0007wS-Ca for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 15:24:13 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25690 for ; Thu, 24 Jul 2003 15:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flg5-0007oT-2k; Thu, 24 Jul 2003 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flfU-0007nn-3L for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 15:22:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25498; Thu, 24 Jul 2003 15:22:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19flfS-0001Hx-00; Thu, 24 Jul 2003 15:22:22 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19flfH-0001G5-00; Thu, 24 Jul 2003 15:22:11 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by flawless.real.com with esmtp; Thu, 24 Jul 2003 12:18:50 -0700 From: Damon Lanphear To: philippe.gentric@philips.com Cc: Mark Handley , dccp@ietf.org, mmusic@ietf.org In-Reply-To: References: Message-Id: <1059074158.6254.203.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 24 Jul 2003 12:15:59 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-07-24 at 11:03, philippe.gentric@philips.com wrote: > Hi Mark, > > > >My assumption is that streaming media apps will normally send at the > >TFRC rate. > > Could it be "at a rate equal or inferior to the TFRC rate"? > > What will happen if an application "does not use" the > bandwidth indicated by TFRC? > > Often there will be no other choice, > for example if my application can do 200 kb/s and 400 kb/s > and TFRC indicates 380 kb/s then I must still use the media > at 200 kb/s and SEND it at 200 kb/s because if I try > to send my 200 kb/s media at 380 kb/s I will simply explode > the player buffers very rapidly? > > >What they need is sufficient advance warning that the > >playout buffer is running low so that they can switch down to a lower > >rate. > > yes on advance warning about the TFRC rate, How can you ever get an advance warning about TFRC rate changes. These changes are response to immediate stimuli, to my knowledge that are not predicted by the current suite of algorithms. > but I see the need for the sender to monitor > the playout buffer as unnecessary complexity: > > I think that if the application *generates* (and sends) data at > (or below) the TFRC rate then data will arrive on time > and the playout buffer will always remain stable? so you are assuming that the application is generating the data on the fly. This is a very different scenario that certain other streaming media applications. So, again, the streaming model that one applies is tied directly to the sort of application. You need to monitor the playout buffer in some way for applications that can not adapt closely to the congestion controlled rate. Since there may be other, more coarse grained, adaptations you can make to maintain the continuity of playout. > > >And if the playout buffer is starting to get rather large, then > >they can switch up to a higher rate. > > you are assuming that the application sends data > at a data rate larger than the media data rate... > > then yes! if you play with this fire you will > need to monitor the player side buffers very carefully! > > The only advantage I can see with that trick > is that *if you are lucky* during the first minutes of streaming > you can play this trick to build up your player-side buffer > using the positive gaps between the TFRC rate and the highest available > media rate smaller than the TFRC rate; which means that playback can be started > with minimal lead time i.e. it shortens the time the user waits between the streaming > request and movie starts to play...unfortunately if you are unlucky > you will underflow... > > do you seen any other advantage? > > anyway it is a more complicated solution. > > I would simply stream at the first available > media rate smaller than the TFRC rate. > > > >Assuming rate switching is not a > >trivial operation, and that the rate can only be switched at certain > >re-sync points, then there is some danger that if congestion suddently > >gets really bad, then the playout buffer will be exhausted before the > >codec can be switched. > > Let us compare: > > if you switch "in a hurry" it maybe that the result > for the end user does not look very good, > however the alternative (keep on sending at the same rate) > is not very attractive either for the end user, > since the player will drain its buffers anyway. > > the difference is that it is worse for the network! > > >My assumption here is that a really good API > >would allow the sender to send above the TFRC rate for a period of > >time, so long as the rate mismatch isn't too bad. A factor of two > >might be reasonable as an upper bound on the oversending rate. > > I though if you wanted to do that you would declare it as a new > rate control policy (since it is one, no?) i.e. give it another CCID ? > > What would be the point of defining TFRC and then "cheat on it" ? > > How would you define "TFRC conformance" then? > > >Anyway, in both cases, if the kernel strictly enforces the TFRC rate, > >app designers will either not use DCCP, or they'll pad their signal > >with redundant data so they can operate within a more predictable > >codec envelope. > > Do you mean send garbage? > what kind of gain would that bring ? > what is a predictable codec envelope? > > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: "Phelan, Tom" > cc: "'Damon Lanphear'" > Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > Magnus Westerlund > Mark Handley dccp@ietf.org > mmusic@ietf.org > "Pasco Anderson, Jay" > Sent by: Subject: Re: [dccp] natural DCCP sender-side API: (was stream switching) > mjh@cs.ucl.ac.uk > Classification: > 24/07/2003 16:46 > > > > > > > > >Actually, my big worry here is TFRC, not the API. I'm baffled about how to > >map slow start plus mostly smooth changes but occasional abrupt changes and > >a small playout buffer into something workable. > > > >Another thing that concerns me (touched on in the paragraph above) is the > >disconnect between a transport protocol making rate decisions and an > >application making rate decisions. It seems to me that these particular > >applications are much better equipped to make the rate decisions - they know > >about what is possible. It also seems that the application can make at > >least as good a decision about what constitutes network congestion. The app > >will need feedback about the playout buffer state, and this is largely > >redundant with the DCCP acks. If the app is making rate decisions and > >detecting network congestion, what do we need DCCP for? > > [I'm just dropping back into a discussion I haven't been following, so > forgive me if this duplicates previous discussion] > > There seem to be two obvious sorts of apps that might use TFRC: > > - streaming media > - videotelephony > > That isn't to say that there are different apps, but these two typify > two classes of apps. Both are fine with variable packet rates. But > streaming media has significantly more playout buffer available. > > Streaming media apps can run the codec (or choice of pre-encoded > stream) at approximately constant bitrate, and send at variable > bitrate, using the playout buffer to deal with the temporary > mismatches. > > Videotelephony apps don't have sufficient delay budget to fix things > at the receiver, but they do have the luxury of encoding live, so they > can change the compression parameters on the fly. They usually don't > have luxury of re-encoding twice though, so if their choice of > quantization parameters gives a rate that is different from what is > expected (because the video content was unpredictable), then they > might be in trouble. Also, if the TFRC bandwidth envelope changes > unexpectedly, you can be in trouble. > > > So, why do I say all this? > > > My assumption is that streaming media apps will normally send at the > TFRC rate. What they need is sufficient advance warning that the > playout buffer is running low so that they can switch down to a lower > rate. And if the playout buffer is starting to get rather large, then > they can switch up to a higher rate. Assuming rate switching is not a > trivial operation, and that the rate can only be switched at certain > re-sync points, then there is some danger that if congestion suddently > gets really bad, then the playout buffer will be exhausted before the > codec can be switched. My assumption here is that a really good API > would allow the sender to send above the TFRC rate for a period of > time, so long as the rate mismatch isn't too bad. A factor of two > might be reasonable as an upper bound on the oversending rate. > > > Videotelephony apps probably can't send at precisely the TFRC rate > without sacrificing delay to an undesirable extent. This means two > things. First, the app needs to be allowed to send at rates above the > TFRC rate for a period of time (again, bounded to avoid extreme > unfairness). Second, if the app sends under the TFRC rate for a short > period, it shouldn't lose it's ability to send faster later, so long > as it didn't undersend by too much. For such apps, the TFRC rate is a > guide rate - the app should be capable of varying around the guide > rate, so long as it stays within reasonable bounds, and so long as the > long-term average is close to the TFRC rate. > > > Anyway, in both cases, if the kernel strictly enforces the TFRC rate, > app designers will either not use DCCP, or they'll pad their signal > with redundant data so they can operate within a more predictable > codec envelope. Both are undesirable. > > > I'm not sure how we best design an API to satisfy this, but I think > it's really important that we do think about how this can be achieved. > > > The general philosophy that the TFRC rate is a guide-rate to be > followed loosely will probably also apply with TFRC-PS and VoIP, but > we know a lot less about this space. > > Cheers, > Mark > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 15:29:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26203 for ; Thu, 24 Jul 2003 15:29:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flm5-00089j-Sb for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:29:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OJTD0S031347 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 15:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flm5-00089W-Pi for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 15:29:13 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26119 for ; Thu, 24 Jul 2003 15:29:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flkv-00082b-Md; Thu, 24 Jul 2003 15:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19flkN-00081n-RT for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 15:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25999; Thu, 24 Jul 2003 15:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19flkM-0001M7-00; Thu, 24 Jul 2003 15:27:26 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19flkA-0001Lu-00; Thu, 24 Jul 2003 15:27:15 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6OJQcD7005688; Thu, 24 Jul 2003 15:26:38 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 15:26:36 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 15:26:36 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB486@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'dccp@ietf.org'" , "'mmusic@ietf.org'" Cc: "Pasco Anderson, Jay" Date: Thu, 24 Jul 2003 15:26:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, I've been continuing to think about the one-way live media case and have come up with the following scheme for using DCCP with TFRC. Recall that one-way live differs from one-way pre-recorded media by having a max possible sending rate equal to the encoding rate (except for very short bursts, perhaps), and differs from two-way interactive media by being tolerant of delay. So, for this scheme we have a playout buffer at the receiver and transmit buffer at the sender. Note that these buffers contain media streams, not packets, and their lengths are measured in seconds, not bytes or packets. The transmit buffer is filled at the encoding rate and drained at the TFRC transmit rate. The playout buffer is filled at the network arrival rate and drained at the decoding rate. The playout buffer has a playback start threshold and the transmit buffer has a "switch encoding" threshold. These thresholds are on the order of a few to several seconds and switch encoding is less than playback start. Assume that the encoder can encode at two rates, a high rate and a low rate. At the start of a connection, the sender places data into the transmit buffer at the high encoding rate. The buffer is drained at the TFRC rate, which at this point is in slow-start and is probably slower than the required rate. This will cause a backup in the transmit buffer. Eventually TFRC will slow-start to a rate slightly above the rate necessary to sustain the encoding rate. When this happens the transmit buffer will drain and we'll reach a steady-state condition where the transmit buffer is empty and we're transmitting at a rate that is probably below the maximum allowed by TFRC. Note that, by my interpretation of TFRC at least, we won't be penalized for transmitting less than we could. You're only penalized when you transmit nothing for some number of roundtrip times. Meanwhile at the receiver, the playout buffer is filling, and when it reaches the playback start threshold playback will start. After TFRC slow-start and the transmit buffer is drained, this buffer will reach a steady state where packets are arriving from the network at the encoding rate (ignoring jitter) and being drained from the buffer at the (equal) decoding rate. The depth of the buffer will be the playback start threshold plus the maximum depth of the transmit buffer during slow start. Now assume that network congestion forces TFRC to drop its rate to below that needed by the high rate encoding. The transmit buffer will begin to fill and the playout buffer will begin to drain. When the transmit buffer reaches the switch encoding threshold, the sender switches to the low rate encoding, and converts all of the data in the transmit buffer to low rate encoding. I'll ignore issues of how to do this efficiently, but it's important not to discard this data, and to convert it. Assuming that the network can support the new, lower, rate (and a little more) the transmit buffer will begin to drain and the playout buffer will begin to fill. Eventually the transmit buffer will empty, the playout buffer will be back to its steady-state level, and we'll be transmitting data at the new, lower, encoding rate. At this point (perhaps after a slight delay) the sender can switch back to the higher rate. If the new rate can't be sustained the transmit buffer will fill again (and the playout buffer will drain). When the switch encoding threshold is reached the sender goes back to the lower encoding rate. This oscillation continues until the stream ends or the network is able to support the high rate for the long term. It might be useful for DCCP to tell the application about rate changes. For instance, when DCCP/TFRC has decided on a rate too low for the high rate encoding the application could make the change to the low rate immediately. This would work, but it might lead to unnecessary switches to the lower rate. In particular, when DCCP decides on a new rate, it has no way of knowing whether this is a transient or a long-term change. If it's transient the transmit buffer might be able to absorb the problem, and a change to the lower rate might unnecessarily reduce the quality seen by the user. If we wait for the switch encoding threshold we can be more sure that the rate change is long-term. Also, if we rely on rate indications for the downshift, we need to ignore it during slow-start. It might be more useful to know when DCCP has raised the rate sufficiently to switch to the high rate (after the transmit buffer has been drained). Note that this scheme is also suitable for one-way pre-recorded media, as long as the transmit buffer is only filled at the encoding rate, not at the disk read rate. Overall I'd say that this is better than the previous scheme (for one-way pre-recorded media), and I think that some of the commenters on the previous message must have had something like this in mind. I still don't know how to do the two-way interactive media. Tom P. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 16:29:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28921 for ; Thu, 24 Jul 2003 16:29:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmho-0002vp-82 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 16:28:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKSqPp011263 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 16:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmhn-0002va-E5 for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:28:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28892 for ; Thu, 24 Jul 2003 16:28:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmhl-0001wL-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 16:28:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmhe-0001wF-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 16:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmgz-0002qb-5M; Thu, 24 Jul 2003 16:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmgi-0002q3-UJ for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 16:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28814; Thu, 24 Jul 2003 16:27:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmgg-0001vF-00; Thu, 24 Jul 2003 16:27:42 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19fmgU-0001uY-00; Thu, 24 Jul 2003 16:27:30 -0400 Received: from batman ([::ffff:172.23.106.42]) (TLS: TLSv1/SSLv3,128bits,RC4-MD5) by goodfellas.real.com with esmtp; Thu, 24 Jul 2003 13:26:51 -0700 From: "Sean Robinson" To: "Damon Lanphear" , "Phelan, Tom" Cc: philippe.gentric@philips.com, "Magnus Westerlund" , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Subject: RE: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Date: Thu, 24 Jul 2003 13:26:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1058982715.6255.56.camel@poesis.dev.prognet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that Tom's contribution has provided a good basis for this discussion. The decision is further complicated by the inclusion of media composition. Consider we following media availablity constraints (which can be applied to each of the named media application, On demand, live and 2-way) - A single fixed rate media source - multiple discrete media encodings - a fully scalable media encoding (such as MPEG-4 FGS) Now, given that in the second case we could add as many rates as we desire and that the third case doesn't really exist (no codec is infitely scalable), we can treat these as the same for the purposes of this discussion. We can view this from the application level as a series of decision points in which the application concludes the best media data to send at a given moment given the current network conditions. The design of the media is obviously a critical factor in the succcess of the application as some media may work better in some application than others. It is assumed that low latency applicaiton will require more frequent decision points where an on-demand application may require fewer. We can think of the media transmitted between these decision points as a media unit. Here I would like to bring up a point that I feel has been neglected in the discussion to this point. That is the perspective of resource efficiency in the interaction between a user level media application and a kernel level protocol. From this perspective the frequency of interaction between the two sides should be minimized. Also we would further hope that the need for user level packet scheduling would also be minimized. If the 2 above points are agreed to, we can then conclude that in the ideal case we would want the interaction with the protocol to match as closely as possible with those media decision points. In other words, the application should only have to interact with the dataflow when there is some meaningful action to be taken. This seems to me to be the best method for evaluation of an API semantic. First, let's take the simple blocking semantic. The first question we should ask (which is not specified in the DCCP user manual) is what triggers that the block has cleared? If we take the naive assumption that the file descriptor is cleared for writing after the transmission of each datagram, then our interaction with the protocol will also be on every datagram (if we are instantly responsive to the signal). This is likely more than we would like in all but the very most scalable solutions. Keep in mind, however, that flow control through file descriptors is a well supported concept throughout different OSes and this is very attractive in the design of a protocol. Further, if we define parameters for when the desriptor is marked for writing we can get greater control over its scalability. It should also be noted that this mechanism is not really optional, since the prtocol must support blocking when the pre-netwqork buffer is full. Now the rate-signalling approach has also been proposed, but it implies a network-driven scheduling model over a media-driven model. TFRC will generate a new throughput claculation once per round trip time and if this is the frequency at which the rate would be signalled, then we could either find this to be too frequent or too sparse depending on the underlying network. Certainly an agrument could be made, media decision points should be syncronized with network condition and if this is possible, this is a more attractive solution. It is important to note, however, that at a fine grained level over delivery rate is not that relevant to the delivery characteristcs, but rather the data size of individual media units. So, if TFRC reports 20kbs at a given window, it doesn't necesicearily mean that the application should choose the 20kbs stream, but should evaluate the data to be transmitted for available streams at that decision point. Another option outside of direct feedback would be a polling approach, whereby the application set interupt timers to evaluate the dataflow at appropriate points in the application. This method could work well in stuations in which the throughput has a low degree of variance, since the evaluation interval could be tailored to the desired media. As the variance increases, the effectiveness of this approach decreases since the data in the pre-network queue may be delivered faster or slower than expected, causing an increased number of "wasted" check in which no action is taken. Another approach could be to tag specific datagrams for signalling on transmission. Then DCCP would signal (using some means) when a given datagram is transmitted. If one datagram per media unit, then we could get a notification at every media unit, which is what we want. The semantics of defining this within an API could be quite complex, however. Which brings me to a final important point. As mentioned in several points, we must consider the method in which the information is signalled. Some OSes have more advanced signalling mechanism than others and the more digression from standard mechanisms, the less integrated into the OS the protocol becomes. This is an extremely imprrtant factor in this discussion and should not be treated likely. S > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Damon Lanphear > Sent: Wednesday, July 23, 2003 10:52 AM > To: Phelan, Tom > Cc: 'philippe.gentric@philips.com'; Magnus Westerlund; dccp@ietf.org; > mmusic@ietf.org; Pasco Anderson, Jay > Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream > switching) > > > Tom, > > Thank you for providing better structure to our discussion. This is > precisely what we needed to speak more precisely on these matters! > > I haven't been able to work out acceptable scenarios for the other two > > applications yet. It seems almost certain to me that TFRC and > a blocking > > API is not at all suitable for two-way media. It might be suitable for > > one-way live media, but I haven't figured out how it could be yet. If > > anyone has ideas here I'd like to hear them :-). > > I'd like to understand the alternative to a blocking API for two-way > media. I assume that in this case the application is responsible for > managing the transmission rate. I guess I get confused when I consider > that some agent in the pipeline will have to block transmission when the > transmission attempt oversteps the congestion control rate. What does > it matter if this agent is DCCP or the application, particularly if we > have access to the transmit queue in DCCP, as is the case in the ICIR > implementation ? > > As regards unidirectional live, its differs from unidirectional > on-demand in that there's no data sitting on disk with which to fill a > post-network buffer to a point where an up shift seems appropriate. > Downshifts are straightforward, however, since under sending can just as > well happen with live streams. So we need a metric for up shifts that > does not rely on buffer state. Perhaps some measure of the stability of > the available congestion controlled throughput over time? > > On Wed, 2003-07-23 at 07:43, Phelan, Tom wrote: > > Hi Phillipe, > > > > In thinking about your draft on stream rate switching and this > discussion on > > APIs I've come to the conclusion that there are actually three different > > applications being discussed, with three different sets of requirements. > > One of these applications can be reasonably satisfied with a > blocking API > > (although there could be some efficiencies with other > capabilities). For > > the other two I'm not sure yet what would work. > > > > Excuse me if I'm re-inventing something here, but the three > applications I > > have in mind are: > > o One-way pre-recorded media > > o One-way live media > > o Two-way interactive media > > > > The relevant difference, as far as this discussion goes, > between recorded > > and live media is that recorded media can be transmitted from > the sender as > > fast as the network allows (assuming buffering at the > receiver). Live media > > can only be transmitted at the rate that it's generated. > > > > The difference between one-way (live) and two-way is the size > of the playout > > buffer. In one-way media you can use a playout buffer that's > hundreds of > > times larger than the round trip time. In two-way media the > playout buffer > > is on the same order of magnitude as the round trip time. > > > > So, it seems to me that one-way pre-recorded media can be > reasonably served > > by DCCP with TFRC and a sockets-like (blocking) API. For > example, assume > > that the sender has a media stream in two bit rates, high and low. Also > > assume that the sender is able to estimate the depth of the receiver's > > playout buffer (either via feedback from the receiver or some > other means). > > Now set three thresholds in the playout buffer, a low > threshold, a playback > > start threshold and a high threshold, in order of increasing depth. > > > > To start the connection, the sender begins transmitting data > from the high > > bit rate stream as fast as TFRC allows (blocking the transmit thread for > > rate control). Since TFRC is in slow-start, this is probably too slow > > initially, but eventually the rate might increase to fast > enough and past. > > The receiver buffers data until the playback start threshold is > reached, and > > then begins playback. > > > > If the TFRC rate never gets fast enough, or a packet loss makes > TFRC drop > > the rate, the receiver will drain the playout buffer faster > than it's being > > filled. If the playout buffer drops below the low threshold, the sender > > switches to the low bit rate stream. Assuming that the network > has a little > > bit more capacity than the low bit rate stream requires, the > playout buffer > > will begin filling again. > > > > When the buffer crosses the high threshold the sender switches > to the high > > bit rate stream. Assuming that the network still doesn't have enough > > capacity for the high bit rate stream, the playout buffer will > drain. When > > it reaches the low threshold the sender switches back to the > low bit rate. > > The sender will oscillate back and forth like this until the > connection is > > terminated. > > > > So, in this scheme, the sender doesn't need to know the rate > that TFRC has > > determined, it simply always sends as fast as TFRC allows. > TFRC shapes the > > stream to the network's requirements, and the feedback about the playout > > buffer allows the sender to shape the stream to the application's > > requirements. > > > > > > > Tom P. > > > > > > > -----Original Message----- > > > From: philippe.gentric@philips.com > > > [mailto:philippe.gentric@philips.com] > > > Sent: Wednesday, July 23, 2003 7:59 AM > > > To: Magnus Westerlund > > > Cc: Damon Lanphear; dccp@ietf.org; mmusic@ietf.org > > > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > > > switching) > > > > > > > > > > > > Magnus,Damon, > > > > > > let us forget a minute about the exact application, > > > (because my point is *not* specific to stream switching) > > > let us instead concentrate on the following problem: > > > > > > you write: > > > > > > "the server can simply switch to a lower bit-rate" > > > > > > This is an indication we are on agreement on one thing: > > > DCCP is about rate-driven applications. > > > > > > This is why my concern has been from the very start: > > > how is the sending application (what ever it is) > > > going to know what rate it must use? > > > > > > The answers you gave so far seem to indicate you are confident > > > the application can "compute" such a rate based on the > > > behavior of a blocking API... > > > > > > (ok, allow me now to *also* put aside my humble opinion that > > > trying to achieve that is not a good idea) > > > > > > I advocate that it would be a shame **because the information > > > is already available**! > > > > > > Allow me to quote Section 3 of RFC 3448: > > > > > > " Generally speaking, TFRC's congestion control mechanism works as > > > follows: > > > > > > o The receiver measures the loss event rate and feeds this > > > information back to the sender. > > > > > > o The sender also uses these feedback messages to measure the > > > round-trip time (RTT). > > > > > > o The loss event rate and RTT are then fed into TFRC's throughput > > > equation, giving the acceptable transmit rate. > > > > > > o The sender then adjusts its transmit rate to match the > > > calculated > > > rate. > > > " > > > > > > This seems to imply that a "natural" sender-side API for DCCP > > > would explicitely > > > inform the application ("sender") about this "acceptable > > > transmit rate". > > > > > > It also happens to be the *best thing* that can be provided to > > > an application designed to perform network adaptation. > > > > > > > > > regards, > > > > > > Philippe Gentric > > > Software Architect > > > Philips MP4Net > > > philippe.gentric@philips.com > > > http://www.platform4.philips.com > > > > > > > > > > > > _______________________________________________ > > > dccp IETF mailing list: dccp@ietf.org > > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > -- > Damon Lanphear > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 16:46:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29825 for ; Thu, 24 Jul 2003 16:46:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmyO-0004bc-CI for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 16:46:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKk0AO017704 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 16:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmyO-0004bT-8h for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:46:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29796 for ; Thu, 24 Jul 2003 16:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmy9-00026i-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 16:45:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmy4-00026d-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 16:45:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmxR-0004TJ-1l; Thu, 24 Jul 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmwl-0004SU-L0 for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 16:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29666; Thu, 24 Jul 2003 16:44:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmwj-00025K-00; Thu, 24 Jul 2003 16:44:17 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19fmwY-00024n-00; Thu, 24 Jul 2003 16:44:06 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04353; Thu, 24 Jul 2003 16:42:18 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15446; Thu, 24 Jul 2003 16:42:13 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1M5BKW>; Thu, 24 Jul 2003 16:42:12 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C4B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" , philippe.gentric@philips.com Cc: "Phelan, Tom" , dccp@ietf.org, mmusic@ietf.org, "'Reiner Ludwig'" Date: Thu, 24 Jul 2003 16:42:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] Using DCCP for VoIP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Not really. If you are going to have a problem, you would rather have the video go before the audio, and thus you would prefer to keep the congestion control separate. I'd rather they be entirely separate. Brian > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Thursday, July 24, 2003 4:21 PM > To: philippe.gentric@philips.com > Cc: Phelan, Tom; dccp@ietf.org; mmusic@ietf.org; 'Reiner Ludwig' > Subject: Re: [dccp] Using DCCP for VoIP > > > Hi all, > > On this issue: > > > IMHO this issue is related to my question in the other mail about > > managing audio AND video at the same time: probably DCCP > should have a > > way to handle "collectively" a bunch of streams, be it > audio plus video > > or two-way audio! > > Our thought was that, given DCCP's unreliability, it is > trivial to layer > multiple streams on top. The first byte of packet data could indicate > stream number to the application. This works as long as both > streams want > to share the same congestion control state + CC mechanism -- > is this the > case? > > Eddie > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 18:01:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02678 for ; Thu, 24 Jul 2003 18:01:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo8o-0000V9-Hd for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:00:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OM0oBb001924 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:00:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo8n-0000Uv-OU for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:00:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02659 for ; Thu, 24 Jul 2003 18:00:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fo8k-0002h5-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:00:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fo8f-0002h2-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:00:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo82-0000Np-6m; Thu, 24 Jul 2003 18:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo7H-0000N3-Dp for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 17:59:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02614; Thu, 24 Jul 2003 17:59:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fo7E-0002g4-00; Thu, 24 Jul 2003 17:59:12 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19fo6y-0002fx-00; Thu, 24 Jul 2003 17:58:56 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OLwki8056056; Thu, 24 Jul 2003 14:58:46 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242158.h6OLwki8056056@coyote.icir.org> To: dccp@ietf.org, mmusic@ietf.org cc: tphelan@sonusnet.com Date: Thu, 24 Jul 2003 14:58:46 -0700 From: Eddie Kohler Subject: [MMUSIC] What's wrong with TFRC for VoIP and other apps? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 all, I just wanted to try to summarize the issues people have brought up, in other threads, about why TFRC and/or DCCP will be inappropriate for VoIP and other apps. I agree with Tom Phelan's comment that the biggest issues have to do with TFRC, not the API. I've left off the solutions people have proposed to these problems. 1. Rate slows down during idle periods The TFRC allowed sending rate will drop down to something very small (2-4 packets/RTT) when the sender is idle. This may cause problems particualrly with VoIP conversations, which are naturally idle-one-way then idle-the-other-way. The rampup from the small rate to the fair rate may take several to many RTTs, ouch. 2. Rate will not increase during app-limited period This is essentially the same problem as above. Say the application is sending at rate R. The allowed rate will not increase much beyond R (say, more than 2R) until the app transmits at a faster rate. 3. Apps with fixed sets of rates An app might have a discrete set of sending rates. Must it send at the highest app rate <= the TFRC allowed rate? Would be very nice to allow some flexibility, so that it could send at, say, the highest rate <= 1.8*TFRC_allowed_rate. 4. Rate changes/oscillations There are application costs, possibly significant ones, associated with changing rates. If the app has to change its rate frequently, because of CC, that's a problem. Have I missed anything? Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 18:03:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02748 for ; Thu, 24 Jul 2003 18:03:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foAi-0000eZ-5L for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:02:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OM2mC8002505 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foAi-0000eK-13 for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:02:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02725 for ; Thu, 24 Jul 2003 18:02:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foAf-0002hf-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:02:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19foAZ-0002hc-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:02:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo9x-0000bq-O2; Thu, 24 Jul 2003 18:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo9w-0000ab-JC for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 18:02:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02710 for ; Thu, 24 Jul 2003 18:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fo9t-0002hL-00 for mmusic@ietf.org; Thu, 24 Jul 2003 18:01:57 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19fo9d-0002hH-00 for mmusic@ietf.org; Thu, 24 Jul 2003 18:01:41 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OM1Vi8056108; Thu, 24 Jul 2003 15:01:31 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242201.h6OM1Vi8056108@coyote.icir.org> To: "Rosen, Brian" cc: "'Eddie Kohler'" , philippe.gentric@philips.com, "Phelan, Tom" , dccp@ietf.org, mmusic@ietf.org, "'Reiner Ludwig'" In-Reply-To: Message from "Rosen, Brian" of "Thu, 24 Jul 2003 16:42:06 EDT." <313680C9A886D511A06000204840E1CF070B5C4B@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 24 Jul 2003 15:01:31 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] Using DCCP for VoIP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Not really. If you are going to have a problem, you would > rather have the video go before the audio, and thus you > would prefer to keep the congestion control separate. > > I'd rather they be entirely separate. This may be a good reason to keep the data *together*, on one connection, actually. The sender can react to congestion feedback by throwing out the video first. If you have two separate connections, both of their rates will decrease. Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 18:12:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03820 for ; Thu, 24 Jul 2003 18:12:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foJR-0001an-Ot for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:11:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OMBnbl006115 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:11:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foJR-0001aU-Ke for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:11:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03771 for ; Thu, 24 Jul 2003 18:11:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foJO-0002n7-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:11:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19foJI-0002n4-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:11:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foIg-0001Mt-Ai; Thu, 24 Jul 2003 18:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foIG-0001MU-PJ for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 18:10:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03632; Thu, 24 Jul 2003 18:10:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foID-0002me-00; Thu, 24 Jul 2003 18:10:33 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19foHx-0002m9-00; Thu, 24 Jul 2003 18:10:17 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OM9mi8056187; Thu, 24 Jul 2003 15:09:48 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242209.h6OM9mi8056187@coyote.icir.org> To: "Phelan, Tom" cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" In-Reply-To: Message from "Phelan, Tom" of "Thu, 24 Jul 2003 15:26:27 EDT." <4CF48720B6E9D4118D040060CF2074E9082BB486@sonusdc3.sonusnet.com> Date: Thu, 24 Jul 2003 15:09:48 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Note that, by my interpretation of TFRC at least, we won't be > penalized for transmitting less than we could. You're only penalized when > you transmit nothing for some number of roundtrip times. My understanding is, you are not penalized -- you still get to send at your (allowed) rate -- but your maximum allowed transmit rate doesn't continue to increase. THe maximum allowed transmit rate is bounded above by some multiple of the current transmit rate. This is essentially the same as in the idle case. > It might be useful for DCCP to tell the application about rate changes. We absolutely want the API to take care of this. Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 18:23:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04575 for ; Thu, 24 Jul 2003 18:23:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foU7-0001yG-CS for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:22:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OMMpfG007570 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 18:22:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foU7-0001y1-7j for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:22:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04537 for ; Thu, 24 Jul 2003 18:22:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foU4-0002ro-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:22:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19foTy-0002rl-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 18:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foTJ-0001n8-E0; Thu, 24 Jul 2003 18:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foSR-0001mT-40 for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 18:21:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04486; Thu, 24 Jul 2003 18:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foSO-0002ql-00; Thu, 24 Jul 2003 18:21:04 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19foS8-0002qe-00; Thu, 24 Jul 2003 18:20:48 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OMKci8056309; Thu, 24 Jul 2003 15:20:38 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242220.h6OMKci8056309@coyote.icir.org> To: dccp@ietf.org, mmusic@ietf.org cc: tphelan@sonusnet.com Date: Thu, 24 Jul 2003 15:20:38 -0700 From: Eddie Kohler Subject: [MMUSIC] Packet drop API / what happens with packet drops now? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , What happens in currently-deployed codecs when packets are dropped? Clearly codecs, and VoIP in particular, can handle loss. Possibly even high loss rates. One way to think about DCCP's allowed sending rate is that it moves drops that *would* have happened in the network *anyway*, into the sending host. (Although DCCP will generally drop more than the network would have, to ensure fairness, and because of congestion-control infelicities that we want to fix.) So how disastrous are these drops? Another way to put this: A DCCP API might never block -- or it might block for at most T seconds. Instead, writing a packet into a full send buffer would drop that packet; or it might drop an older packet---a drop-from-head send buffer; or it might drop the oldest packet with lowest priority annotation. Now the app simply sees a loss rate, which DCCP will happily report. For codec switching, you can simply switch when the loss rate is intolerably high -- which you would have had to do anyway. How horrible would this be? Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 21:29:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07863 for ; Thu, 24 Jul 2003 21:29:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frO5-0000e4-Qs for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:28:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1Sngb002474 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frO5-0000dp-Nn for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:28:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07841 for ; Thu, 24 Jul 2003 21:28:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frO2-0003hN-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:28:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frNx-0003hK-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frNJ-0000Wo-EO; Thu, 24 Jul 2003 21:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frMV-0000VO-Gq for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 21:27:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07825; Thu, 24 Jul 2003 21:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frMR-0003gv-00; Thu, 24 Jul 2003 21:27:07 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19frMG-0003gn-00; Thu, 24 Jul 2003 21:26:56 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6P1Q6YG023620; Thu, 24 Jul 2003 21:26:06 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 21:26:04 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 21:26:03 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB488@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Eddie Kohler'" , "Phelan, Tom" Cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Date: Thu, 24 Jul 2003 21:25:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Eddie, If DCCP conflicts with an application's requirements, then the application won't use it, whether DCCP is network friendly or not. Note that I think that network-friendly reaction to congestion is absolutely one of my application's requirements (my app is two-way voice). I hope that I can use DCCP to get that, but I'm having difficulties making it work. Not that I've given up hope, mind you. I think I've managed to work out reasonable ways to use DCCP for similar, but not quite identical apps. And I intend to keep trying for my app. I think it's very important for DCCP to know whether it's really useful for two-way voice or not. All of the DCCP documents mention it as a primary target application. Some people on this list might already know how to make it work, but I don't yet, and I haven't seen anyone give a credible scheme for it yet, so I'll keep trying. Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Thursday, July 24, 2003 5:27 PM > To: Phelan, Tom > Cc: 'Damon Lanphear'; 'philippe.gentric@philips.com'; Magnus > Westerlund; > dccp@ietf.org; mmusic@ietf.org; Pasco Anderson, Jay > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > switching) > > > > > Another thing that concerns me (touched on in the paragraph > above) is the > > disconnect between a transport protocol making rate decisions and an > > application making rate decisions. It seems to me that > these particular > > applications are much better equipped to make the rate > decisions - they know > > about what is possible. It also seems that the application > can make at > > least as good a decision about what constitutes network > congestion. The app > > will need feedback about the playout buffer state, and this > is largely > > redundant with the DCCP acks. If the app is making rate > decisions and > > detecting network congestion, what do we need DCCP for? > > My take: > > Your paragraph was written from the application's point of > view, not that > of the network. DCCP is about implementing congestion control that is > appropriate for the network: in other words, currently, > TCP-friendly CC. > This may conflict with application "requirements". > > > For example: > > > It seems to me that these particular > > applications are much better equipped to make the rate > decisions - they know > > about what is possible. > > What is possible for the application may not be TCP-friendly > or appropriate > for the network (if the app has a minimum rate, for example). > > > It also seems that the application can make at > > least as good a decision about what constitutes network congestion. > > The app should make a decision that is TCP-friendly -- in > which case you've > got DCCP all over again. You need acks, probably ECN Nonces, .... > > > We have a congestion control problem, for which we need a congestion > control solution. Avoiding DCCP doesn't avoid the problem. > > So we should solve the problem! And I think we can solve it! > > > Now, it may end up that DCCP is not appropriate, once the congestion > control problem is solved. I'm not against UDP with application-level > congestion control. But CC is a hard problem, which we are > trying to solve > for you. > > > Also: > > > The app will need feedback about the playout buffer state, > and this is > > largely redundant with the DCCP acks. > > The app should be able to extract this information from the > DCCP API, so no > app-level acks are necessary. > > > Eddie > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 21:31:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07944 for ; Thu, 24 Jul 2003 21:31:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frQ0-0000rE-Dz for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:30:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1UmjE003288 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frQ0-0000qp-AV for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:30:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07901 for ; Thu, 24 Jul 2003 21:30:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frPx-0003iW-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:30:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frPr-0003iT-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:30:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frPF-0000l9-Rw; Thu, 24 Jul 2003 21:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frPA-0000jE-3l for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 21:29:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07880; Thu, 24 Jul 2003 21:29:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frP7-0003hp-00; Thu, 24 Jul 2003 21:29:53 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19frOw-0003ha-00; Thu, 24 Jul 2003 21:29:42 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6P1T8YG023789; Thu, 24 Jul 2003 21:29:08 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 21:29:04 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 21:29:03 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB489@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Eddie Kohler'" , dccp@ietf.org, mmusic@ietf.org Cc: "Phelan, Tom" Date: Thu, 24 Jul 2003 21:28:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: What's wrong with TFRC for VoIP and other apps? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Eddie, One more problem I see for two-way voice is slow-start. This is somewhat related to "rate slows down during idle periods", but you're stuck with it even if you don't do silence suppression. I don't have a "TCP-friendly" solution for this yet. Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Thursday, July 24, 2003 5:59 PM > To: dccp@ietf.org; mmusic@ietf.org > Cc: tphelan@sonusnet.com > Subject: What's wrong with TFRC for VoIP and other apps? > > > Hi all, > > I just wanted to try to summarize the issues people have > brought up, in > other threads, about why TFRC and/or DCCP will be > inappropriate for VoIP > and other apps. I agree with Tom Phelan's comment that the > biggest issues > have to do with TFRC, not the API. I've left off the > solutions people have > proposed to these problems. > > 1. Rate slows down during idle periods > > The TFRC allowed sending rate will drop down to something > very small > (2-4 packets/RTT) when the sender is idle. This may cause problems > particualrly with VoIP conversations, which are naturally > idle-one-way > then idle-the-other-way. The rampup from the small rate to > the fair rate > may take several to many RTTs, ouch. > > 2. Rate will not increase during app-limited period > > This is essentially the same problem as above. Say the > application is > sending at rate R. The allowed rate will not increase much beyond R > (say, more than 2R) until the app transmits at a faster rate. > > 3. Apps with fixed sets of rates > > An app might have a discrete set of sending rates. Must it > send at the > highest app rate <= the TFRC allowed rate? Would be very > nice to allow > some flexibility, so that it could send at, say, the > highest rate <= > 1.8*TFRC_allowed_rate. > > 4. Rate changes/oscillations > > There are application costs, possibly significant ones, > associated with > changing rates. If the app has to change its rate > frequently, because of > CC, that's a problem. > > Have I missed anything? > > Eddie > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 21:37:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08113 for ; Thu, 24 Jul 2003 21:37:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frVp-0001FS-0V for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:36:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1am0J004792 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:36:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frVo-0001FD-TX for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:36:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08099 for ; Thu, 24 Jul 2003 21:36:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frVm-0003lG-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:36:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frVg-0003lD-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:36:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frV4-00018L-DK; Thu, 24 Jul 2003 21:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frUB-00014V-4v for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 21:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08048; Thu, 24 Jul 2003 21:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frU7-0003kB-00; Thu, 24 Jul 2003 21:35:03 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19frTw-0003jy-00; Thu, 24 Jul 2003 21:34:52 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6P1YIYG024028; Thu, 24 Jul 2003 21:34:18 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 21:34:15 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 21:34:14 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB48A@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Eddie Kohler'" , "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Date: Thu, 24 Jul 2003 21:34:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Eddie, See inline ... Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Thursday, July 24, 2003 6:10 PM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: Re: [dccp] One-way live media with DCCP/TFRC > > > > Note that, by my interpretation of TFRC at least, we won't be > > penalized for transmitting less than we could. You're only > penalized when > > you transmit nothing for some number of roundtrip times. > > My understanding is, you are not penalized -- you still get > to send at your > (allowed) rate -- but your maximum allowed transmit rate > doesn't continue > to increase. THe maximum allowed transmit rate is bounded > above by some > multiple of the current transmit rate. This is essentially > the same as in > the idle case. Oh, I missed this. So if the high rate is more than twice or so the low rate you'll have to slow-start up to it when you upshift, regardless of how low the RTT has become. I think that the scheme I described still works, though. You just have some transmit buffer buildup as the rate ramps up, like in slow-start at the beginning of the connection. > > > It might be useful for DCCP to tell the application about > rate changes. > > We absolutely want the API to take care of this. > > Eddie > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Jul 24 21:43:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08243 for ; Thu, 24 Jul 2003 21:43:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frbc-0001oO-Ta for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:42:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1gmWw006960 for mmusic-archive@odin.ietf.org; Thu, 24 Jul 2003 21:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frbc-0001oB-Qi for mmusic-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:42:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08228 for ; Thu, 24 Jul 2003 21:42:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frbZ-0003n7-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:42:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frbU-0003n4-00 for mmusic-web-archive@ietf.org; Thu, 24 Jul 2003 21:42:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frar-0001iP-T6; Thu, 24 Jul 2003 21:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fraH-0001f2-Kl for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 21:41:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08208; Thu, 24 Jul 2003 21:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fraE-0003mX-00; Thu, 24 Jul 2003 21:41:22 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19fra3-0003mF-00; Thu, 24 Jul 2003 21:41:11 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6P1ebYG024304; Thu, 24 Jul 2003 21:40:37 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 24 Jul 2003 21:40:35 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 21:40:34 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB48B@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Eddie Kohler'" , dccp@ietf.org, mmusic@ietf.org Cc: "Phelan, Tom" Date: Thu, 24 Jul 2003 21:40:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: Packet drop API / what happens with packet drops now? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Eddie, I actually think that there's a big advantage to throwing packets away at the sender, rather than having the network choose the packets to throw away, even if you end up discarding more packets that way. When the sender chooses the packets to discard, it can ensure that important packets (like frame markers, etc.) are preserved. The network simply makes random decisions. Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Thursday, July 24, 2003 6:21 PM > To: dccp@ietf.org; mmusic@ietf.org > Cc: tphelan@sonusnet.com > Subject: Packet drop API / what happens with packet drops now? > > > What happens in currently-deployed codecs when packets are dropped? > > Clearly codecs, and VoIP in particular, can handle loss. > Possibly even high > loss rates. One way to think about DCCP's allowed sending > rate is that it > moves drops that *would* have happened in the network > *anyway*, into the > sending host. (Although DCCP will generally drop more than the network > would have, to ensure fairness, and because of congestion-control > infelicities that we want to fix.) So how disastrous are these drops? > > Another way to put this: A DCCP API might never block -- or > it might block > for at most T seconds. Instead, writing a packet into a full > send buffer > would drop that packet; or it might drop an older packet---a > drop-from-head > send buffer; or it might drop the oldest packet with lowest priority > annotation. > > Now the app simply sees a loss rate, which DCCP will happily > report. For > codec switching, you can simply switch when the loss rate is > intolerably > high -- which you would have had to do anyway. > > How horrible would this be? > > Eddie > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 02:53:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26210 for ; Fri, 25 Jul 2003 02:53:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fwRf-0004d5-UQ for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 02:52:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P6qpXV017783 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 02:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fwRe-0004ck-H9 for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 02:52:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26200 for ; Fri, 25 Jul 2003 02:52:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fwRa-0005oS-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 02:52:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fwRV-0005oP-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 02:52:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fwQr-0004X1-U3; Fri, 25 Jul 2003 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fwPt-0004Vo-Je for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 02:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26169; Fri, 25 Jul 2003 02:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fwPp-0005nd-00; Fri, 25 Jul 2003 02:50:57 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19fwPZ-0005nJ-00; Fri, 25 Jul 2003 02:50:42 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6P6nYi8059056; Thu, 24 Jul 2003 23:49:34 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307250649.h6P6nYi8059056@coyote.icir.org> To: "Phelan, Tom" cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" In-Reply-To: Message from "Phelan, Tom" of "Thu, 24 Jul 2003 21:25:57 EDT." <4CF48720B6E9D4118D040060CF2074E9082BB488@sonusdc3.sonusnet.com> Date: Thu, 24 Jul 2003 23:49:34 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Tom, > If DCCP conflicts with an application's requirements, then the application > won't use it, whether DCCP is network friendly or not. Totally agree. And totally agree that we must figure out whether DCCP is really useful for two-way voice. But, for example, an application with a requirement "must achieve a minimum bandwidth" would not be appropriate for DCCP, because it requires non-TCP-friendly congestion control. Nothing that you have discussed is that far out, but some of it is getting far out enough that I wanted to make the concern explicit. (For instance, we've been talking about apps that can transmit only at a discrete set of rates---unless 0pps was one of those rates, such an app would have a minimum bandwidth requirement.) > Note that I think > that network-friendly reaction to congestion is absolutely one of my > application's requirements (my app is two-way voice). I hope that I can use > DCCP to get that, but I'm having difficulties making it work. Not that I've > given up hope, mind you. I think I've managed to work out reasonable ways > to use DCCP for similar, but not quite identical apps. And I intend to keep > trying for my app. > > I think it's very important for DCCP to know whether it's really useful for > two-way voice or not. All of the DCCP documents mention it as a primary > target application. Some people on this list might already know how to make > it work, but I don't yet, and I haven't seen anyone give a credible scheme > for it yet, so I'll keep trying. FYI I really appreciate this discussion!!! Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 08:56:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03589 for ; Fri, 25 Jul 2003 08:56:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g27K-0002EB-Qf for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 08:56:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PCuEh9008553 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 08:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g27K-0002Dr-Mi for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 08:56:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03572 for ; Fri, 25 Jul 2003 08:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g27E-00004h-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 08:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g278-00004O-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 08:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g269-00026y-MJ; Fri, 25 Jul 2003 08:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g25N-00026C-FQ for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 08:54:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03543; Fri, 25 Jul 2003 08:54:08 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g25L-00002u-00; Fri, 25 Jul 2003 08:54:11 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19g25B-00002X-00; Fri, 25 Jul 2003 08:54:01 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 28F6E55002; Fri, 25 Jul 2003 14:53:30 +0200 (MET DST) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id B603A19C48; Fri, 25 Jul 2003 14:53:29 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 6159319C46; Fri, 25 Jul 2003 14:53:29 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA12242; Fri, 25 Jul 2003 14:53:28 +0200 (MEST) To: Damon Lanphear Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 14:43:56 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 14:54:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] what is DCCP for? (was: natural DCCP sender-side API) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Damon, you write: > ?!? How does DCCP guarantee on time delivery? (let me first check something, I define "on time delivery" as: the amount of time its takes for data to transit from sender to receiver is constant. do you agree?) My understanding of DCCP is that it would tell the sender at which max rate to send. Then I assume that *if the sender does its part of the job*, (which is to abide by the max rate indicated by DCCP) then the system (application + DCCP) will run "in the best possible way" ... which is: *avoid congestion* (if DCCP does not do that, please change the name!-) ... which means on time delivery of data! so I conclude that DCCP "allows" on time delivery, right? ** the reason one could go from "allow" to "guarantee" would be (king of ad absurdum): I have been assuming (this is the "contract" I would wish DCCP to operate under) that when DCCP gives the sending rate indication it does so based on the *best possible knowledge about the network*. Therefore I would like to be able to assume that if the network "behavior" is such that even DCCP cannot fulfill the "contract" then *nothing* would do the job. In other words I am assuming that if an application strictly doing its job (strictly respecting the MAX send rate indicated by DCCP) does not get on time delivery ... then the application would "fail" in any case. (my definition of "fail" for streaming is: playback is interrupted) Am I putting irrealistic hopes in DCCP? but then what would it be good for? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 09:15:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03970 for ; Fri, 25 Jul 2003 09:15:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2PH-00034r-Na for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 09:14:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PDElEX011823 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 09:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2PH-00034c-KL for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 09:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03946 for ; Fri, 25 Jul 2003 09:14:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2PF-0000AP-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 09:14:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g2PA-0000AM-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 09:14:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2OX-0002yA-1L; Fri, 25 Jul 2003 09:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2Ng-0002wv-E2 for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 09:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03861; Fri, 25 Jul 2003 09:13:03 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2Ne-00009e-00; Fri, 25 Jul 2003 09:13:06 -0400 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 19g2NT-00009X-00; Fri, 25 Jul 2003 09:12:55 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id F3B676BE36; Fri, 25 Jul 2003 15:12:27 +0200 (MET DST) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 585DC19C49; Fri, 25 Jul 2003 15:12:27 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 03AAE19C46; Fri, 25 Jul 2003 15:12:26 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA20737; Fri, 25 Jul 2003 15:12:26 +0200 (MEST) To: Damon Lanphear Cc: dccp@ietf.org, mmusic@ietf.org, Mark Handley X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 15:02:50 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 15:13:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Damon, >> yes on advance warning about the TFRC rate, > >How can you ever get an advance warning about TFRC rate changes. These >changes are response to immediate stimuli, to my knowledge that are not >predicted by the current suite of algorithms. Yes. TFRC can update the rate computation everytime it receives feedback from the receiver. What I would like is that the sender application gets this information as soon as it is updated. this is the meaning of "advance warning" for me. I can use it to drive my media source (RT encoder or stream switch). It contrast sharply with a "blocking write" which is "too late" for me: once my source has produced a frame what I am supposed to do if DCCP blocks it ? garbage it ? wait? but how long should I wait? wait for what? for a timeout ? but what will happen after the timeout ? will I write this frame or not ? If I have to change the rate how am going to know which rate to choose ? etc ... on the other hand I would expect that DCCP never blocks a write if the source always follows the DCCP indicated rate .... regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 09:42:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04694 for ; Fri, 25 Jul 2003 09:42:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2pS-00043L-3E for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 09:41:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PDfocf015572 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 09:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2pR-00042s-VS for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 09:41:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04672 for ; Fri, 25 Jul 2003 09:41:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2pQ-0000LL-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 09:41:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g2pK-0000LI-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 09:41:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2oh-0003ww-2s; Fri, 25 Jul 2003 09:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2no-0003wA-32 for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 09:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04646; Fri, 25 Jul 2003 09:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2nl-0000Kg-00; Fri, 25 Jul 2003 09:40:05 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19g2nb-0000KZ-00; Fri, 25 Jul 2003 09:39:55 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6PDdJYG025666; Fri, 25 Jul 2003 09:39:19 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 25 Jul 2003 09:39:17 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 09:39:16 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB48C@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Eddie Kohler'" , "Phelan, Tom" Cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Date: Fri, 25 Jul 2003 09:39:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Eddie, See inline ... Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Friday, July 25, 2003 2:50 AM > To: Phelan, Tom > Cc: 'Damon Lanphear'; 'philippe.gentric@philips.com'; Magnus > Westerlund; > dccp@ietf.org; mmusic@ietf.org; Pasco Anderson, Jay > Subject: Re: [dccp] natural DCCP sender-side API: (was stream > switching) > > > > Hi Tom, > > > If DCCP conflicts with an application's requirements, then > the application > > won't use it, whether DCCP is network friendly or not. > > Totally agree. And totally agree that we must figure out > whether DCCP is > really useful for two-way voice. But, for example, an > application with a > requirement "must achieve a minimum bandwidth" would not be > appropriate for > DCCP, because it requires non-TCP-friendly congestion control. I think I'd rephrase that as "must achieve a minimum bandwidth and everyone else be damned would not be appropriate". > Nothing that you have discussed is that far out, but some of > it is getting > far out enough that I wanted to make the concern explicit. > (For instance, > we've been talking about apps that can transmit only at a > discrete set of > rates---unless 0pps was one of those rates, such an app would have a > minimum bandwidth requirement.) I haven't mentioned this in my e-mails so far because they were long enough without it, but I assume that when the TFRC rate falls below the minimum coding rate we throw away packets to shape the flow to the TFRC rate. As I said before, it seems better to me that the sender makes intelligent decisions about packet discard, rather than the network makes random decisions. Eventually you could get to the point that the media stream is completely unintelligible, and maybe you should disconnect. I certainly don't feel that you should keep blasting away at some minimum acceptable rate regardless of what happens to those packets in the network. > > > Note that I think > > that network-friendly reaction to congestion is absolutely one of my > > application's requirements (my app is two-way voice). I > hope that I can use > > DCCP to get that, but I'm having difficulties making it > work. Not that I've > > given up hope, mind you. I think I've managed to work out > reasonable ways > > to use DCCP for similar, but not quite identical apps. And > I intend to keep > > trying for my app. > > > > I think it's very important for DCCP to know whether it's > really useful for > > two-way voice or not. All of the DCCP documents mention it > as a primary > > target application. Some people on this list might already > know how to make > > it work, but I don't yet, and I haven't seen anyone give a > credible scheme > > for it yet, so I'll keep trying. > > FYI I really appreciate this discussion!!! > > Eddie > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 10:20:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06955 for ; Fri, 25 Jul 2003 10:20:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3QE-0005iy-3V for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:19:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PEJo0B022004 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:19:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3QE-0005ip-0T for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 10:19:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06916 for ; Fri, 25 Jul 2003 10:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3QB-0000bH-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:19:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g3Q6-0000bE-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:19:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3PR-0005bP-9Q; Fri, 25 Jul 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3OW-0005a0-MK for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 10:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06769; Fri, 25 Jul 2003 10:17:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3OT-0000ZP-00; Fri, 25 Jul 2003 10:18:01 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19g3OI-0000Ye-00; Fri, 25 Jul 2003 10:17:50 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19521; Fri, 25 Jul 2003 10:16:52 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29231; Fri, 25 Jul 2003 10:16:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1M5PJQ>; Fri, 25 Jul 2003 10:16:52 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C51@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" , "Phelan, Tom" Cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" Subject: RE: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Date: Fri, 25 Jul 2003 10:16:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The requirement is pretty easy to state: For two way voice, the data rate is quantized, and constant. You can tolerate some packet loss, which is in the percent or so range without problems, and some packets are more important than others. It takes some time to change rates. Delay is one of the most important parameters. Add any significant delay, and we can't use it. For video, the data rate can be less constant (ours is only slightly variable), there are more reasons to do sender marking of packets to be discarded, and delay is even more important. A nice characteristic you can use is that voice and video has the possibility of admission control. You can say that a transport protocol can't really directly deal with that, but at least at the moment, that's how you get a rate change, so the same mechanism can get you admission control. In the end, you either get an acceptable rate that you can send constant bit rates at, or you stop sending at all. I'm more sanguine about complexity. I'll tolerate some level of code complexity if I get something out of it. Let's face it, TCP-friendly isn't something that matters to me. Better experience for our users is. If TCP-friendly ultimately results in a better user experience, good. If it doesn't .... Brian > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Friday, July 25, 2003 2:50 AM > To: Phelan, Tom > Cc: 'Damon Lanphear'; 'philippe.gentric@philips.com'; Magnus > Westerlund; > dccp@ietf.org; mmusic@ietf.org; Pasco Anderson, Jay > Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream > switching) > > > Hi Tom, > > > If DCCP conflicts with an application's requirements, then > the application > > won't use it, whether DCCP is network friendly or not. > > Totally agree. And totally agree that we must figure out > whether DCCP is > really useful for two-way voice. But, for example, an > application with a > requirement "must achieve a minimum bandwidth" would not be > appropriate for > DCCP, because it requires non-TCP-friendly congestion control. > > Nothing that you have discussed is that far out, but some of > it is getting > far out enough that I wanted to make the concern explicit. > (For instance, > we've been talking about apps that can transmit only at a > discrete set of > rates---unless 0pps was one of those rates, such an app would have a > minimum bandwidth requirement.) > > > Note that I think > > that network-friendly reaction to congestion is absolutely one of my > > application's requirements (my app is two-way voice). I > hope that I can use > > DCCP to get that, but I'm having difficulties making it > work. Not that I've > > given up hope, mind you. I think I've managed to work out > reasonable ways > > to use DCCP for similar, but not quite identical apps. And > I intend to keep > > trying for my app. > > > > I think it's very important for DCCP to know whether it's > really useful for > > two-way voice or not. All of the DCCP documents mention it > as a primary > > target application. Some people on this list might already > know how to make > > it work, but I don't yet, and I haven't seen anyone give a > credible scheme > > for it yet, so I'll keep trying. > > FYI I really appreciate this discussion!!! > > Eddie > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 10:22:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07168 for ; Fri, 25 Jul 2003 10:22:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3S9-0005uZ-FO for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:21:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PELnF3022716 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:21:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3S9-0005uJ-Bv for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 10:21:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07152 for ; Fri, 25 Jul 2003 10:21:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3S6-0000cO-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:21:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g3S0-0000cL-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:21:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3RO-0005o9-GT; Fri, 25 Jul 2003 10:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3QU-0005je-VI for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 10:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06921; Fri, 25 Jul 2003 10:20:01 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3QS-0000bT-00; Fri, 25 Jul 2003 10:20:04 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19g3QH-0000an-00; Fri, 25 Jul 2003 10:19:53 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id B7322553F1; Fri, 25 Jul 2003 16:19:19 +0200 (MET DST) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 60ECE19C46; Fri, 25 Jul 2003 16:19:19 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 1672219C45; Fri, 25 Jul 2003 16:19:19 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA20342; Fri, 25 Jul 2003 16:19:18 +0200 (MEST) To: "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 16:10:07 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 16:20:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Tom, first thank you for this detailed and clear description of how a typical system would work! I agree it is useful to insist that streaming is about "seconds" rather than "bytes";-) I share your belief that the same scheme applies to one-way pre-recorded media. I also share your hope hat an application transmitting data *below* the TFRC rate is not penalized, because, as you demonstrate, this is what a streaming application will *have* to do. By the way can someone give a confirmation about that ? ***** one remark: you write: > ... when DCCP/TFRC has decided on a rate too low for the high rate >encoding the application could make the change to the low rate immediately. >This would work, but it might lead to unnecessary switches to the lower >rate. Let me give my interpretation of what "unnecessary switches to the lower rate" are. For me the "risk" (of reduced quality seen by the user) is the direct result of the congestion control policy. TFRC is already designed to give you a rate that changes in a "less drastic" manner than TCP divide-by-two, and in general to give "smoother" rate variations etc... In other words, if I dont like the risk associated with using a given congestion control (say TRFC) the right thing to do should be to design another one, no? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 10:32:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07628 for ; Fri, 25 Jul 2003 10:32:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3bq-0006NL-6I for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:31:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PEVoph024503 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:31:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3bo-0006Mq-MG for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 10:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07584 for ; Fri, 25 Jul 2003 10:31:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3bl-0000i6-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:31:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g3bg-0000i3-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:31:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3b3-0006Gz-R2; Fri, 25 Jul 2003 10:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3aD-0006Ec-H2 for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 10:30:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07487; Fri, 25 Jul 2003 10:30:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3aB-0000hF-00; Fri, 25 Jul 2003 10:30:07 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19g3a0-0000gW-00; Fri, 25 Jul 2003 10:29:56 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6PET2YG028820; Fri, 25 Jul 2003 10:29:02 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 25 Jul 2003 10:28:59 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 10:28:58 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB48D@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" , "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" Date: Fri, 25 Jul 2003 10:28:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Philippe, From an e-mail from Eddie it appears that I wasn't totally correct that there's no penalty for sending below the maximum rate, but I don't think it changes my scheme. From what Eddie said, and from looking at the TFRC RFC again, I think that while you're sending below the TFRC max rate the max rate doesn't grow (even if it could). So if you want to now increase your sending rate, the maximum you can send in the next RTT is twice what you just sent, regardless of how low the RTT is. You need to slow-start up to the rate that you could have been sending if you were greedy. Tom P. > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Friday, July 25, 2003 10:10 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org' > Subject: Re: [dccp] One-way live media with DCCP/TFRC > > > Tom, > > first thank you for this detailed and clear description of > how a typical system would work! > > I agree it is useful to insist that streaming is about > "seconds" rather than "bytes";-) > > I share your belief that the same scheme applies to one-way > pre-recorded media. > > I also share your hope hat an application transmitting data > *below* the TFRC rate is not penalized, > because, as you demonstrate, this is what a streaming > application will *have* to do. > By the way can someone give a confirmation about that ? > > ***** > one remark: > > you write: > > > ... when DCCP/TFRC has decided on a rate too low for the high rate > >encoding the application could make the change to the low > rate immediately. > >This would work, but it might lead to unnecessary switches > to the lower > >rate. > > Let me give my interpretation of what "unnecessary switches > to the lower rate" are. > > For me the "risk" (of reduced quality seen by the user) is > the direct result of the congestion control policy. > > TFRC is already designed to give you a rate that changes in a > "less drastic" manner than TCP divide-by-two, > and in general to give "smoother" rate variations etc... > > In other words, if I dont like the risk associated with using > a given congestion control > (say TRFC) the right thing to do should be to design another one, no? > > > regards, > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 10:49:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08135 for ; Fri, 25 Jul 2003 10:49:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3sF-00079H-TF for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:48:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PEml7a027471 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 10:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3sF-00078r-PY for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 10:48:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08114 for ; Fri, 25 Jul 2003 10:48:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3sC-0000pD-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:48:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g3s7-0000pA-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 10:48:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3rU-00070u-Sp; Fri, 25 Jul 2003 10:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3ql-0006zB-DW for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 10:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08047; Fri, 25 Jul 2003 10:47:08 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3qi-0000ns-00; Fri, 25 Jul 2003 10:47:12 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19g3qX-0000nm-00; Fri, 25 Jul 2003 10:47:01 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id EC70254ECC; Fri, 25 Jul 2003 16:46:55 +0200 (MET DST) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 8832F19C49; Fri, 25 Jul 2003 16:46:55 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 4099F19C46; Fri, 25 Jul 2003 16:46:55 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA01090; Fri, 25 Jul 2003 16:46:54 +0200 (MEST) To: Eddie Kohler Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 16:37:42 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 16:48:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] Using DCCP for VoIP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 all, > >On this issue: > >> IMHO this issue is related to my question in the other mail about >> managing audio AND video at the same time: probably DCCP should have a >> way to handle "collectively" a bunch of streams, be it audio plus video >> or two-way audio! > >Our thought was that, given DCCP's unreliability, it is trivial to layer >multiple streams on top. The first byte of packet data could indicate >stream number to the application. This works as long as both streams want >to share the same congestion control state + CC mechanism -- is this the >case? a multiplex? (that would clash rather badly with the idea that RTP can be mapped trivially using the port numbers !-) One thing is sure, I have questions about how it would work with multiple DCCP "sessions": If DCCP is running 2 sessions from host A to host B, and at a given time DCCP tells *each* session "you have 200 kb/s" => does it mean the available bandwidth is 400 kb/s ? but then the application could prefer to allocate +50 kb/s to audio and +350 kb/s to video ... => or does it mean the total is 200 kb/s? but then DCCP would have to assume that the 2 sessions are correctly managed (linked/grouped) so that they dont "fight" for it, right? otherwise what a mess! So the need is rather for a "grouping", like the API would enable the application to tell DCCP: "these are 2 (or more) streams, but it is a single CC "session", i.e. give me a single rate for the group I will do the repartition". (same spirit as RTSP aggregate control) regards Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 11:09:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08682 for ; Fri, 25 Jul 2003 11:09:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Bk-00006H-20 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:08:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PF8uL2000379 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:08:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Bj-000062-UN for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:08:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08672 for ; Fri, 25 Jul 2003 11:08:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Bh-0000x0-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:08:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4Bb-0000wu-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:08:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Ar-0008SV-2X; Fri, 25 Jul 2003 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4AK-0008Ja-Ul for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 11:07:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08653 for ; Fri, 25 Jul 2003 11:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4AF-0000wa-00 for mmusic@ietf.org; Fri, 25 Jul 2003 11:07:23 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19g4A4-0000wP-00 for mmusic@ietf.org; Fri, 25 Jul 2003 11:07:12 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6PF6ljG013047 for ; Fri, 25 Jul 2003 17:06:47 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6LH7Z0; Fri, 25 Jul 2003 17:10:05 +0200 Message-ID: <3F214784.2030804@ericsson.com> Date: Fri, 25 Jul 2003 17:06:44 +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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here is my comments on this draft. 1. As a WG draft you should have the short copyright statement and not only the long one at the end of the draft. 2. In section 1 I would like that you clarify that RFC 2828 contains security terminology. 3. Section 3.1. This section needs to be improved. As I understand it the a=crypto attribute can be used with any transport and media. Therefore the section should not start with defining that this defines the value for RTP/SAVP. The actual crypto suits will be required to be registered and defined for each individual transport. There might in fact be even further restrictions that apply to future crypto suits. 4. Section 3.4, I think the session parameters are actually specific to the crypto suit, primarily. Secondarily it can be dependent on more things. 5. Section 3 and 4. In general I think the basic definition of the a=crypto attribute can be more cleanly separated from the specific application for SRTP. 6. Section 4.1, Is usage of multiple a=crypto lines allowed. IF yes this section contradict this. 7. Section 4.1.4, last sentence: How can one add a new name that is identical and still carry any difference. Please reword. 8. Section 4.2, I think there is a large shortcoming regarding the uri: parameter. I think one must clearly define the format one retrieves the keys when using the URI. Of course this format can be crypto suit dependent. 9. Section 4.3.1, second and third paragraph. I think the definition of the SSRC, ROC, SEQ, could be better done. As I understand it any of the three is sufficient, why not express it that way. Then one MAY have the parameter anyway. 10. Section 5.4, second paragraph: I think the limitation you would like to declare here needs some discussion. First you forbid the usage of multiple m= lines on the same port, after last weeks discussion I don't know if this is acceptable, at least not without further motivation. I would also write some recommendations/considerations regarding grouping of media lines here. 11. Section 5.7, I am not certain that session parameters can't be restrained from being changed. For example the SRC (ROC) parameter seems one that might need to be included and changed in an offer for rekeying. Are there any synchronization problem that can arise when doing rekeying? There seems to be need to define from what seq the new key are valid. 12. When it comes to SRTPs protection mechanism it seems necessary to be able to define the window size using the a=crypto parameter. There are a lot of difference between a uncompressed video stream running at a couple of hundreds of Mbyte/s using 100 000 packets each second. This will require a much larger window then a 64 kbit stream that sends 15 packets every second. 13. Section 6.1 First paragraph, last sentence. The attack is only avoided if there is one master key per SSRC, not media stream. I think that there is some ambiguity in the use of media stream, which needs to be clarified to avoid misunderstanding. 14. Section 6.2, second paragraph, first sentence: The attribute is crypto not SRTP as it says in the text. 15. Section 7.: The ABNF does not define the extension space. For example the crypto-suite definition should have an extra alternative crypto-suit-extension which is VCHAR. I think the whole ABNF needs to be thought through to be more complete in the extension sense. 16. Section 7. Why have the 2^ optional value if it does not matter. Please simplify this. 17. Section 7, The absolute URI should not rely only on RFC 2396, there is an extension to that document, please see RFC 2732. 18. Last page, has not the normal number of lines. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 11:11:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08762 for ; Fri, 25 Jul 2003 11:11:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4DX-0000HZ-FS for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:10:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFAlx1001079 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:10:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4DX-0000HK-AC for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:10:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08737 for ; Fri, 25 Jul 2003 11:10:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4DU-0000yX-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:10:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4DP-0000yU-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:10:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Cn-00009c-3o; Fri, 25 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Cf-000099-GM for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 11:09:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08700; Fri, 25 Jul 2003 11:09:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Cc-0000xU-00; Fri, 25 Jul 2003 11:09:50 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19g4CN-0000xE-00; Fri, 25 Jul 2003 11:09:35 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6PF94i8061604; Fri, 25 Jul 2003 08:09:04 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307251509.h6PF94i8061604@coyote.icir.org> To: philippe.gentric@philips.com cc: Damon Lanphear , dccp@ietf.org, mmusic@ietf.org In-Reply-To: Message from philippe.gentric@philips.com of "Fri, 25 Jul 2003 14:43:56 +0200." Date: Fri, 25 Jul 2003 08:09:04 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] what is DCCP for? (was: natural DCCP sender-side API) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Phillipe > Then I assume that *if the sender does its part of the job*, > (which is to abide by the max rate indicated by DCCP) > then the system (application + DCCP) will run "in the best possible way" > ... > which is: *avoid congestion* > (if DCCP does not do that, please change the name!-) > ... > which means on time delivery of data! DCCP traffic is still best effort traffic. Best effort traffic must expect loss. That's the only way the network can signal congestion currently. (DCCP will then avoid congestion *collapse* by backing off its send rate.) Furthermore, there may be variable delay, depending on the network. There is no magic "do not drop or delay my packets" button in the Internet today. Except that when ECN is deployed in routers, DCCP packets will get marked when UDP packets would get dropped. > Am I putting irrealistic hopes in DCCP? Yes. DCCP cannot predict congestion in the network. It sounds like you want intserv (a guaranteed bandwidth reservation). You can get some of what you want, in that DCCP will tell the app the best rate it is currently allowing, and if that's not good enough, your app can quit. Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 11:49:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09923 for ; Fri, 25 Jul 2003 11:49:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4oq-0002VQ-AL for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:49:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFnK7N009626 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4oq-0002VB-7J for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09847 for ; Fri, 25 Jul 2003 11:49:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4op-0001Kc-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:49:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4oo-0001KZ-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:49:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4oX-0002PO-Rh; Fri, 25 Jul 2003 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4o5-0002OV-GX for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 11:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09806; Fri, 25 Jul 2003 11:48:27 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4o2-0001K8-00; Fri, 25 Jul 2003 11:48:30 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19g4o2-0001K5-00; Fri, 25 Jul 2003 11:48:30 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id F3DE054C50; Fri, 25 Jul 2003 17:48:27 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 8FDE519C49; Fri, 25 Jul 2003 17:48:27 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 41CF819C45; Fri, 25 Jul 2003 17:48:27 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA16719; Fri, 25 Jul 2003 17:48:26 +0200 (MEST) To: Mark Handley Cc: dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 17:39:15 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 17:49:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Mark, >>What will happen if an application "does not use" the >>bandwidth indicated by TFRC? > >OK, my assumption here was that streaming media was coming from disk. >Thus you can always send faster then the receiver is consuming. I am not sure about what you mean by "always" but what I am sure is that it cannot be "all the time": specifically you can do that up to the moment when your client side buffer is full, because a media decoder is not regulated on a *data* rate but on *media time*... so if you send data faster than the media rate you fill up the client buffer ... (which brings back the previous conclusion that pre-recorded media is not that much different than one-way "live") regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 11:52:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10070 for ; Fri, 25 Jul 2003 11:52:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4ri-0002eg-PB for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:52:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFqIqb010200 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 11:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4ri-0002eR-LL for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10048 for ; Fri, 25 Jul 2003 11:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4rh-0001Nt-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:52:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4rg-0001Nq-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 11:52:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4rS-0002c5-3l; Fri, 25 Jul 2003 11:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4qq-0002bT-D3 for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 11:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09997 for ; Fri, 25 Jul 2003 11:51:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4qp-0001ND-00 for mmusic@ietf.org; Fri, 25 Jul 2003 11:51:23 -0400 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 19g4qo-0001Mf-00 for mmusic@ietf.org; Fri, 25 Jul 2003 11:51:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP and mobility Date: Fri, 25 Jul 2003 17:52:43 +0200 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B90949B0658A@swing.cefriel.it> Thread-Topic: [MMUSIC] RTSP and mobility Thread-Index: AcNQcWktXaWkC0YvTXKBkf3nwVYaGwCM7BVQ From: "Enrico Balatti" To: Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Ashutosh, thank you for you quickly reply. I tried to implement what the paper says about RTSP mobility. The Client now send the SETUP after the handoff, but the RTSP server (Darwin Streaming Server) doesn't respond with any message. Looking the Server source code I think that the Server doesn't accept the incoming SETUP message because it doesn't belong to any opend RTSP session (it is like there is a relation between=20 the session and the transport socket and the session accepts packet from its client socket). Therefore if the packet arrive with a source=20 address different (due to mobility), the packet is rejected. I don't know if this mean that the Server is not RTSP standard = compliant. Do you know where the RTSP specification=20 talks about the RTSP application-mobility? Thanks, Enrico -----Original Message----- From: Ashutosh Dutta [mailto:adutta@research.telcordia.com] Sent: marted=EC 22 luglio 2003 18.49 To: Enrico Balatti Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility=20 Enrico, please see the paper =20 http://www.cs.columbia.edu/~hgs/papers/Schu0007_Application.pdf, it talks about some issues related to RTSP and mobility when IP address changes on the mobile because of subnet movement or domain movement. Thanks Ashutosh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 12:20:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10959 for ; Fri, 25 Jul 2003 12:20:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5Ip-0004e4-0n for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:20:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PGKIUc017852 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5Io-0004dr-Sz for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 12:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10937 for ; Fri, 25 Jul 2003 12:20:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5In-0001co-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:20:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g5Im-0001cl-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:20:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5IY-0004aF-5n; Fri, 25 Jul 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5Hu-0004X4-4m for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 12:19:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10898; Fri, 25 Jul 2003 12:19:15 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5Hr-0001c9-00; Fri, 25 Jul 2003 12:19:19 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19g5Hq-0001c6-00; Fri, 25 Jul 2003 12:19:18 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id E6CD654997; Fri, 25 Jul 2003 18:19:17 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 6FBCD19C48; Fri, 25 Jul 2003 18:19:17 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 1B07A19C45; Fri, 25 Jul 2003 18:19:17 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA21154; Fri, 25 Jul 2003 18:19:16 +0200 (MEST) To: "'dccp@ietf.org'" Cc: "'mmusic@ietf.org'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 18:10:05 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 18:20:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RE: [dccp] rapid rate change codecs (was ... something else!) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, Tom, Eddie, (just sending to the lists now, getting too many duplicates!) >Hi Philippe, > >From an e-mail from Eddie it appears that I wasn't totally correct that >there's no penalty for sending below the maximum rate, but I don't think it >changes my scheme. > >From what Eddie said, and from looking at the TFRC RFC again, I think that >while you're sending below the TFRC max rate the max rate doesn't grow (even >if it could). So if you want to now increase your sending rate, the maximum >you can send in the next RTT is twice what you just sent, regardless of how >low the RTT is. You need to slow-start up to the rate that you could have >been sending if you were greedy. > >Tom P. Yes, it means that the application will have to "probe" by sending data at the TFRC rate, which in turn means oscillating between * sending a "low" media rate too fast (which will fill up the player buffers) * sending a "high" media rate too slow (which will deplete the player buffers) to keep a constant buffer at the receiver. (Damon: you were right, DCCP is not any progress here, we will still need to monitor the receiver buffers as we do now !-) for media delivery (large buffers) this is ok (assuming you have the capability to switch etc ..;-) Unfortunately for very small buffers (i.e. small delay, VoIP) that means switching *VERY often*! I think it leads to the conclusion that DCCP for VoIP is useful with codecs for which the rate can be changed very often with no penalty ? This would be OK for voice (with AMR, EVRC etc) but maybe not so much for video? >> Am I putting irrealistic hopes in DCCP? > >Yes. DCCP cannot predict congestion in the network. Actually that part is ok: DCCP will tell the sender to reduce the rate, give it a new target, this is good. > >You can get some of what you want, in that DCCP will tell the app the best >rate it is currently allowing ... Ah, but finally the irrealistic hope I was putting in DCCP is discovered: DCCP can not tell the application when to increase its rate unless the application "probes" the network first by ... increasing its rate. But one who has the right codecs can live with that ;-) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 12:33:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11366 for ; Fri, 25 Jul 2003 12:33:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5VT-0005S7-Kc for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:33:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PGXNOw020953 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5VE-0005RV-GW for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 12:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11257 for ; Fri, 25 Jul 2003 12:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5RX-0001jV-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:29:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g5RW-0001jS-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:29:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5RG-0005IB-Hd; Fri, 25 Jul 2003 12:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5R7-0005GX-Bs for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 12:28:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11228; Fri, 25 Jul 2003 12:28:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5QW-0001ih-00; Fri, 25 Jul 2003 12:28:16 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19g5QT-0001g6-00; Fri, 25 Jul 2003 12:28:13 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Fri, 25 Jul 2003 09:26:33 -0700 From: Damon Lanphear To: "Phelan, Tom" Cc: "'Eddie Kohler'" , dccp@ietf.org, mmusic@ietf.org In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB48B@sonusdc3.sonusnet.com> References: <4CF48720B6E9D4118D040060CF2074E9082BB48B@sonusdc3.sonusnet.com> Message-Id: <1059150183.13194.6.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 25 Jul 2003 09:23:04 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] RE: Packet drop API / what happens with packet drops now? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Tom. I think that rather than dropping packets on write in the sending DCCP, you'd want to block and let the app decide whether the blocked packet should be queued in the app or dropped. One of the things we can do for live unidirectional media, as an example, is prune an app layer queue to smoothly degrade perceptual distortion based on a prioritization scheme. On Thu, 2003-07-24 at 18:40, Phelan, Tom wrote: > Hi Eddie, > > I actually think that there's a big advantage to throwing packets away at > the sender, rather than having the network choose the packets to throw away, > even if you end up discarding more packets that way. When the sender > chooses the packets to discard, it can ensure that important packets (like > frame markers, etc.) are preserved. The network simply makes random > decisions. > > Tom P. > > > -----Original Message----- > > From: Eddie Kohler [mailto:kohler@icir.org] > > Sent: Thursday, July 24, 2003 6:21 PM > > To: dccp@ietf.org; mmusic@ietf.org > > Cc: tphelan@sonusnet.com > > Subject: Packet drop API / what happens with packet drops now? > > > > > > What happens in currently-deployed codecs when packets are dropped? > > > > Clearly codecs, and VoIP in particular, can handle loss. > > Possibly even high > > loss rates. One way to think about DCCP's allowed sending > > rate is that it > > moves drops that *would* have happened in the network > > *anyway*, into the > > sending host. (Although DCCP will generally drop more than the network > > would have, to ensure fairness, and because of congestion-control > > infelicities that we want to fix.) So how disastrous are these drops? > > > > Another way to put this: A DCCP API might never block -- or > > it might block > > for at most T seconds. Instead, writing a packet into a full > > send buffer > > would drop that packet; or it might drop an older packet---a > > drop-from-head > > send buffer; or it might drop the oldest packet with lowest priority > > annotation. > > > > Now the app simply sees a loss rate, which DCCP will happily > > report. For > > codec switching, you can simply switch when the loss rate is > > intolerably > > high -- which you would have had to do anyway. > > > > How horrible would this be? > > > > Eddie > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 12:46:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11805 for ; Fri, 25 Jul 2003 12:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5hv-0006Nu-Os for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:46:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PGkFcF024536 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5hl-0006NM-LA for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 12:46:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11668 for ; Fri, 25 Jul 2003 12:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5e4-0001ou-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:42:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g5e3-0001or-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:42:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5dp-0006BB-Jz; Fri, 25 Jul 2003 12:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5dD-00068W-AU for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 12:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11625; Fri, 25 Jul 2003 12:40:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5cm-0001oB-00; Fri, 25 Jul 2003 12:40:56 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19g5cl-0001ny-00; Fri, 25 Jul 2003 12:40:55 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Fri, 25 Jul 2003 09:40:22 -0700 From: Damon Lanphear To: Eddie Kohler Cc: dccp@ietf.org, mmusic@ietf.org In-Reply-To: <200307242158.h6OLwki8056056@coyote.icir.org> References: <200307242158.h6OLwki8056056@coyote.icir.org> Message-Id: <1059151044.13194.20.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 25 Jul 2003 09:37:24 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] What's wrong with TFRC for VoIP and other apps? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Eddie, I would add that when ECN is not available loss becomes a considerable factor that bounds the TFRC rate. The TFRC algorithm periodically touches the upper bounds of the link capacity, at which point loss is induced, and the algorithm decreases the rate. The result is periodic distortion. This distortion can be mitigated through a resend mechanism. But when you combine a resend mechanism with adherence to the TFRC rate, you get a more complicated solution. You have to define a trade off between delay for satisfying resends and minimizing distortion. Of course, congestion induced loss is a fact of life in the best effort internet. But we can at least define a way by which TFRC can further minimize periodic loss. I understand that TFRC as it is currently defined has been designed to significantly dampen periodic oscillations. I think, however, that we may want to go a step further and say that TFRC can optionally limit itself to some maximum rate, that may vary over the duration of the session, but is defined by the application. The intent in doing so is to obviate the requirement that TFRC constantly push against an unknown upper bounds. So unless congestion causes the upper bound to be close to the defined maximal rate, periodic loss will be eliminated. If the maximal rate is close to the link rate (due to congestion, or otherwise) then we are no better off than before. But at least there is an opportunity to specifically provision sessions for known media rates. On Thu, 2003-07-24 at 14:58, Eddie Kohler wrote: > Hi all, > > I just wanted to try to summarize the issues people have brought up, in > other threads, about why TFRC and/or DCCP will be inappropriate for VoIP > and other apps. I agree with Tom Phelan's comment that the biggest issues > have to do with TFRC, not the API. I've left off the solutions people have > proposed to these problems. > > 1. Rate slows down during idle periods > > The TFRC allowed sending rate will drop down to something very small > (2-4 packets/RTT) when the sender is idle. This may cause problems > particualrly with VoIP conversations, which are naturally idle-one-way > then idle-the-other-way. The rampup from the small rate to the fair rate > may take several to many RTTs, ouch. > > 2. Rate will not increase during app-limited period > > This is essentially the same problem as above. Say the application is > sending at rate R. The allowed rate will not increase much beyond R > (say, more than 2R) until the app transmits at a faster rate. > > 3. Apps with fixed sets of rates > > An app might have a discrete set of sending rates. Must it send at the > highest app rate <= the TFRC allowed rate? Would be very nice to allow > some flexibility, so that it could send at, say, the highest rate <= > 1.8*TFRC_allowed_rate. > > 4. Rate changes/oscillations > > There are application costs, possibly significant ones, associated with > changing rates. If the app has to change its rate frequently, because of > CC, that's a problem. > > Have I missed anything? > > Eddie > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 12:58:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12251 for ; Fri, 25 Jul 2003 12:58:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5tb-0006sb-0p for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:58:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PGwIWR026439 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 12:58:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5ta-0006sM-Tt for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 12:58:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12224 for ; Fri, 25 Jul 2003 12:58:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5tZ-0001uc-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:58:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g5tY-0001uZ-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 12:58:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5tJ-0006no-E5; Fri, 25 Jul 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5sT-0006iG-4l for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 12:57:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12213; Fri, 25 Jul 2003 12:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5sR-0001uO-00; Fri, 25 Jul 2003 12:57:07 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19g5sQ-0001uL-00; Fri, 25 Jul 2003 12:57:06 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by goodfellas.real.com with esmtp; Fri, 25 Jul 2003 09:56:32 -0700 From: Damon Lanphear To: "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB486@sonusdc3.sonusnet.com> References: <4CF48720B6E9D4118D040060CF2074E9082BB486@sonusdc3.sonusnet.com> Message-Id: <1059152018.13196.37.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 25 Jul 2003 09:53:38 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [dccp] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom, Great way to frame this problem. I like this approach. I have one apprehension: On Thu, 2003-07-24 at 12:26, Phelan, Tom wrote: At this point (perhaps after a slight delay) the sender can switch back to > the higher rate. If the new rate can't be sustained the transmit buffer > will fill again (and the playout buffer will drain). When the switch > encoding threshold is reached the sender goes back to the lower encoding > rate. This oscillation continues until the stream ends or the network is > able to support the high rate for the long term. I think we'd like to avoid the oscillation you describe. Or at least extend the period over which it can occur. But that all comes down to understand the impact of the oscillation on the subjective experience of the user. If we're delivering video, and there is a perceivable difference in the distortion of the high and low rates, then switching back and forth over even 20s intervals could be truly annoying. I think of this oscillation problem as being kind of like that which we encounter with congestion control algorithms. Where there is some unknown upper bounds against which we have to test periodically at a cost. I'm not sure what a good solution is. I think whatever solution is put forward will have to be dependent on the attributes of the media, and perhaps tie upshift attempts to a combination of buffer state and some measure of stability of the upper bounds rate. On Thu, 2003-07-24 at 12:26, Phelan, Tom wrote: > Hi, > > I've been continuing to think about the one-way live media case and have > come up with the following scheme for using DCCP with TFRC. Recall that > one-way live differs from one-way pre-recorded media by having a max > possible sending rate equal to the encoding rate (except for very short > bursts, perhaps), and differs from two-way interactive media by being > tolerant of delay. > > So, for this scheme we have a playout buffer at the receiver and transmit > buffer at the sender. Note that these buffers contain media streams, not > packets, and their lengths are measured in seconds, not bytes or packets. > > The transmit buffer is filled at the encoding rate and drained at the TFRC > transmit rate. The playout buffer is filled at the network arrival rate and > drained at the decoding rate. The playout buffer has a playback start > threshold and the transmit buffer has a "switch encoding" threshold. These > thresholds are on the order of a few to several seconds and switch encoding > is less than playback start. > > Assume that the encoder can encode at two rates, a high rate and a low rate. > At the start of a connection, the sender places data into the transmit > buffer at the high encoding rate. The buffer is drained at the TFRC rate, > which at this point is in slow-start and is probably slower than the > required rate. This will cause a backup in the transmit buffer. Eventually > TFRC will slow-start to a rate slightly above the rate necessary to sustain > the encoding rate. When this happens the transmit buffer will drain and > we'll reach a steady-state condition where the transmit buffer is empty and > we're transmitting at a rate that is probably below the maximum allowed by > TFRC. Note that, by my interpretation of TFRC at least, we won't be > penalized for transmitting less than we could. You're only penalized when > you transmit nothing for some number of roundtrip times. > > Meanwhile at the receiver, the playout buffer is filling, and when it > reaches the playback start threshold playback will start. After TFRC > slow-start and the transmit buffer is drained, this buffer will reach a > steady state where packets are arriving from the network at the encoding > rate (ignoring jitter) and being drained from the buffer at the (equal) > decoding rate. The depth of the buffer will be the playback start threshold > plus the maximum depth of the transmit buffer during slow start. > > Now assume that network congestion forces TFRC to drop its rate to below > that needed by the high rate encoding. The transmit buffer will begin to > fill and the playout buffer will begin to drain. When the transmit buffer > reaches the switch encoding threshold, the sender switches to the low rate > encoding, and converts all of the data in the transmit buffer to low rate > encoding. I'll ignore issues of how to do this efficiently, but it's > important not to discard this data, and to convert it. > > Assuming that the network can support the new, lower, rate (and a little > more) the transmit buffer will begin to drain and the playout buffer will > begin to fill. Eventually the transmit buffer will empty, the playout > buffer will be back to its steady-state level, and we'll be transmitting > data at the new, lower, encoding rate. > > At this point (perhaps after a slight delay) the sender can switch back to > the higher rate. If the new rate can't be sustained the transmit buffer > will fill again (and the playout buffer will drain). When the switch > encoding threshold is reached the sender goes back to the lower encoding > rate. This oscillation continues until the stream ends or the network is > able to support the high rate for the long term. > > It might be useful for DCCP to tell the application about rate changes. For > instance, when DCCP/TFRC has decided on a rate too low for the high rate > encoding the application could make the change to the low rate immediately. > This would work, but it might lead to unnecessary switches to the lower > rate. In particular, when DCCP decides on a new rate, it has no way of > knowing whether this is a transient or a long-term change. If it's > transient the transmit buffer might be able to absorb the problem, and a > change to the lower rate might unnecessarily reduce the quality seen by the > user. If we wait for the switch encoding threshold we can be more sure that > the rate change is long-term. Also, if we rely on rate indications for the > downshift, we need to ignore it during slow-start. > > It might be more useful to know when DCCP has raised the rate sufficiently > to switch to the high rate (after the transmit buffer has been drained). > > Note that this scheme is also suitable for one-way pre-recorded media, as > long as the transmit buffer is only filled at the encoding rate, not at the > disk read rate. Overall I'd say that this is better than the previous > scheme (for one-way pre-recorded media), and I think that some of the > commenters on the previous message must have had something like this in > mind. > > I still don't know how to do the two-way interactive media. > > Tom P. > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 13:05:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12624 for ; Fri, 25 Jul 2003 13:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g60N-0007SS-0O for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 13:05:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PH5IST028664 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 13:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g60M-0007SF-Tn for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 13:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12559 for ; Fri, 25 Jul 2003 13:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g60L-00020b-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 13:05:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g60K-00020Y-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 13:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g606-0007Kg-9M; Fri, 25 Jul 2003 13:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5z8-0007JL-HV for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 13:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12500; Fri, 25 Jul 2003 13:03:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5z5-0001zG-00; Fri, 25 Jul 2003 13:03:59 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19g5z4-0001yy-00; Fri, 25 Jul 2003 13:03:59 -0400 Received: from poesis.dev.prognet.com ([::ffff:172.23.22.105]) by capefear.real.com with esmtp; Fri, 25 Jul 2003 10:03:25 -0700 Subject: Re: [MMUSIC] RE: [dccp] rapid rate change codecs (was ... something else!) From: Damon Lanphear To: philippe.gentric@philips.com Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" In-Reply-To: References: Message-Id: <1059152430.13194.42.camel@poesis.dev.prognet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.0 Date: 25 Jul 2003 10:00:30 -0700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline: On Fri, 2003-07-25 at 09:10, philippe.gentric@philips.com wrote: > Hi, Tom, Eddie, > > (just sending to the lists now, getting too many duplicates!) > > >Hi Philippe, > > > >From an e-mail from Eddie it appears that I wasn't totally correct that > >there's no penalty for sending below the maximum rate, but I don't think it > >changes my scheme. > > > >From what Eddie said, and from looking at the TFRC RFC again, I think that > >while you're sending below the TFRC max rate the max rate doesn't grow (even > >if it could). So if you want to now increase your sending rate, the maximum > >you can send in the next RTT is twice what you just sent, regardless of how > >low the RTT is. You need to slow-start up to the rate that you could have > >been sending if you were greedy. > > > >Tom P. > > Yes, it means that the application will have to "probe" by sending data at the TFRC rate, > which in turn means oscillating between > * sending a "low" media rate too fast (which will fill up the player buffers) > * sending a "high" media rate too slow (which will deplete the player buffers) > to keep a constant buffer at the receiver. > > (Damon: you were right, DCCP is not any progress here, > we will still need to monitor the receiver buffers as we do now !-) > > for media delivery (large buffers) this is ok (assuming you have the capability to switch etc ..;-) > > Unfortunately for very small buffers (i.e. small delay, VoIP) that means switching *VERY often*! > > I think it leads to the conclusion that DCCP for VoIP is useful with codecs > for which the rate can be changed very often with no penalty ? > > This would be OK for voice (with AMR, EVRC etc) but maybe not so much for video? Yes. Video quality oscillation is going to be a big bad problem. Unless we have truly wonderful codecs with very fine grained scalability (which I understand are very expensive in terms of rate efficiency), we have to live with potentially annoying oscillations over relatively short timescales. So any robust video solution that uses TFRC and media adaptation will have provide a way to exchange potential for oscillation/maximization of quality vs. stability/lowest common denominator quality. > > > > >> Am I putting irrealistic hopes in DCCP? > > > >Yes. DCCP cannot predict congestion in the network. > > Actually that part is ok: DCCP will tell the sender to reduce the rate, > give it a new target, this is good. > > > > >You can get some of what you want, in that DCCP will tell the app the best > >rate it is currently allowing ... > > Ah, but finally the irrealistic hope I was putting in DCCP is discovered: > DCCP can not tell the application when to increase its rate unless > the application "probes" the network first by ... increasing its rate. > > But one who has the right codecs can live with that ;-) > > 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 -- Damon Lanphear _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 13:15:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12930 for ; Fri, 25 Jul 2003 13:15:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6A4-00086s-1B for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 13:15:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PHFJfM031168 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 13:15:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6A2-00086d-Gt for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 13:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12888 for ; Fri, 25 Jul 2003 13:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6A0-00025f-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 13:15:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g6A0-00025c-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 13:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g69l-000829-GY; Fri, 25 Jul 2003 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g69H-0007yv-So for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 13:14:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12872; Fri, 25 Jul 2003 13:14:25 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g69F-00024y-00; Fri, 25 Jul 2003 13:14:30 -0400 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 19g69E-00024v-00; Fri, 25 Jul 2003 13:14:29 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl6.philips.com (Postfix) with ESMTP id C7B3C5D321; Fri, 25 Jul 2003 19:14:27 +0200 (MET DST) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 09F8A19C4C; Fri, 25 Jul 2003 19:14:26 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id A568819C46; Fri, 25 Jul 2003 19:14:25 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA26758; Fri, 25 Jul 2003 19:14:25 +0200 (MEST) Subject: Re: [MMUSIC] delay API (was: Packet drop API / what happens with packet drops now?) To: dccp@ietf.org Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 25 Jul 2003 19:05:14 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/07/2003 19:15:32 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: , Eddie, >What happens in currently-deployed codecs when packets are dropped? > all recent codecs can handle substancial amounts of loss (that is: well implemented decoders can ;-) but mimizing losses should remain the highest priority because the perceived quality for (X-loss) is always smaller than if the codec had produced (X-loss)bits in the first place. >Clearly codecs, and VoIP in particular, can handle loss. Possibly even high >loss rates. One way to think about DCCP's allowed sending rate is that it >moves drops that *would* have happened in the network *anyway*, into the >sending host. (Although DCCP will generally drop more than the network >would have, to ensure fairness, and because of congestion-control >infelicities that we want to fix.) So how disastrous are these drops? What is desirable is that DCCP tells the sender "dont send that much!" and as Tom expressed it: >"it seems better to me that the sender makes intelligent >decisions about packet discard, rather than the network makes random >decisions which also apply to the DCCP stack (sender side): it is not in a good position to make the best decision. >Another way to put this: A DCCP API might never block -- or it might block >for at most T seconds. Instead, writing a packet into a full send buffer >would drop that packet; or it might drop an older packet---a drop-from-head >send buffer; or it might drop the oldest packet with lowest priority >annotation. > >Now the app simply sees a loss rate, which DCCP will happily report. For >codec switching, you can simply switch when the loss rate is intolerably >high -- which you would have had to do anyway. > >How horrible would this be? You make it sound like the DCCP sender API would be some mysterious black hole?-) I vote for "extremely horrible"?-) What about a *delay* API: When the rate changes the application is notified (e.g. a call back would be nice, at startup an application would be able to pass a rate callback pointer function) If the application complies i.e. waits the right amount of time between each packet and/or send packets with the right size so that its rate is below the indicated rate, then all is good. If the application does not comply (sends a packet too soon and/or too big) the API replys: "This packet will be sent, but with a delay of xxx ms" (and *sends* it, the delay being computed to match the current CC max rate) obviously such a message implies that the sender is sending with a rate too high... (at that stage an application which passed "null" at startup for the rate callback pointer function can use an explicit call to get the rate...) If the application sends *really* too much the API returns with *increasing delays* until a more severe error occurs: "packet not accepted, buffer is full". In short, the (int) returned by "send" would not be the amount of data sent but the amount of *delay* the packet will suffer before flying out. Zero meaning the application rate is below the max (TFRC) rate. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 13:28:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13306 for ; Fri, 25 Jul 2003 13:28:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6ME-0000Lv-7V for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 13:27:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PHRsHi001351 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 13:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6ME-0000Li-4T for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 13:27:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13272 for ; Fri, 25 Jul 2003 13:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6MC-0002BD-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 13:27:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g6MB-0002BA-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 13:27:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6LN-0000CC-Vc; Fri, 25 Jul 2003 13:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6Kg-0000BV-Vp for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 13:26:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13225; Fri, 25 Jul 2003 13:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6Ke-0002Ae-00; Fri, 25 Jul 2003 13:26:16 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19g6Kd-0002AJ-00; Fri, 25 Jul 2003 13:26:16 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26226; Fri, 25 Jul 2003 13:25:39 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26545; Fri, 25 Jul 2003 13:25:40 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1M54Y1>; Fri, 25 Jul 2003 13:25:39 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C52@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Damon Lanphear'" , Eddie Kohler Cc: dccp@ietf.org, mmusic@ietf.org Date: Fri, 25 Jul 2003 13:25:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] What's wrong with TFRC for VoIP and other apps? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , In VoIP (audio and video) you NEVER resend. You drop and move on. So, the resend mechanism is baggage for us. It's one of the reasons UDP is used. Having an agreed upon max rate would be good. It would be nice to have some kind of negotiation: I want to send at 64K You can only send at max 40K Okay, the max I can use then is 32K Fine, 32K it is Brian > -----Original Message----- > From: Damon Lanphear [mailto:damonlan@real.com] > Sent: Friday, July 25, 2003 12:37 PM > To: Eddie Kohler > Cc: dccp@ietf.org; mmusic@ietf.org > Subject: Re: [dccp] What's wrong with TFRC for VoIP and other apps? > > > Eddie, > > I would add that when ECN is not available loss becomes a considerable > factor that bounds the TFRC rate. The TFRC algorithm periodically > touches the upper bounds of the link capacity, at which point loss is > induced, and the algorithm decreases the rate. The result is periodic > distortion. > > This distortion can be mitigated through a resend mechanism. But when > you combine a resend mechanism with adherence to the TFRC > rate, you get > a more complicated solution. You have to define a trade off between > delay for satisfying resends and minimizing distortion. > > Of course, congestion induced loss is a fact of life in the > best effort > internet. But we can at least define a way by which TFRC can further > minimize periodic loss. I understand that TFRC as it is currently > defined has been designed to significantly dampen periodic > oscillations. > I think, however, that we may want to go a step further and say that > TFRC can optionally limit itself to some maximum rate, that may vary > over the duration of the session, but is defined by the application. > > The intent in doing so is to obviate the requirement that TFRC > constantly push against an unknown upper bounds. So unless congestion > causes the upper bound to be close to the defined maximal > rate, periodic > loss will be eliminated. If the maximal rate is close to the > link rate > (due to congestion, or otherwise) then we are no better off than > before. But at least there is an opportunity to specifically > provision > sessions for known media rates. > > On Thu, 2003-07-24 at 14:58, Eddie Kohler wrote: > > Hi all, > > > > I just wanted to try to summarize the issues people have > brought up, in > > other threads, about why TFRC and/or DCCP will be > inappropriate for VoIP > > and other apps. I agree with Tom Phelan's comment that the > biggest issues > > have to do with TFRC, not the API. I've left off the > solutions people have > > proposed to these problems. > > > > 1. Rate slows down during idle periods > > > > The TFRC allowed sending rate will drop down to > something very small > > (2-4 packets/RTT) when the sender is idle. This may > cause problems > > particualrly with VoIP conversations, which are > naturally idle-one-way > > then idle-the-other-way. The rampup from the small rate > to the fair rate > > may take several to many RTTs, ouch. > > > > 2. Rate will not increase during app-limited period > > > > This is essentially the same problem as above. Say the > application is > > sending at rate R. The allowed rate will not increase > much beyond R > > (say, more than 2R) until the app transmits at a faster rate. > > > > 3. Apps with fixed sets of rates > > > > An app might have a discrete set of sending rates. Must > it send at the > > highest app rate <= the TFRC allowed rate? Would be very > nice to allow > > some flexibility, so that it could send at, say, the > highest rate <= > > 1.8*TFRC_allowed_rate. > > > > 4. Rate changes/oscillations > > > > There are application costs, possibly significant ones, > associated with > > changing rates. If the app has to change its rate > frequently, because of > > CC, that's a problem. > > > > Have I missed anything? > > > > Eddie > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > -- > Damon Lanphear > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Jul 25 14:29:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14618 for ; Fri, 25 Jul 2003 14:29:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g7JV-00034f-IS for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 14:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PIT9Nl011813 for mmusic-archive@odin.ietf.org; Fri, 25 Jul 2003 14:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g7JV-00034S-Dy for mmusic-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 14:29:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14612 for ; Fri, 25 Jul 2003 14:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g7JS-0002WK-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 14:29:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g7JS-0002WH-00 for mmusic-web-archive@ietf.org; Fri, 25 Jul 2003 14:29:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g7JN-00032p-Vf; Fri, 25 Jul 2003 14:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g7It-00032H-MZ for mmusic@optimus.ietf.org; Fri, 25 Jul 2003 14:28:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14598; Fri, 25 Jul 2003 14:28:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g7Iq-0002W1-00; Fri, 25 Jul 2003 14:28:28 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19g7Ip-0002Vi-00; Fri, 25 Jul 2003 14:28:28 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6PIRtYG013162; Fri, 25 Jul 2003 14:27:56 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 25 Jul 2003 14:27:53 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 14:27:53 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB48E@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Damon Lanphear'" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Date: Fri, 25 Jul 2003 14:27:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [dccp] One-way live media with DCCP/TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 Damon, Yes, the application can pick its "upshift probe" period based on its knowledge of the user perception of rate shifts (the one up to probe and the possible one down if the probe fails). I suspect many apps might choose to never probe up. Tom P. > -----Original Message----- > From: Damon Lanphear [mailto:damonlan@real.com] > Sent: Friday, July 25, 2003 12:54 PM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: Re: [dccp] One-way live media with DCCP/TFRC > > > Tom, > > Great way to frame this problem. I like this approach. I have one > apprehension: > > On Thu, 2003-07-24 at 12:26, Phelan, Tom wrote: > At this point (perhaps after a slight delay) the sender can > switch back > to > > the higher rate. If the new rate can't be sustained the > transmit buffer > > will fill again (and the playout buffer will drain). When > the switch > > encoding threshold is reached the sender goes back to the > lower encoding > > rate. This oscillation continues until the stream ends or > the network is > > able to support the high rate for the long term. > > I think we'd like to avoid the oscillation you describe. Or at least > extend the period over which it can occur. But that all comes down to > understand the impact of the oscillation on the subjective > experience of > the user. If we're delivering video, and there is a perceivable > difference in the distortion of the high and low rates, then switching > back and forth over even 20s intervals could be truly annoying. > > I think of this oscillation problem as being kind of like > that which we > encounter with congestion control algorithms. Where there is some > unknown upper bounds against which we have to test periodically at a > cost. I'm not sure what a good solution is. I think > whatever solution > is put forward will have to be dependent on the attributes of > the media, > and perhaps tie upshift attempts to a combination of buffer state and > some measure of stability of the upper bounds rate. > > > > On Thu, 2003-07-24 at 12:26, Phelan, Tom wrote: > > Hi, > > > > I've been continuing to think about the one-way live media > case and have > > come up with the following scheme for using DCCP with TFRC. > Recall that > > one-way live differs from one-way pre-recorded media by having a max > > possible sending rate equal to the encoding rate (except > for very short > > bursts, perhaps), and differs from two-way interactive > media by being > > tolerant of delay. > > > > So, for this scheme we have a playout buffer at the > receiver and transmit > > buffer at the sender. Note that these buffers contain > media streams, not > > packets, and their lengths are measured in seconds, not > bytes or packets. > > > > The transmit buffer is filled at the encoding rate and > drained at the TFRC > > transmit rate. The playout buffer is filled at the network > arrival rate and > > drained at the decoding rate. The playout buffer has a > playback start > > threshold and the transmit buffer has a "switch encoding" > threshold. These > > thresholds are on the order of a few to several seconds and > switch encoding > > is less than playback start. > > > > Assume that the encoder can encode at two rates, a high > rate and a low rate. > > At the start of a connection, the sender places data into > the transmit > > buffer at the high encoding rate. The buffer is drained at > the TFRC rate, > > which at this point is in slow-start and is probably slower than the > > required rate. This will cause a backup in the transmit > buffer. Eventually > > TFRC will slow-start to a rate slightly above the rate > necessary to sustain > > the encoding rate. When this happens the transmit buffer > will drain and > > we'll reach a steady-state condition where the transmit > buffer is empty and > > we're transmitting at a rate that is probably below the > maximum allowed by > > TFRC. Note that, by my interpretation of TFRC at least, we won't be > > penalized for transmitting less than we could. You're only > penalized when > > you transmit nothing for some number of roundtrip times. > > > > Meanwhile at the receiver, the playout buffer is filling, > and when it > > reaches the playback start threshold playback will start. > After TFRC > > slow-start and the transmit buffer is drained, this buffer > will reach a > > steady state where packets are arriving from the network at > the encoding > > rate (ignoring jitter) and being drained from the buffer at > the (equal) > > decoding rate. The depth of the buffer will be the > playback start threshold > > plus the maximum depth of the transmit buffer during slow start. > > > > Now assume that network congestion forces TFRC to drop its > rate to below > > that needed by the high rate encoding. The transmit buffer > will begin to > > fill and the playout buffer will begin to drain. When the > transmit buffer > > reaches the switch encoding threshold, the sender switches > to the low rate > > encoding, and converts all of the data in the transmit > buffer to low rate > > encoding. I'll ignore issues of how to do this > efficiently, but it's > > important not to discard this data, and to convert it. > > > > Assuming that the network can support the new, lower, rate > (and a little > > more) the transmit buffer will begin to drain and the > playout buffer will > > begin to fill. Eventually the transmit buffer will empty, > the playout > > buffer will be back to its steady-state level, and we'll be > transmitting > > data at the new, lower, encoding rate. > > > > At this point (perhaps after a slight delay) the sender can > switch back to > > the higher rate. If the new rate can't be sustained the > transmit buffer > > will fill again (and the playout buffer will drain). When > the switch > > encoding threshold is reached the sender goes back to the > lower encoding > > rate. This oscillation continues until the stream ends or > the network is > > able to support the high rate for the long term. > > > > It might be useful for DCCP to tell the application about > rate changes. For > > instance, when DCCP/TFRC has decided on a rate too low for > the high rate > > encoding the application could make the change to the low > rate immediately. > > This would work, but it might lead to unnecessary switches > to the lower > > rate. In particular, when DCCP decides on a new rate, it > has no way of > > knowing whether this is a transient or a long-term change. If it's > > transient the transmit buffer might be able to absorb the > problem, and a > > change to the lower rate might unnecessarily reduce the > quality seen by the > > user. If we wait for the switch encoding threshold we can > be more sure that > > the rate change is long-term. Also, if we rely on rate > indications for the > > downshift, we need to ignore it during slow-start. > > > > It might be more useful to know when DCCP has raised the > rate sufficiently > > to switch to the high rate (after the transmit buffer has > been drained). > > > > Note that this scheme is also suitable for one-way > pre-recorded media, as > > long as the transmit buffer is only filled at the encoding > rate, not at the > > disk read rate. Overall I'd say that this is better than > the previous > > scheme (for one-way pre-recorded media), and I think that > some of the > > commenters on the previous message must have had something > like this in > > mind. > > > > I still don't know how to do the two-way interactive media. > > > > Tom P. > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > -- > Damon Lanphear > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 27 11:23:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17782 for ; Sun, 27 Jul 2003 11:23:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007ue-6Z for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RFNNXY030399 for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007uC-2g for mmusic-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17766 for ; Sun, 27 Jul 2003 11:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gnMn-0004ZQ-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gnMl-0004Yz-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMU-0007rm-0E; Sun, 27 Jul 2003 11:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fncB-0007GK-U3 for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 17:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01702; Thu, 24 Jul 2003 17:27:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnc6-0002U0-00; Thu, 24 Jul 2003 17:27:02 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19fnbq-0002Tu-00; Thu, 24 Jul 2003 17:26:46 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OLQYi8055704; Thu, 24 Jul 2003 14:26:34 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242126.h6OLQYi8055704@coyote.icir.org> To: "Phelan, Tom" cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" In-Reply-To: Message from "Phelan, Tom" of "Thu, 24 Jul 2003 10:02:01 EDT." <4CF48720B6E9D4118D040060CF2074E9082BB481@sonusdc3.sonusnet.com> Date: Thu, 24 Jul 2003 14:26:34 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Another thing that concerns me (touched on in the paragraph above) is the > disconnect between a transport protocol making rate decisions and an > application making rate decisions. It seems to me that these particular > applications are much better equipped to make the rate decisions - they know > about what is possible. It also seems that the application can make at > least as good a decision about what constitutes network congestion. The app > will need feedback about the playout buffer state, and this is largely > redundant with the DCCP acks. If the app is making rate decisions and > detecting network congestion, what do we need DCCP for? My take: Your paragraph was written from the application's point of view, not that of the network. DCCP is about implementing congestion control that is appropriate for the network: in other words, currently, TCP-friendly CC. This may conflict with application "requirements". For example: > It seems to me that these particular > applications are much better equipped to make the rate decisions - they know > about what is possible. What is possible for the application may not be TCP-friendly or appropriate for the network (if the app has a minimum rate, for example). > It also seems that the application can make at > least as good a decision about what constitutes network congestion. The app should make a decision that is TCP-friendly -- in which case you've got DCCP all over again. You need acks, probably ECN Nonces, .... We have a congestion control problem, for which we need a congestion control solution. Avoiding DCCP doesn't avoid the problem. So we should solve the problem! And I think we can solve it! Now, it may end up that DCCP is not appropriate, once the congestion control problem is solved. I'm not against UDP with application-level congestion control. But CC is a hard problem, which we are trying to solve for you. Also: > The app will need feedback about the playout buffer state, and this is > largely redundant with the DCCP acks. The app should be able to extract this information from the DCCP API, so no app-level acks are necessary. Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 27 11:23:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17781 for ; Sun, 27 Jul 2003 11:23:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007uE-2u for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RFNNHA030382 for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMo-0007tx-VB for mmusic-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 11:23:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17761 for ; Sun, 27 Jul 2003 11:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gnMn-0004ZE-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gnMl-0004Z7-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMS-0007r0-OL; Sun, 27 Jul 2003 11:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ez1r-0003N9-TK for mmusic@optimus.ietf.org; Tue, 22 Jul 2003 11:26:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17319 for ; Tue, 22 Jul 2003 11:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ez1r-0005Sy-00 for mmusic@ietf.org; Tue, 22 Jul 2003 11:26:15 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ez1g-0005SQ-00 for mmusic@ietf.org; Tue, 22 Jul 2003 11:26:04 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6MFPGAX003247; Tue, 22 Jul 2003 08:25:16 -0700 Date: Tue, 22 Jul 2003 08:25:16 -0700 From: David Meyer To: mboned@network-services.uoregon.edu Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt Message-ID: <20030722082516.A3189@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Folks, Here's something that would be productive: Let's talk about facts, and stay away from statements such as ... ASM for IPv4 is not scalable in interdomain but SSM is ... We need to support this type of statement, otherwise it is just marketing for SSM (maybe that is appropriate somewhere, but not on the MBONED list). Let's stay away from marketing and speculating about what might happen (or for that matter, what might have happened), and spend our resources on multicast deployment, which is the charter of MBONED. Thanks, Dave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 27 11:23:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17846 for ; Sun, 27 Jul 2003 11:23:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMt-0007vJ-Nn for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RFNRhB030451 for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMt-0007v4-KV for mmusic-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 11:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17762 for ; Sun, 27 Jul 2003 11:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gnMn-0004ZO-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gnMl-0004Z0-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMT-0007r8-2g; Sun, 27 Jul 2003 11:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhNS-0001wk-9w for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 10:47:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09685; Thu, 24 Jul 2003 10:47:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fhNP-0006af-00; Thu, 24 Jul 2003 10:47:27 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 19fhNE-0006aU-00; Thu, 24 Jul 2003 10:47:16 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.8p1/8.12.8) with ESMTP id h6OEkIGc061828; Thu, 24 Jul 2003 15:46:19 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: "Phelan, Tom" cc: "'Damon Lanphear'" , "'philippe.gentric@philips.com'" , Magnus Westerlund , dccp@ietf.org, mmusic@ietf.org, "Pasco Anderson, Jay" In-reply-to: Your message of "Thu, 24 Jul 2003 10:02:01 EDT." <4CF48720B6E9D4118D040060CF2074E9082BB481@sonusdc3.sonusnet.com> Date: Thu, 24 Jul 2003 15:46:18 +0100 Message-ID: <61827.1059057978@aardvark.cs.ucl.ac.uk> Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >Actually, my big worry here is TFRC, not the API. I'm baffled about how to >map slow start plus mostly smooth changes but occasional abrupt changes and >a small playout buffer into something workable. > >Another thing that concerns me (touched on in the paragraph above) is the >disconnect between a transport protocol making rate decisions and an >application making rate decisions. It seems to me that these particular >applications are much better equipped to make the rate decisions - they know >about what is possible. It also seems that the application can make at >least as good a decision about what constitutes network congestion. The app >will need feedback about the playout buffer state, and this is largely >redundant with the DCCP acks. If the app is making rate decisions and >detecting network congestion, what do we need DCCP for? [I'm just dropping back into a discussion I haven't been following, so forgive me if this duplicates previous discussion] There seem to be two obvious sorts of apps that might use TFRC: - streaming media - videotelephony That isn't to say that there are different apps, but these two typify two classes of apps. Both are fine with variable packet rates. But streaming media has significantly more playout buffer available. Streaming media apps can run the codec (or choice of pre-encoded stream) at approximately constant bitrate, and send at variable bitrate, using the playout buffer to deal with the temporary mismatches. Videotelephony apps don't have sufficient delay budget to fix things at the receiver, but they do have the luxury of encoding live, so they can change the compression parameters on the fly. They usually don't have luxury of re-encoding twice though, so if their choice of quantization parameters gives a rate that is different from what is expected (because the video content was unpredictable), then they might be in trouble. Also, if the TFRC bandwidth envelope changes unexpectedly, you can be in trouble. So, why do I say all this? My assumption is that streaming media apps will normally send at the TFRC rate. What they need is sufficient advance warning that the playout buffer is running low so that they can switch down to a lower rate. And if the playout buffer is starting to get rather large, then they can switch up to a higher rate. Assuming rate switching is not a trivial operation, and that the rate can only be switched at certain re-sync points, then there is some danger that if congestion suddently gets really bad, then the playout buffer will be exhausted before the codec can be switched. My assumption here is that a really good API would allow the sender to send above the TFRC rate for a period of time, so long as the rate mismatch isn't too bad. A factor of two might be reasonable as an upper bound on the oversending rate. Videotelephony apps probably can't send at precisely the TFRC rate without sacrificing delay to an undesirable extent. This means two things. First, the app needs to be allowed to send at rates above the TFRC rate for a period of time (again, bounded to avoid extreme unfairness). Second, if the app sends under the TFRC rate for a short period, it shouldn't lose it's ability to send faster later, so long as it didn't undersend by too much. For such apps, the TFRC rate is a guide rate - the app should be capable of varying around the guide rate, so long as it stays within reasonable bounds, and so long as the long-term average is close to the TFRC rate. Anyway, in both cases, if the kernel strictly enforces the TFRC rate, app designers will either not use DCCP, or they'll pad their signal with redundant data so they can operate within a more predictable codec envelope. Both are undesirable. I'm not sure how we best design an API to satisfy this, but I think it's really important that we do think about how this can be achieved. The general philosophy that the TFRC rate is a guide-rate to be followed loosely will probably also apply with TFRC-PS and VoIP, but we know a lot less about this space. Cheers, Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 27 12:09:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17783 for ; Sun, 27 Jul 2003 11:23:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007uu-9A for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RFNNRk030425 for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007uK-4d for mmusic-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17769 for ; Sun, 27 Jul 2003 11:23:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gnMn-0004ZR-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gnMl-0004Z2-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMT-0007ra-Mq; Sun, 27 Jul 2003 11:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnL4-0006Ew-34 for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 17:09:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01028; Thu, 24 Jul 2003 17:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnKp-0002KU-00; Thu, 24 Jul 2003 17:09:11 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19fnKZ-0002KD-00; Thu, 24 Jul 2003 17:08:55 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OL8Si8055542; Thu, 24 Jul 2003 14:08:28 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242108.h6OL8Si8055542@coyote.icir.org> To: philippe.gentric@philips.com cc: "Phelan, Tom" , dccp@ietf.org, mmusic@ietf.org In-Reply-To: Message from philippe.gentric@philips.com of "Wed, 23 Jul 2003 19:43:04 +0200." Date: Thu, 24 Jul 2003 14:08:28 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > Surely DCCP has better assets to lure implementers?-)... > I think an API providing a target rate would be a good starting point;-) It's been mentioned a couple times deep in emails, but just to make it explicit: We absolutely expect APIs to provide the current congestion control state to applications. This includes, but is not limited to, the maximum allowed rate. Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 27 12:09:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17784 for ; Sun, 27 Jul 2003 11:23:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007uk-7V for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RFNN5U030408 for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMp-0007uD-2x for mmusic-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 11:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17770 for ; Sun, 27 Jul 2003 11:23:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gnMn-0004ZP-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gnMl-0004Z1-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMT-0007rO-CD; Sun, 27 Jul 2003 11:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmb1-0002DK-22 for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 16:21:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28473; Thu, 24 Jul 2003 16:21:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmaz-0001qf-00; Thu, 24 Jul 2003 16:21:49 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 19fmaj-0001qU-00; Thu, 24 Jul 2003 16:21:33 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OKLJi8055203; Thu, 24 Jul 2003 13:21:19 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200307242021.h6OKLJi8055203@coyote.icir.org> To: philippe.gentric@philips.com cc: "Phelan, Tom" , dccp@ietf.org, mmusic@ietf.org, "'Reiner Ludwig'" In-Reply-To: Message from philippe.gentric@philips.com of "Thu, 17 Jul 2003 10:37:47 +0200." Date: Thu, 24 Jul 2003 13:21:19 -0700 From: Eddie Kohler Subject: [MMUSIC] Re: [dccp] Using DCCP for VoIP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 all, On this issue: > IMHO this issue is related to my question in the other mail about > managing audio AND video at the same time: probably DCCP should have a > way to handle "collectively" a bunch of streams, be it audio plus video > or two-way audio! Our thought was that, given DCCP's unreliability, it is trivial to layer multiple streams on top. The first byte of packet data could indicate stream number to the application. This works as long as both streams want to share the same congestion control state + CC mechanism -- is this the case? Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Jul 27 12:09:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17780 for ; Sun, 27 Jul 2003 11:23:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMo-0007tp-Cl for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RFNMZT030364 for mmusic-archive@odin.ietf.org; Sun, 27 Jul 2003 11:23:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMo-0007tf-7Q for mmusic-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 11:23:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17757 for ; Sun, 27 Jul 2003 11:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gnMn-0004ZB-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gnMl-0004Yy-00 for mmusic-web-archive@ietf.org; Sun, 27 Jul 2003 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gnMU-0007ry-AM; Sun, 27 Jul 2003 11:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foB2-0000gt-VP for mmusic@optimus.ietf.org; Thu, 24 Jul 2003 18:03:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02736; Thu, 24 Jul 2003 18:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foB0-0002hk-00; Thu, 24 Jul 2003 18:03:06 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 19foAp-0002hF-00; Thu, 24 Jul 2003 18:02:55 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.8p1/8.12.8) with ESMTP id h6OM16wo001466; Thu, 24 Jul 2003 23:01:06 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: philippe.gentric@philips.com cc: dccp@ietf.org, mmusic@ietf.org In-reply-to: Your message of "Thu, 24 Jul 2003 20:03:36 +0200." Date: Thu, 24 Jul 2003 23:01:06 +0100 Message-ID: <1465.1059084066@aardvark.cs.ucl.ac.uk> Subject: [MMUSIC] Re: [dccp] natural DCCP sender-side API: (was stream switching) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >>My assumption is that streaming media apps will normally send at the >>TFRC rate. > >Could it be "at a rate equal or inferior to the TFRC rate"? > >What will happen if an application "does not use" the >bandwidth indicated by TFRC? OK, my assumption here was that streaming media was coming from disk. Thus you can always send faster then the receiver is consuming. This isn't always true - live broadcast fits in the spectrum between streaming media and teleconferencing. But you can do your own extrapolation - my high level point that the for many apps the TFRC rate should be treated as a reference rate rather than an absolute mandate is still the case. >What would be the point of defining TFRC and then "cheat on it" ? You have to understand that TFRC is only an approximation. It "cheats" on TCP on short timescales. And at high loss rates, even different TCP implementations aren't very fair to each other. If the apps "cheat" on TFRC on shortish timescales, but in such a way that it generally averages out in the end, then this is very similar to what TFCR is doing anyway relative to TCP. Our goals for TFRC were that it was within a factor of two of TCP's average rate on medium timescales. Thus it doesn't make sense to argue about an app being (say) 10% over the TFRC rate on short timescales - the app's constraints are more important than a small factor of fairness in rate. What matters is that no-one loses badly (from a fairness point of view) and that the goodput through the bottleneck is close to 100% (so we don't want to encourage unnecessary padding to keep the app's rate up to the TFRC rate). Cheers, Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 01:11:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05980 for ; Mon, 28 Jul 2003 01:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h0I6-0004fF-93 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 01:11:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S5BMgq017928 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 01:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h0I6-0004f5-2v for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 01:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05974 for ; Mon, 28 Jul 2003 01:11:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h0I3-0004Ml-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 01:11:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h0I2-0004Mi-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 01:11:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h0Hl-0004eg-UE; Mon, 28 Jul 2003 01:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h0HI-0004e3-OR for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 01:10:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05957 for ; Mon, 28 Jul 2003 01:10:29 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h0HF-0004MH-00 for mmusic@ietf.org; Mon, 28 Jul 2003 01:10:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19h0HF-0004ME-00 for mmusic@ietf.org; Mon, 28 Jul 2003 01:10:29 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6S5ASB07690 for ; Mon, 28 Jul 2003 08:10:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Jul 2003 08:10:28 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Jul 2003 08:10:28 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Jul 2003 08:10:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jul 2003 08:10:26 +0300 Message-ID: <2BF0AD29BC31FE46B78877321144043102F7D641@trebe003.europe.nokia.com> Thread-Topic: draft-ietf-mmusic-sdp-new-13.txt - total conf BW & automatic interactivity Thread-Index: AcNMkOV0SKO+Mp4mRJWtIgQVzyfrbg== To: Cc: X-OriginalArrivalTime: 28 Jul 2003 05:10:27.0751 (UTC) FILETIME=[8F187B70:01C354C6] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] draft-ietf-mmusic-sdp-new-13.txt - total conf BW & automatic interactivity Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi - two quick comments from the meeting slides - On the bandwidth parameter giving the total (all users) bandwidth for = RTP multiparty conferences: in this case there is some sense, but the = layering issue is somewhat orthogonal (i.e. is does solve for layering). = The notion of layered codecs (one or more sources) has some commonality = to RMT-ALC which enables layering (e.g. over a number of SSM channels). = So actually describing the layered session (media/content/whatever) = could be done once for both cases (or many layered cases) and the change = proposed does not deal with this. With layered deliver, it's important = that devices understand what is available and their capabilities (e.g. = for data rates over communications links and for decoding) so the = minimum bandwidth is more important than "total bandwidth". In any case, = is it really part of the main SDP spec to include laying descriptors or = a child spec.? (draft-ietf-mmusic-sdp-bwparam-04.txt) I think the meeting established SHOULD NOT -> MUST NOT for automatically = opening interactive sessions (without in-sequence user intervention) is = not so great unless there is a disclaimer that with pre-authorization = you may do automatic. I agree, and just one to add that the "no human = user present" case is also valid and can be served by stating you can do = automatic with pre-authorization (remote monitoring and auto-answering = to teleconferences are the obvious use cases I've seen). Cheers, Rod. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Rod Walsh Nokia Research Center Tampere, Finland +358 50 483 5632 rod.walsh@nokia.com = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 10:23:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03015 for ; Mon, 28 Jul 2003 10:23:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h8tr-0007XL-1m for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 10:22:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SEMtd3028971 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 10:22:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h8tq-0007XC-VA for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 10:22:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02996 for ; Mon, 28 Jul 2003 10:22:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h8to-0002om-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 10:22:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h8to-0002oj-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 10:22:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h8sz-0007RC-U9; Mon, 28 Jul 2003 10:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h8sH-0007QJ-2Y for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 10:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02960; Mon, 28 Jul 2003 10:21:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h8sE-0002nJ-00; Mon, 28 Jul 2003 10:21:14 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19h8sD-0002n6-00; Mon, 28 Jul 2003 10:21:13 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6SEKgOT022660; Mon, 28 Jul 2003 10:20:42 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 28 Jul 2003 10:20:38 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 10:20:37 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB491@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'dccp@ietf.org'" , "'mmusic@ietf.org'" Cc: "Pasco Anderson, Jay" Date: Mon, 28 Jul 2003 10:20:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] Two-way media with DCCP and TFRC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, I've come up with the following scheme for using DCCP/TFRC with two-way interactive media. As a reminder, two-way media differs from one-way live in being very intolerant of delay. One-way live differs from one-way pre-recorded in having a maximum transmit rate equal to the encoding rate (rather than the disk read rate). The procedure here is a significant departure from current practice. I haven't been able to fully digest the system implications of this scheme yet, but some of them, especially with regard to congestion and call admission control seem pretty exciting. Assume that each end of the connection is capable of using a number of codecs with increasing bandwidth needs, where each step up is less than twice the rate of the previous step, and that the sender can switch between them at "low cost" (perhaps a big assumption). Assume also that DCCP provides immediate feedback to the application when it changes the computed sending rate. To start, the calling part sends an INVITE (loosely using SIP terminology) indicating the IP address and DCCP port to use for media at its end. Without informing the called user, the called system responds to the INVITE by connecting to the media port. Both end systems then begin exchanging test data, at the (slowly increasing) rate allowed by TFRC. The purpose of this test data is to see what rate the connection can be ramped up to. If that rate is less than a minimum acceptable rate, the call is cleared (conceptually, the calling user hears "fast busy" and the called user is never informed of the incoming call). Note that once the rate has ramped up sufficiently for the highest rate codec there's no need to go further. If an acceptable rate can be achieved, the called user is informed of the incoming call. The test data is continued during this period. Once the called user accepts the call, the test data is replaced by real data at the same rate. If congestion is encountered during the call, TFRC will reduce its allowed sending rate. When that rate falls below the codec currently is use, the sender switches to a lower rate codec. If the rate continues to fall the sender will eventually get to its lowest rate codec. If the TFRC rate continues to fall past the lowest rate codec, the sender must discard packets to conform to that rate. If the network capacity is sufficient to support one of the lower rate codecs, eventually the congestion will clear and TFRC will slowly increase the allowed transmit rate. Since the application will continue to transmit at its codec rate, TFRC will limit this increase to at most twice the current sending rate (my interpretation of the TFRC paper here, I could be wrong :-)). This is the reason that the sender must use a codec suite with rates in steps of less that two times the previous rate. If the TFRC rate increases sufficiently for the next codec step, the sender may switch to the higher rate step. If the network can't support the new rate, eventually congestion will reappear and the sender will fall back to the lower rate. Over time the sender will oscillate between the lower and higher rate with a period equal to the time it takes TFRC to probe between the two rates. This procedure doesn't work when silence suppression is in use. I need to think about that some more. Tom P. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 10:34:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03362 for ; Mon, 28 Jul 2003 10:34:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h94T-00085X-Pn for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 10:33:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SEXrAx031085 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 10:33:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h94T-00085I-MS for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 10:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03352 for ; Mon, 28 Jul 2003 10:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h94R-0002vn-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 10:33:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h94Q-0002vk-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 10:33:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h93d-0007wt-Ec; Mon, 28 Jul 2003 10:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h93B-0007vm-M5 for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 10:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03307; Mon, 28 Jul 2003 10:32:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h936-0002uV-00; Mon, 28 Jul 2003 10:32:28 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19h935-0002uS-00; Mon, 28 Jul 2003 10:32:27 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6SEWOTv012316; Mon, 28 Jul 2003 10:32:24 -0400 (EDT) Message-ID: <3F2533F8.2000702@cs.columbia.edu> Date: Mon, 28 Jul 2003 10:32:24 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC References: <4CF48720B6E9D4118D040060CF2074E9082BB491@sonusdc3.sonusnet.com> In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB491@sonusdc3.sonusnet.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 Like all measurement-based admissions control mechanism (and dozens have been proposed...), this one may well introduce unacceptable call setup delays. Once the other side has accepted a call, the last thing you want is "dead air", even for a few milliseconds (since the 'Hello' will get lost, which messes up the human two-way handshake pretty badly). You have a bit more room prior to ringing, but acceptable post-dial delay is probably no more than a second or two for landline phones. If you consider that the call may well be an emergency call, you really don't want to go probing the network for a few seconds before you connect to the PSAP... I'm not arguing against measurement-based admission control, but existing published experience has not been very encouraging, from what I can tell. Henning Phelan, Tom wrote: > Hi, > > I've come up with the following scheme for using DCCP/TFRC with two-way > interactive media. As a reminder, two-way media differs from one-way live > in being very intolerant of delay. One-way live differs from one-way > pre-recorded in having a maximum transmit rate equal to the encoding rate > (rather than the disk read rate). > > The procedure here is a significant departure from current practice. I > haven't been able to fully digest the system implications of this scheme > yet, but some of them, especially with regard to congestion and call > admission control seem pretty exciting. > > Assume that each end of the connection is capable of using a number of > codecs with increasing bandwidth needs, where each step up is less than > twice the rate of the previous step, and that the sender can switch between > them at "low cost" (perhaps a big assumption). Assume also that DCCP > provides immediate feedback to the application when it changes the computed > sending rate. > > To start, the calling part sends an INVITE (loosely using SIP terminology) > indicating the IP address and DCCP port to use for media at its end. > Without informing the called user, the called system responds to the INVITE > by connecting to the media port. Both end systems then begin exchanging > test data, at the (slowly increasing) rate allowed by TFRC. The purpose of > this test data is to see what rate the connection can be ramped up to. If > that rate is less than a minimum acceptable rate, the call is cleared > (conceptually, the calling user hears "fast busy" and the called user is > never informed of the incoming call). Note that once the rate has ramped up > sufficiently for the highest rate codec there's no need to go further. > > If an acceptable rate can be achieved, the called user is informed of the > incoming call. The test data is continued during this period. Once the > called user accepts the call, the test data is replaced by real data at the > same rate. > > If congestion is encountered during the call, TFRC will reduce its allowed > sending rate. When that rate falls below the codec currently is use, the > sender switches to a lower rate codec. If the rate continues to fall the > sender will eventually get to its lowest rate codec. If the TFRC rate > continues to fall past the lowest rate codec, the sender must discard > packets to conform to that rate. > > If the network capacity is sufficient to support one of the lower rate > codecs, eventually the congestion will clear and TFRC will slowly increase > the allowed transmit rate. Since the application will continue to transmit > at its codec rate, TFRC will limit this increase to at most twice the > current sending rate (my interpretation of the TFRC paper here, I could be > wrong :-)). This is the reason that the sender must use a codec suite with > rates in steps of less that two times the previous rate. If the TFRC rate > increases sufficiently for the next codec step, the sender may switch to the > higher rate step. If the network can't support the new rate, eventually > congestion will reappear and the sender will fall back to the lower rate. > Over time the sender will oscillate between the lower and higher rate with a > period equal to the time it takes TFRC to probe between the two rates. > > This procedure doesn't work when silence suppression is in use. I need to > think about that some more. > > Tom P. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 10:43:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03550 for ; Mon, 28 Jul 2003 10:43:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9DB-00008m-Ub for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 10:42:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SEgrui000535 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 10:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9DB-00008Y-Rf for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 10:42:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03522 for ; Mon, 28 Jul 2003 10:42:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9D9-00030B-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 10:42:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9D8-000308-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 10:42:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9CL-0008Sy-Me; Mon, 28 Jul 2003 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9BW-0008SC-6x for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 10:41:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03476; Mon, 28 Jul 2003 10:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9BS-0002yt-00; Mon, 28 Jul 2003 10:41:06 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19h9BR-0002yf-00; Mon, 28 Jul 2003 10:41:05 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6SEeXOT023996; Mon, 28 Jul 2003 10:40:34 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 28 Jul 2003 10:40:29 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 10:40:28 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB492@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Henning Schulzrinne'" , "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 28 Jul 2003 10:40:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Henning, Yes, I recognize that the post-dial delay problem is a big one. The big problem I faced with trying to map two-may media onto DCCP and TFRC was the TFRC slow-start. This probing mechanism actually turns it (slow-start) from a bug to get around into a feature to use. My understanding of TFRC is insufficient to tell how long the ramp up will take, but for the bandwidth needed by voice, it seems like it could be less than a second. Tom P. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, July 28, 2003 10:32 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC > > > Like all measurement-based admissions control mechanism (and > dozens have > been proposed...), this one may well introduce unacceptable > call setup > delays. Once the other side has accepted a call, the last > thing you want > is "dead air", even for a few milliseconds (since the 'Hello' > will get > lost, which messes up the human two-way handshake pretty badly). > > You have a bit more room prior to ringing, but acceptable post-dial > delay is probably no more than a second or two for landline > phones. If > you consider that the call may well be an emergency call, you really > don't want to go probing the network for a few seconds before you > connect to the PSAP... > > I'm not arguing against measurement-based admission control, but > existing published experience has not been very encouraging, > from what I > can tell. > > Henning > > Phelan, Tom wrote: > > > Hi, > > > > I've come up with the following scheme for using DCCP/TFRC > with two-way > > interactive media. As a reminder, two-way media differs > from one-way live > > in being very intolerant of delay. One-way live differs > from one-way > > pre-recorded in having a maximum transmit rate equal to the > encoding rate > > (rather than the disk read rate). > > > > The procedure here is a significant departure from current > practice. I > > haven't been able to fully digest the system implications > of this scheme > > yet, but some of them, especially with regard to congestion and call > > admission control seem pretty exciting. > > > > Assume that each end of the connection is capable of using > a number of > > codecs with increasing bandwidth needs, where each step up > is less than > > twice the rate of the previous step, and that the sender > can switch between > > them at "low cost" (perhaps a big assumption). Assume also > that DCCP > > provides immediate feedback to the application when it > changes the computed > > sending rate. > > > > To start, the calling part sends an INVITE (loosely using > SIP terminology) > > indicating the IP address and DCCP port to use for media at its end. > > Without informing the called user, the called system > responds to the INVITE > > by connecting to the media port. Both end systems then > begin exchanging > > test data, at the (slowly increasing) rate allowed by TFRC. > The purpose of > > this test data is to see what rate the connection can be > ramped up to. If > > that rate is less than a minimum acceptable rate, the call > is cleared > > (conceptually, the calling user hears "fast busy" and the > called user is > > never informed of the incoming call). Note that once the > rate has ramped up > > sufficiently for the highest rate codec there's no need to > go further. > > > > If an acceptable rate can be achieved, the called user is > informed of the > > incoming call. The test data is continued during this > period. Once the > > called user accepts the call, the test data is replaced by > real data at the > > same rate. > > > > If congestion is encountered during the call, TFRC will > reduce its allowed > > sending rate. When that rate falls below the codec > currently is use, the > > sender switches to a lower rate codec. If the rate > continues to fall the > > sender will eventually get to its lowest rate codec. If > the TFRC rate > > continues to fall past the lowest rate codec, the sender > must discard > > packets to conform to that rate. > > > > If the network capacity is sufficient to support one of the > lower rate > > codecs, eventually the congestion will clear and TFRC will > slowly increase > > the allowed transmit rate. Since the application will > continue to transmit > > at its codec rate, TFRC will limit this increase to at most > twice the > > current sending rate (my interpretation of the TFRC paper > here, I could be > > wrong :-)). This is the reason that the sender must use a > codec suite with > > rates in steps of less that two times the previous rate. > If the TFRC rate > > increases sufficiently for the next codec step, the sender > may switch to the > > higher rate step. If the network can't support the new > rate, eventually > > congestion will reappear and the sender will fall back to > the lower rate. > > Over time the sender will oscillate between the lower and > higher rate with a > > period equal to the time it takes TFRC to probe between the > two rates. > > > > This procedure doesn't work when silence suppression is in > use. I need to > > think about that some more. > > > > Tom P. > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 16:19:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19766 for ; Mon, 28 Jul 2003 16:19:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hESm-0001YL-Ma for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 16:19:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SKJKmu005965 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 16:19:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hESm-0001Y8-JC for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 16:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19738 for ; Mon, 28 Jul 2003 16:19:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hESk-0007co-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 16:19:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hESk-0007ck-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 16:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEST-0001UW-1B; Mon, 28 Jul 2003 16:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hERz-0001Tg-Ag for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 16:18:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19719; Mon, 28 Jul 2003 16:18:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hERw-0007br-00; Mon, 28 Jul 2003 16:18:28 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19hERv-0007aV-00; Mon, 28 Jul 2003 16:18:27 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6SKHsOT015174; Mon, 28 Jul 2003 16:17:54 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 28 Jul 2003 16:17:52 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 16:17:52 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB499@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Henning Schulzrinne'" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 28 Jul 2003 16:17:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, Henning has pointed out a basic problem with the two-way media over DCCP procedure - the "probe" time must be small enough to meet user expectations of connect time, probably on the order of magnitude of one second. Note that this seems to me to be a fundamental problem with any congestion control that uses slow-start, not just TFRC. Whether this can be achieved with TFRC depends on the details of TFRC slow-start. As I understand it, TFRC basically starts with an initial rate, and then doubles it every round-trip time until congestion is encountered. RFC3448 says that the initial rate is 1 packet/second. Now I have to admit that one packet per round-trip time sounds more like TCP's behavior to me, but I'll go with what the RFC says. Note that the difference is *very* significant for two-way voice. I'd appreciate it if someone had some authoritative info. Let's assume that a voice call has a minimum acceptable codec of G.711 with 40ms packetization interval. That translates to 25 packets/second. The TFRC rate will be 1 pkt/sec in the first RTT, 2 in the second, 4 in the third and so on, reaching 32 pkt/sec in the sixth RTT. Add two more RTTs for the initial DCCP connection handshake, and you have 8 RTTs. If the RTT is 100ms (on the hairy edge of usable for voice) then you have held up the connection progress for 800ms. If the RTT is 20ms the ramp up time is 160ms - hardly noticeable. If the minimum codec has a 20ms packetization interval, that doubles the needed rate, but only adds one round-trip time to the ramp up. So, the questions are: Does this analysis hold water? If it does, are these connection setup delays acceptable? Tom P. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, July 28, 2003 10:32 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC > > > Like all measurement-based admissions control mechanism (and > dozens have > been proposed...), this one may well introduce unacceptable > call setup > delays. Once the other side has accepted a call, the last > thing you want > is "dead air", even for a few milliseconds (since the 'Hello' > will get > lost, which messes up the human two-way handshake pretty badly). > > You have a bit more room prior to ringing, but acceptable post-dial > delay is probably no more than a second or two for landline > phones. If > you consider that the call may well be an emergency call, you really > don't want to go probing the network for a few seconds before you > connect to the PSAP... > > I'm not arguing against measurement-based admission control, but > existing published experience has not been very encouraging, > from what I > can tell. > > Henning > > Phelan, Tom wrote: > > > Hi, > > > > I've come up with the following scheme for using DCCP/TFRC > with two-way > > interactive media. As a reminder, two-way media differs > from one-way live > > in being very intolerant of delay. One-way live differs > from one-way > > pre-recorded in having a maximum transmit rate equal to the > encoding rate > > (rather than the disk read rate). > > > > The procedure here is a significant departure from current > practice. I > > haven't been able to fully digest the system implications > of this scheme > > yet, but some of them, especially with regard to congestion and call > > admission control seem pretty exciting. > > > > Assume that each end of the connection is capable of using > a number of > > codecs with increasing bandwidth needs, where each step up > is less than > > twice the rate of the previous step, and that the sender > can switch between > > them at "low cost" (perhaps a big assumption). Assume also > that DCCP > > provides immediate feedback to the application when it > changes the computed > > sending rate. > > > > To start, the calling part sends an INVITE (loosely using > SIP terminology) > > indicating the IP address and DCCP port to use for media at its end. > > Without informing the called user, the called system > responds to the INVITE > > by connecting to the media port. Both end systems then > begin exchanging > > test data, at the (slowly increasing) rate allowed by TFRC. > The purpose of > > this test data is to see what rate the connection can be > ramped up to. If > > that rate is less than a minimum acceptable rate, the call > is cleared > > (conceptually, the calling user hears "fast busy" and the > called user is > > never informed of the incoming call). Note that once the > rate has ramped up > > sufficiently for the highest rate codec there's no need to > go further. > > > > If an acceptable rate can be achieved, the called user is > informed of the > > incoming call. The test data is continued during this > period. Once the > > called user accepts the call, the test data is replaced by > real data at the > > same rate. > > > > If congestion is encountered during the call, TFRC will > reduce its allowed > > sending rate. When that rate falls below the codec > currently is use, the > > sender switches to a lower rate codec. If the rate > continues to fall the > > sender will eventually get to its lowest rate codec. If > the TFRC rate > > continues to fall past the lowest rate codec, the sender > must discard > > packets to conform to that rate. > > > > If the network capacity is sufficient to support one of the > lower rate > > codecs, eventually the congestion will clear and TFRC will > slowly increase > > the allowed transmit rate. Since the application will > continue to transmit > > at its codec rate, TFRC will limit this increase to at most > twice the > > current sending rate (my interpretation of the TFRC paper > here, I could be > > wrong :-)). This is the reason that the sender must use a > codec suite with > > rates in steps of less that two times the previous rate. > If the TFRC rate > > increases sufficiently for the next codec step, the sender > may switch to the > > higher rate step. If the network can't support the new > rate, eventually > > congestion will reappear and the sender will fall back to > the lower rate. > > Over time the sender will oscillate between the lower and > higher rate with a > > period equal to the time it takes TFRC to probe between the > two rates. > > > > This procedure doesn't work when silence suppression is in > use. I need to > > think about that some more. > > > > Tom P. > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 16:25:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19980 for ; Mon, 28 Jul 2003 16:25:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEYY-00028M-RK for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 16:25:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SKPIsn008198 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 16:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEYY-000289-OV for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 16:25:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19967 for ; Mon, 28 Jul 2003 16:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hEYW-0007gd-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 16:25:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hEYW-0007gZ-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 16:25:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEYH-00024B-Ri; Mon, 28 Jul 2003 16:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEXN-000202-Vd for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 16:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19915; Mon, 28 Jul 2003 16:24:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hEXM-0007g1-00; Mon, 28 Jul 2003 16:24:04 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19hEXK-0007fs-00; Mon, 28 Jul 2003 16:24:03 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6SKNrUr024126 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Jul 2003 16:23:53 -0400 (EDT) Message-ID: <3F258659.2090601@cs.columbia.edu> Date: Mon, 28 Jul 2003 16:23:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC References: <4CF48720B6E9D4118D040060CF2074E9082BB499@sonusdc3.sonusnet.com> In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB499@sonusdc3.sonusnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Phelan, Tom wrote: What happens if only one of these packets gets lost? > Hi, > > Henning has pointed out a basic problem with the two-way media over DCCP > procedure - the "probe" time must be small enough to meet user expectations > of connect time, probably on the order of magnitude of one second. Note > that this seems to me to be a fundamental problem with any congestion > control that uses slow-start, not just TFRC. Whether this can be achieved > with TFRC depends on the details of TFRC slow-start. > > As I understand it, TFRC basically starts with an initial rate, and then > doubles it every round-trip time until congestion is encountered. RFC3448 > says that the initial rate is 1 packet/second. Now I have to admit that one > packet per round-trip time sounds more like TCP's behavior to me, but I'll > go with what the RFC says. Note that the difference is *very* significant > for two-way voice. I'd appreciate it if someone had some authoritative > info. > > Let's assume that a voice call has a minimum acceptable codec of G.711 with > 40ms packetization interval. That translates to 25 packets/second. The > TFRC rate will be 1 pkt/sec in the first RTT, 2 in the second, 4 in the > third and so on, reaching 32 pkt/sec in the sixth RTT. Add two more RTTs > for the initial DCCP connection handshake, and you have 8 RTTs. If the RTT > is 100ms (on the hairy edge of usable for voice) then you have held up the > connection progress for 800ms. If the RTT is 20ms the ramp up time is 160ms > - hardly noticeable. > > If the minimum codec has a 20ms packetization interval, that doubles the > needed rate, but only adds one round-trip time to the ramp up. > > So, the questions are: Does this analysis hold water? If it does, are > these connection setup delays acceptable? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Jul 28 16:28:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20056 for ; Mon, 28 Jul 2003 16:28:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEbS-0002Kh-0c for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 16:28:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SKSHqN008961 for mmusic-archive@odin.ietf.org; Mon, 28 Jul 2003 16:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEbR-0002KS-Sr for mmusic-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 16:28:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20029 for ; Mon, 28 Jul 2003 16:28:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hEbQ-0007hp-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 16:28:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hEbP-0007hm-00 for mmusic-web-archive@ietf.org; Mon, 28 Jul 2003 16:28:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEbB-0002F0-P0; Mon, 28 Jul 2003 16:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEaU-0002D5-VC for mmusic@optimus.ietf.org; Mon, 28 Jul 2003 16:27:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20013; Mon, 28 Jul 2003 16:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hEaT-0007hM-00; Mon, 28 Jul 2003 16:27:17 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19hEaS-0007hA-00; Mon, 28 Jul 2003 16:27:16 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6SKQjOT015745; Mon, 28 Jul 2003 16:26:45 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 28 Jul 2003 16:26:43 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 16:26:42 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB49A@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Henning Schulzrinne'" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 28 Jul 2003 16:26:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Henning, > What happens if only one of these packets gets lost? Slow-start stops and the next rate is half of the current rate (if any packets are lost). Tom P. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 29 01:39:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00970 for ; Tue, 29 Jul 2003 01:39:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNCh-0003uk-3b for mmusic-archive@odin.ietf.org; Tue, 29 Jul 2003 01:39:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T5dJ2Q015042 for mmusic-archive@odin.ietf.org; Tue, 29 Jul 2003 01:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNCg-0003uX-Hl for mmusic-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 01:39:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00957 for ; Tue, 29 Jul 2003 01:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNCd-0002mC-00 for mmusic-web-archive@ietf.org; Tue, 29 Jul 2003 01:39:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hNCc-0002m9-00 for mmusic-web-archive@ietf.org; Tue, 29 Jul 2003 01:39:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNCO-0003tx-Up; Tue, 29 Jul 2003 01:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNBv-0003sl-Oy for mmusic@optimus.ietf.org; Tue, 29 Jul 2003 01:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00950; Tue, 29 Jul 2003 01:38:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNBs-0002m0-00; Tue, 29 Jul 2003 01:38:28 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hNBr-0002lr-00; Tue, 29 Jul 2003 01:38:27 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6T5bw6Y003067; Tue, 29 Jul 2003 01:37:59 -0400 (EDT) Message-ID: <3F260834.5090700@dynamicsoft.com> Date: Tue, 29 Jul 2003 01:37:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC References: <4CF48720B6E9D4118D040060CF2074E9082BB491@sonusdc3.sonusnet.com> In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB491@sonusdc3.sonusnet.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 This kind of scheme might work for video. I have seen interactive video applications which tell the user that the video is being prepared, after call setup. It is OK if that takes a few seconds to do. However, VoIP is quite different, and there are some further issues there. Firstly, as Brian has pointed out, rate adaptive codecs for VoIP are very rare. Practically speaking, nearly all commercial VoIP phones use single rate codecs. Many can support multiple codecs. However, frequently, once a codec is selected, it cannot be changed easily during the call. This is commonly the case for hardware phones, where I believe the codecs are stored in flash and downloaded into RAM once a codec is selected in the call. We have had a lot of folks ask how, in SIP, to signal that the called party has to pick one of the N offered codecs, and then stick to it. RFC 3264 describes means for doing that. Such a phone would not permit rate adaptivity by switching codecs as you describe below. Thus, it would be all or nothing in terms of sending rate. Even assuming there was rate adaptivity for voice, there are perceptual issues when the encoding is frequently changed. It is apparently more annoying for users to oscillate between high and low rate codecs, than to stay constant with a medium rate codec. I seem to recall some studies along these lines in the late 90s by Jean Bolot and his students, though I cannot find the specific reference. -Jonathan R. Phelan, Tom wrote: > Hi, > > I've come up with the following scheme for using DCCP/TFRC with two-way > interactive media. As a reminder, two-way media differs from one-way live > in being very intolerant of delay. One-way live differs from one-way > pre-recorded in having a maximum transmit rate equal to the encoding rate > (rather than the disk read rate). > > The procedure here is a significant departure from current practice. I > haven't been able to fully digest the system implications of this scheme > yet, but some of them, especially with regard to congestion and call > admission control seem pretty exciting. > > Assume that each end of the connection is capable of using a number of > codecs with increasing bandwidth needs, where each step up is less than > twice the rate of the previous step, and that the sender can switch between > them at "low cost" (perhaps a big assumption). Assume also that DCCP > provides immediate feedback to the application when it changes the computed > sending rate. > > To start, the calling part sends an INVITE (loosely using SIP terminology) > indicating the IP address and DCCP port to use for media at its end. > Without informing the called user, the called system responds to the INVITE > by connecting to the media port. Both end systems then begin exchanging > test data, at the (slowly increasing) rate allowed by TFRC. The purpose of > this test data is to see what rate the connection can be ramped up to. If > that rate is less than a minimum acceptable rate, the call is cleared > (conceptually, the calling user hears "fast busy" and the called user is > never informed of the incoming call). Note that once the rate has ramped up > sufficiently for the highest rate codec there's no need to go further. > > If an acceptable rate can be achieved, the called user is informed of the > incoming call. The test data is continued during this period. Once the > called user accepts the call, the test data is replaced by real data at the > same rate. > > If congestion is encountered during the call, TFRC will reduce its allowed > sending rate. When that rate falls below the codec currently is use, the > sender switches to a lower rate codec. If the rate continues to fall the > sender will eventually get to its lowest rate codec. If the TFRC rate > continues to fall past the lowest rate codec, the sender must discard > packets to conform to that rate. > > If the network capacity is sufficient to support one of the lower rate > codecs, eventually the congestion will clear and TFRC will slowly increase > the allowed transmit rate. Since the application will continue to transmit > at its codec rate, TFRC will limit this increase to at most twice the > current sending rate (my interpretation of the TFRC paper here, I could be > wrong :-)). This is the reason that the sender must use a codec suite with > rates in steps of less that two times the previous rate. If the TFRC rate > increases sufficiently for the next codec step, the sender may switch to the > higher rate step. If the network can't support the new rate, eventually > congestion will reappear and the sender will fall back to the lower rate. > Over time the sender will oscillate between the lower and higher rate with a > period equal to the time it takes TFRC to probe between the two rates. > > This procedure doesn't work when silence suppression is in use. I need to > think about that some more. > > Tom P. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 29 01:49:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01047 for ; Tue, 29 Jul 2003 01:49:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNMT-0004AB-IU for mmusic-archive@odin.ietf.org; Tue, 29 Jul 2003 01:49:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T5nP1A015997 for mmusic-archive@odin.ietf.org; Tue, 29 Jul 2003 01:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNMT-00049w-DQ for mmusic-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 01:49:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01026 for ; Tue, 29 Jul 2003 01:48:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNLK-0002p1-00 for mmusic-web-archive@ietf.org; Tue, 29 Jul 2003 01:48:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hNLJ-0002oy-00 for mmusic-web-archive@ietf.org; Tue, 29 Jul 2003 01:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNL6-00044v-Se; Tue, 29 Jul 2003 01:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNKM-00044X-Ny for mmusic@optimus.ietf.org; Tue, 29 Jul 2003 01:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01018; Tue, 29 Jul 2003 01:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNKJ-0002oG-00; Tue, 29 Jul 2003 01:47:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hNKI-0002nt-00; Tue, 29 Jul 2003 01:47:10 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6T5kf6Y003071; Tue, 29 Jul 2003 01:46:42 -0400 (EDT) Message-ID: <3F260A3F.4030709@dynamicsoft.com> Date: Tue, 29 Jul 2003 01:46:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eddie Kohler CC: dccp@ietf.org, mmusic@ietf.org, tphelan@sonusnet.com Subject: Re: [MMUSIC] Packet drop API / what happens with packet drops now? References: <200307242220.h6OMKci8056309@coyote.icir.org> In-Reply-To: <200307242220.h6OMKci8056309@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddie, It is really quite a bit worse to through away the packet at the sender, as opposed to informing the application and having it respond by ceasing transmission or lowering its rate. The difference has to do with error propagation that result from compression algorithms. The loss of a single packet causes reconstruction errors in the decoder, which propagate into subsequent audio frames or video macroblocks. The lower the rate, the longer these artifacts persist. If the sender knows that it cannot send, it is much better to back off in a way that does not result in a desynchronization of encoder and decoder state. Indeed, I performed some studies to look at this phenomenon as part of my dissertation work. For G.729 (an 8kbps audio codec), I found that it was much more useful to keep the the state of the encoder and decoder synchronized than it was to faithfully reconstruct the speech content of a lost frame, due to this error propagation. The results, if you are interested, are described in: http://www.jdrosen.net/e6880/index.html -Jonathan R. Eddie Kohler wrote: > What happens in currently-deployed codecs when packets are dropped? > > Clearly codecs, and VoIP in particular, can handle loss. Possibly even high > loss rates. One way to think about DCCP's allowed sending rate is that it > moves drops that *would* have happened in the network *anyway*, into the > sending host. (Although DCCP will generally drop more than the network > would have, to ensure fairness, and because of congestion-control > infelicities that we want to fix.) So how disastrous are these drops? > > Another way to put this: A DCCP API might never block -- or it might block > for at most T seconds. Instead, writing a packet into a full send buffer > would drop that packet; or it might drop an older packet---a drop-from-head > send buffer; or it might drop the oldest packet with lowest priority > annotation. > > Now the app simply sees a loss rate, which DCCP will happily report. For > codec switching, you can simply switch when the loss rate is intolerably > high -- which you would have had to do anyway. > > How horrible would this be? > > Eddie > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Jul 29 03:29:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14757 for ; Tue, 29 Jul 2003 03:29:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOuC-0000GT-Ug for mmusic-archive@odin.ietf.org; Tue, 29 Jul 2003 03:28:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T7SK19001005 for mmusic-archive@odin.ietf.org; Tue, 29 Jul 2003 03:28:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOuB-0000G8-TO for mmusic-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 03:28:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14730 for ; Tue, 29 Jul 2003 03:28:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hOu9-0003Fm-00 for mmusic-web-archive@ietf.org; Tue, 29 Jul 2003 03:28:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hOu9-0003Fj-00 for mmusic-web-archive@ietf.org; Tue, 29 Jul 2003 03:28:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOtt-0000EN-7E; Tue, 29 Jul 2003 03:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOtA-0000Dd-DN for mmusic@optimus.ietf.org; Tue, 29 Jul 2003 03:27:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14710 for ; Tue, 29 Jul 2003 03:27:12 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hOt8-0003Fb-00 for mmusic@ietf.org; Tue, 29 Jul 2003 03:27:14 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19hOt7-0003FY-00 for mmusic@ietf.org; Tue, 29 Jul 2003 03:27:13 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6T7RCJ14964 for ; Tue, 29 Jul 2003 10:27:13 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Jul 2003 10:27:12 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 10:27:12 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 10:27:11 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 10:27:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WG Last call: draft-ietf-mmusic-sdp-bwparam-04.txt Date: Tue, 29 Jul 2003 10:27:10 +0300 Message-ID: <2BF0AD29BC31FE46B78877321144043101B9E466@trebe003.europe.nokia.com> Thread-Topic: [MMUSIC] WG Last call: draft-ietf-mmusic-sdp-bwparam-04.txt Thread-Index: AcNMjdoyxXQfCyy0QQS0dw26o4yMRgJErPRw To: Cc: , , X-OriginalArrivalTime: 29 Jul 2003 07:27:11.0285 (UTC) FILETIME=[D3322E50:01C355A2] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus -bwparam-04 is an excellent document - thanks for doing the hard work! The ID allows TIAS to be less than the sum of the total bandwidth as = media bandwdith may vary diferently (makes sense). Also, this feature = can be useful for when an application specifically expects/requires that = all the media will not be used. Such as in a "internationalised TV = program" - e.g. a single video stream and 2 audio streams of different = languages to end-receivers required to decode only 1 video and 1 audio = stream. In my eyes, this works without any changes at all to the ID = (there's no need to explicitly mention this use case). However, I'd be = interested to know if you see that there are any problems in this usage? I also spotted one trivial typo - first word, last paragraph, section = 6.3 - missing " I don't think either of these should have an effect last call since the = ID is already so mature. Cheers, Rod. > -----Original Message----- > From: ext Colin Perkins [mailto:csp@csperkins.org] > Sent: Thursday, July 17, 2003 9:01 PM > To: mmusic@ietf.org > Cc: jo@tzi.uni-bremen.de > Subject: [MMUSIC] WG Last call: draft-ietf-mmusic-sdp-bwparam-04.txt >=20 >=20 > As announced in the MMUSIC session this morning, the SDP bandwidth > parameters draft is now in working group last call. Please=20 > send any final > comments on this draft to the mailing list by 28th July. If=20 > no substantive > comments are received by that time, we propose to submit this=20 > draft to the > IESG for publication as a proposed standard RFC. >=20 > --=20 > Colin Perkins > csp@csperkins.org >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 30 08:33:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28422 for ; Wed, 30 Jul 2003 08:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hq8v-00072i-25 for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 08:33:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UCXLIu027068 for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 08:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hq8u-00072V-UT for mmusic-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 08:33:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28399 for ; Wed, 30 Jul 2003 08:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hq8t-0007JK-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 08:33:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hq8t-0007JG-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 08:33:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hq8b-00070c-7K; Wed, 30 Jul 2003 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hq8V-000708-AW for mmusic@optimus.ietf.org; Wed, 30 Jul 2003 08:32:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28390; Wed, 30 Jul 2003 08:32:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hq8T-0007J6-00; Wed, 30 Jul 2003 08:32:53 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19hq8T-0007J3-00; Wed, 30 Jul 2003 08:32:53 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6UCWMOT015264; Wed, 30 Jul 2003 08:32:22 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 30 Jul 2003 08:32:20 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 08:32:19 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB4A2@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [MMUSIC] Two-way media with DCCP and TFRC Date: Wed, 30 Jul 2003 08:32:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Jonathon, I agree that the assumption of multiple codecs for a single session is an enormous leap of faith. Given the difficulties you talk about, it would appear that you think end-to-end congestion control like what's described in draft-iab-congestion-00.txt isn't practical. Do you have any other comments on that draft? Tom P. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 29, 2003 1:38 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC > > > This kind of scheme might work for video. I have seen interactive > video applications which tell the user that the video is being > prepared, after call setup. It is OK if that takes a few seconds to > do. However, VoIP is quite different, and there are some further > issues there. > > Firstly, as Brian has pointed out, rate adaptive codecs for VoIP are > very rare. Practically speaking, nearly all commercial VoIP > phones use > single rate codecs. Many can support multiple codecs. However, > frequently, once a codec is selected, it cannot be changed easily > during the call. This is commonly the case for hardware phones, where > I believe the codecs are stored in flash and downloaded into RAM once > a codec is selected in the call. We have had a lot of folks ask how, > in SIP, to signal that the called party has to pick one of the N > offered codecs, and then stick to it. RFC 3264 describes means for > doing that. > > Such a phone would not permit rate adaptivity by switching codecs as > you describe below. Thus, it would be all or nothing in terms of > sending rate. > > Even assuming there was rate adaptivity for voice, there are > perceptual issues when the encoding is frequently changed. It is > apparently more annoying for users to oscillate between high and low > rate codecs, than to stay constant with a medium rate codec. > I seem to > recall some studies along these lines in the late 90s by Jean Bolot > and his students, though I cannot find the specific reference. > > -Jonathan R. > > Phelan, Tom wrote: > > > Hi, > > > > I've come up with the following scheme for using DCCP/TFRC > with two-way > > interactive media. As a reminder, two-way media differs > from one-way live > > in being very intolerant of delay. One-way live differs > from one-way > > pre-recorded in having a maximum transmit rate equal to the > encoding rate > > (rather than the disk read rate). > > > > The procedure here is a significant departure from current > practice. I > > haven't been able to fully digest the system implications > of this scheme > > yet, but some of them, especially with regard to congestion and call > > admission control seem pretty exciting. > > > > Assume that each end of the connection is capable of using > a number of > > codecs with increasing bandwidth needs, where each step up > is less than > > twice the rate of the previous step, and that the sender > can switch between > > them at "low cost" (perhaps a big assumption). Assume also > that DCCP > > provides immediate feedback to the application when it > changes the computed > > sending rate. > > > > To start, the calling part sends an INVITE (loosely using > SIP terminology) > > indicating the IP address and DCCP port to use for media at its end. > > Without informing the called user, the called system > responds to the INVITE > > by connecting to the media port. Both end systems then > begin exchanging > > test data, at the (slowly increasing) rate allowed by TFRC. > The purpose of > > this test data is to see what rate the connection can be > ramped up to. If > > that rate is less than a minimum acceptable rate, the call > is cleared > > (conceptually, the calling user hears "fast busy" and the > called user is > > never informed of the incoming call). Note that once the > rate has ramped up > > sufficiently for the highest rate codec there's no need to > go further. > > > > If an acceptable rate can be achieved, the called user is > informed of the > > incoming call. The test data is continued during this > period. Once the > > called user accepts the call, the test data is replaced by > real data at the > > same rate. > > > > If congestion is encountered during the call, TFRC will > reduce its allowed > > sending rate. When that rate falls below the codec > currently is use, the > > sender switches to a lower rate codec. If the rate > continues to fall the > > sender will eventually get to its lowest rate codec. If > the TFRC rate > > continues to fall past the lowest rate codec, the sender > must discard > > packets to conform to that rate. > > > > If the network capacity is sufficient to support one of the > lower rate > > codecs, eventually the congestion will clear and TFRC will > slowly increase > > the allowed transmit rate. Since the application will > continue to transmit > > at its codec rate, TFRC will limit this increase to at most > twice the > > current sending rate (my interpretation of the TFRC paper > here, I could be > > wrong :-)). This is the reason that the sender must use a > codec suite with > > rates in steps of less that two times the previous rate. > If the TFRC rate > > increases sufficiently for the next codec step, the sender > may switch to the > > higher rate step. If the network can't support the new > rate, eventually > > congestion will reappear and the sender will fall back to > the lower rate. > > Over time the sender will oscillate between the lower and > higher rate with a > > period equal to the time it takes TFRC to probe between the > two rates. > > > > This procedure doesn't work when silence suppression is in > use. I need to > > think about that some more. > > > > Tom P. > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 30 11:42:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05380 for ; Wed, 30 Jul 2003 11:42:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht5E-0005Jq-AM for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 11:41:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFfifo020446 for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 11:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht5E-0005Jh-5H for mmusic-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05358 for ; Wed, 30 Jul 2003 11:41:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ht58-0001BB-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 11:41:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ht57-0001B8-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 11:41:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht4X-0005Gh-HT; Wed, 30 Jul 2003 11:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht3q-0005FC-Qm for mmusic@optimus.ietf.org; Wed, 30 Jul 2003 11:40:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05286; Wed, 30 Jul 2003 11:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ht3p-0001AU-00; Wed, 30 Jul 2003 11:40:17 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ht3o-0001AE-00; Wed, 30 Jul 2003 11:40:16 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UFdk6Y003984; Wed, 30 Jul 2003 11:39:46 -0400 (EDT) Message-ID: <3F27E6BF.6010305@dynamicsoft.com> Date: Wed, 30 Jul 2003 11:39:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC References: <4CF48720B6E9D4118D040060CF2074E9082BB4A2@sonusdc3.sonusnet.com> In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB4A2@sonusdc3.sonusnet.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 My take on draft-iab-congestion is that, for voip, what the draft effectively implies is that you will send at your specific codec-defined rate, and then when congestion hits the defined percentage, stop. That is, there will be a binary choice of either sending or not, as opposed to a continuum of rates. I dont think that this is a bad thing, but does mean that the threshold loss rate is incredibly important. The current draft talks about relatively high loss rates, ones where the voice quality is probably already unacceptable. However, it is my understanding that these rates are very sensitive to the assumed TCP parameters, and that they could be quite a bit lower if computed differently. -Jonathan R. Phelan, Tom wrote: > Hi Jonathon, > > I agree that the assumption of multiple codecs for a single session is an > enormous leap of faith. Given the difficulties you talk about, it would > appear that you think end-to-end congestion control like what's described in > draft-iab-congestion-00.txt isn't practical. Do you have any other comments > on that draft? > > Tom P. > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Tuesday, July 29, 2003 1:38 AM >>To: Phelan, Tom >>Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay >>Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC >> >> >>This kind of scheme might work for video. I have seen interactive >>video applications which tell the user that the video is being >>prepared, after call setup. It is OK if that takes a few seconds to >>do. However, VoIP is quite different, and there are some further >>issues there. >> >>Firstly, as Brian has pointed out, rate adaptive codecs for VoIP are >>very rare. Practically speaking, nearly all commercial VoIP >>phones use >>single rate codecs. Many can support multiple codecs. However, >>frequently, once a codec is selected, it cannot be changed easily >>during the call. This is commonly the case for hardware phones, where >>I believe the codecs are stored in flash and downloaded into RAM once >>a codec is selected in the call. We have had a lot of folks ask how, >>in SIP, to signal that the called party has to pick one of the N >>offered codecs, and then stick to it. RFC 3264 describes means for >>doing that. >> >>Such a phone would not permit rate adaptivity by switching codecs as >>you describe below. Thus, it would be all or nothing in terms of >>sending rate. >> >>Even assuming there was rate adaptivity for voice, there are >>perceptual issues when the encoding is frequently changed. It is >>apparently more annoying for users to oscillate between high and low >>rate codecs, than to stay constant with a medium rate codec. >>I seem to >>recall some studies along these lines in the late 90s by Jean Bolot >>and his students, though I cannot find the specific reference. >> >>-Jonathan R. >> >>Phelan, Tom wrote: >> >> >>>Hi, >>> >>>I've come up with the following scheme for using DCCP/TFRC >> >>with two-way >> >>>interactive media. As a reminder, two-way media differs >> >>from one-way live >> >>>in being very intolerant of delay. One-way live differs >> >>from one-way >> >>>pre-recorded in having a maximum transmit rate equal to the >> >>encoding rate >> >>>(rather than the disk read rate). >>> >>>The procedure here is a significant departure from current >> >>practice. I >> >>>haven't been able to fully digest the system implications >> >>of this scheme >> >>>yet, but some of them, especially with regard to congestion and call >>>admission control seem pretty exciting. >>> >>>Assume that each end of the connection is capable of using >> >>a number of >> >>>codecs with increasing bandwidth needs, where each step up >> >>is less than >> >>>twice the rate of the previous step, and that the sender >> >>can switch between >> >>>them at "low cost" (perhaps a big assumption). Assume also >> >>that DCCP >> >>>provides immediate feedback to the application when it >> >>changes the computed >> >>>sending rate. >>> >>>To start, the calling part sends an INVITE (loosely using >> >>SIP terminology) >> >>>indicating the IP address and DCCP port to use for media at its end. >>>Without informing the called user, the called system >> >>responds to the INVITE >> >>>by connecting to the media port. Both end systems then >> >>begin exchanging >> >>>test data, at the (slowly increasing) rate allowed by TFRC. >> >> The purpose of >> >>>this test data is to see what rate the connection can be >> >>ramped up to. If >> >>>that rate is less than a minimum acceptable rate, the call >> >>is cleared >> >>>(conceptually, the calling user hears "fast busy" and the >> >>called user is >> >>>never informed of the incoming call). Note that once the >> >>rate has ramped up >> >>>sufficiently for the highest rate codec there's no need to >> >>go further. >> >>>If an acceptable rate can be achieved, the called user is >> >>informed of the >> >>>incoming call. The test data is continued during this >> >>period. Once the >> >>>called user accepts the call, the test data is replaced by >> >>real data at the >> >>>same rate. >>> >>>If congestion is encountered during the call, TFRC will >> >>reduce its allowed >> >>>sending rate. When that rate falls below the codec >> >>currently is use, the >> >>>sender switches to a lower rate codec. If the rate >> >>continues to fall the >> >>>sender will eventually get to its lowest rate codec. If >> >>the TFRC rate >> >>>continues to fall past the lowest rate codec, the sender >> >>must discard >> >>>packets to conform to that rate. >>> >>>If the network capacity is sufficient to support one of the >> >>lower rate >> >>>codecs, eventually the congestion will clear and TFRC will >> >>slowly increase >> >>>the allowed transmit rate. Since the application will >> >>continue to transmit >> >>>at its codec rate, TFRC will limit this increase to at most >> >>twice the >> >>>current sending rate (my interpretation of the TFRC paper >> >>here, I could be >> >>>wrong :-)). This is the reason that the sender must use a >> >>codec suite with >> >>>rates in steps of less that two times the previous rate. >> >>If the TFRC rate >> >>>increases sufficiently for the next codec step, the sender >> >>may switch to the >> >>>higher rate step. If the network can't support the new >> >>rate, eventually >> >>>congestion will reappear and the sender will fall back to >> >>the lower rate. >> >>>Over time the sender will oscillate between the lower and >> >>higher rate with a >> >>>period equal to the time it takes TFRC to probe between the >> >>two rates. >> >>>This procedure doesn't work when silence suppression is in >> >>use. I need to >> >>>think about that some more. >>> >>>Tom P. >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 30 13:43:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10083 for ; Wed, 30 Jul 2003 13:43:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huyM-0003qP-Ha for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 13:42:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHgkSE014773 for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 13:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huyM-0003qC-EV for mmusic-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 13:42:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10031 for ; Wed, 30 Jul 2003 13:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huyK-0002Ab-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 13:42:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19huyJ-0002AY-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 13:42:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huxe-0003jo-2s; Wed, 30 Jul 2003 13:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huwo-0003cD-TM for mmusic@optimus.ietf.org; Wed, 30 Jul 2003 13:41:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09931; Wed, 30 Jul 2003 13:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huwm-00029K-00; Wed, 30 Jul 2003 13:41:08 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19huwh-000290-00; Wed, 30 Jul 2003 13:41:03 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6UHeXOT005167; Wed, 30 Jul 2003 13:40:33 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 30 Jul 2003 13:40:30 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 13:40:29 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB4A5@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Jonathan Rosenberg'" , "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [MMUSIC] Two-way media with DCCP and TFRC Date: Wed, 30 Jul 2003 13:40:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Jonathan, Yes, that seems reasonable. If we can forget the slow-start issues with the procedure I proposed, it can help in the high-loss situation Sally describes. As the procedure says, once the TFRC rate drops below the minimum acceptable rate (which will be your only rate), you discard packets at the sender to conform to the TFRC rate. If you're discarding at sender to conform to the TFRC rate, as opposed to discarding in the network, I think you can continue to send and be fair to TCP, regardless of the local and network loss rates. It also seems to me that if you aren't pumping way to many packets into a congested situation, you might actually be able to get more packets through. Tom P. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 30, 2003 11:40 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC > > > My take on draft-iab-congestion is that, for voip, what the draft > effectively implies is that you will send at your specific > codec-defined rate, and then when congestion hits the defined > percentage, stop. That is, there will be a binary choice of either > sending or not, as opposed to a continuum of rates. > > I dont think that this is a bad thing, but does mean that the > threshold loss rate is incredibly important. The current draft talks > about relatively high loss rates, ones where the voice quality is > probably already unacceptable. However, it is my understanding that > these rates are very sensitive to the assumed TCP parameters, > and that > they could be quite a bit lower if computed differently. > > -Jonathan R. > > Phelan, Tom wrote: > > > Hi Jonathon, > > > > I agree that the assumption of multiple codecs for a single > session is an > > enormous leap of faith. Given the difficulties you talk > about, it would > > appear that you think end-to-end congestion control like > what's described in > > draft-iab-congestion-00.txt isn't practical. Do you have > any other comments > > on that draft? > > > > Tom P. > > > > > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>Sent: Tuesday, July 29, 2003 1:38 AM > >>To: Phelan, Tom > >>Cc: 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > >>Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC > >> > >> > >>This kind of scheme might work for video. I have seen interactive > >>video applications which tell the user that the video is being > >>prepared, after call setup. It is OK if that takes a few seconds to > >>do. However, VoIP is quite different, and there are some further > >>issues there. > >> > >>Firstly, as Brian has pointed out, rate adaptive codecs for > VoIP are > >>very rare. Practically speaking, nearly all commercial VoIP > >>phones use > >>single rate codecs. Many can support multiple codecs. However, > >>frequently, once a codec is selected, it cannot be changed easily > >>during the call. This is commonly the case for hardware > phones, where > >>I believe the codecs are stored in flash and downloaded > into RAM once > >>a codec is selected in the call. We have had a lot of folks > ask how, > >>in SIP, to signal that the called party has to pick one of the N > >>offered codecs, and then stick to it. RFC 3264 describes means for > >>doing that. > >> > >>Such a phone would not permit rate adaptivity by switching > codecs as > >>you describe below. Thus, it would be all or nothing in terms of > >>sending rate. > >> > >>Even assuming there was rate adaptivity for voice, there are > >>perceptual issues when the encoding is frequently changed. It is > >>apparently more annoying for users to oscillate between > high and low > >>rate codecs, than to stay constant with a medium rate codec. > >>I seem to > >>recall some studies along these lines in the late 90s by Jean Bolot > >>and his students, though I cannot find the specific reference. > >> > >>-Jonathan R. > >> > >>Phelan, Tom wrote: > >> > >> > >>>Hi, > >>> > >>>I've come up with the following scheme for using DCCP/TFRC > >> > >>with two-way > >> > >>>interactive media. As a reminder, two-way media differs > >> > >>from one-way live > >> > >>>in being very intolerant of delay. One-way live differs > >> > >>from one-way > >> > >>>pre-recorded in having a maximum transmit rate equal to the > >> > >>encoding rate > >> > >>>(rather than the disk read rate). > >>> > >>>The procedure here is a significant departure from current > >> > >>practice. I > >> > >>>haven't been able to fully digest the system implications > >> > >>of this scheme > >> > >>>yet, but some of them, especially with regard to > congestion and call > >>>admission control seem pretty exciting. > >>> > >>>Assume that each end of the connection is capable of using > >> > >>a number of > >> > >>>codecs with increasing bandwidth needs, where each step up > >> > >>is less than > >> > >>>twice the rate of the previous step, and that the sender > >> > >>can switch between > >> > >>>them at "low cost" (perhaps a big assumption). Assume also > >> > >>that DCCP > >> > >>>provides immediate feedback to the application when it > >> > >>changes the computed > >> > >>>sending rate. > >>> > >>>To start, the calling part sends an INVITE (loosely using > >> > >>SIP terminology) > >> > >>>indicating the IP address and DCCP port to use for media > at its end. > >>>Without informing the called user, the called system > >> > >>responds to the INVITE > >> > >>>by connecting to the media port. Both end systems then > >> > >>begin exchanging > >> > >>>test data, at the (slowly increasing) rate allowed by TFRC. > >> > >> The purpose of > >> > >>>this test data is to see what rate the connection can be > >> > >>ramped up to. If > >> > >>>that rate is less than a minimum acceptable rate, the call > >> > >>is cleared > >> > >>>(conceptually, the calling user hears "fast busy" and the > >> > >>called user is > >> > >>>never informed of the incoming call). Note that once the > >> > >>rate has ramped up > >> > >>>sufficiently for the highest rate codec there's no need to > >> > >>go further. > >> > >>>If an acceptable rate can be achieved, the called user is > >> > >>informed of the > >> > >>>incoming call. The test data is continued during this > >> > >>period. Once the > >> > >>>called user accepts the call, the test data is replaced by > >> > >>real data at the > >> > >>>same rate. > >>> > >>>If congestion is encountered during the call, TFRC will > >> > >>reduce its allowed > >> > >>>sending rate. When that rate falls below the codec > >> > >>currently is use, the > >> > >>>sender switches to a lower rate codec. If the rate > >> > >>continues to fall the > >> > >>>sender will eventually get to its lowest rate codec. If > >> > >>the TFRC rate > >> > >>>continues to fall past the lowest rate codec, the sender > >> > >>must discard > >> > >>>packets to conform to that rate. > >>> > >>>If the network capacity is sufficient to support one of the > >> > >>lower rate > >> > >>>codecs, eventually the congestion will clear and TFRC will > >> > >>slowly increase > >> > >>>the allowed transmit rate. Since the application will > >> > >>continue to transmit > >> > >>>at its codec rate, TFRC will limit this increase to at most > >> > >>twice the > >> > >>>current sending rate (my interpretation of the TFRC paper > >> > >>here, I could be > >> > >>>wrong :-)). This is the reason that the sender must use a > >> > >>codec suite with > >> > >>>rates in steps of less that two times the previous rate. > >> > >>If the TFRC rate > >> > >>>increases sufficiently for the next codec step, the sender > >> > >>may switch to the > >> > >>>higher rate step. If the network can't support the new > >> > >>rate, eventually > >> > >>>congestion will reappear and the sender will fall back to > >> > >>the lower rate. > >> > >>>Over time the sender will oscillate between the lower and > >> > >>higher rate with a > >> > >>>period equal to the time it takes TFRC to probe between the > >> > >>two rates. > >> > >>>This procedure doesn't work when silence suppression is in > >> > >>use. I need to > >> > >>>think about that some more. > >>> > >>>Tom P. > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Chief Technology Officer Parsippany, NJ > 07054-2711 > >>dynamicsoft > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Jul 30 19:23:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23067 for ; Wed, 30 Jul 2003 19:23:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0Hv-0001rT-5y for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 19:23:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UNNJhH007151 for mmusic-archive@odin.ietf.org; Wed, 30 Jul 2003 19:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0Hv-0001rF-2Z for mmusic-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 19:23:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23060 for ; Wed, 30 Jul 2003 19:23:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i0Ht-000594-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 19:23:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i0Ht-000591-00 for mmusic-web-archive@ietf.org; Wed, 30 Jul 2003 19:23:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0Hd-0001nz-G0; Wed, 30 Jul 2003 19:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0Gm-0001mQ-GP for mmusic@optimus.ietf.org; Wed, 30 Jul 2003 19:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23029 for ; Wed, 30 Jul 2003 19:22:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i0Gk-00058W-00 for mmusic@ietf.org; Wed, 30 Jul 2003 19:22:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19i0Gh-00058G-00 for mmusic@ietf.org; Wed, 30 Jul 2003 19:22:03 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2003 16:24:30 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6UNLVCb026802; Wed, 30 Jul 2003 16:21:31 -0700 (PDT) Received: from DWINGW2K4 ([10.32.130.98]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AJU68210; Wed, 30 Jul 2003 16:16:26 -0700 (PDT) From: "Dan Wing" To: "Magnus Westerlund" Cc: "Flemming Andreasen" , "Mark Baugher" , "IETF MMUSIC WG" , "Dan Wing" Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt Date: Wed, 30 Jul 2003 16:21:30 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3F214784.2030804@ericsson.com> 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 > Here is my comments on this draft. Thanks for your comments. Sorry for the delay, I have been out of the office. > 1. As a WG draft you should have the short copyright statement and not > only the long one at the end of the draft. Yes, sorry we didn't correct this, I see you commented on this same issue when you reviewed -00. > 2. In section 1 I would like that you clarify that RFC 2828 contains > security terminology. Okay. > 3. Section 3.1. This section needs to be improved. As I understand it > the a=crypto attribute can be used with any transport and media. > Therefore the section should not start with defining that this defines > the value for RTP/SAVP. The actual crypto suits will be required to be > registered and defined for each individual transport. There might in > fact be even further restrictions that apply to future crypto suits. -sdescriptions- is only trying to describe a=crypto for the RTP/SAVP (SRTP) transport. > 4. Section 3.4, I think the session parameters are actually specific to > the crypto suit, primarily. But "encrypted_srtcp" can be specified for any and all crypto suites. Are there session parameters that are specific to a cryptographic suite? > Secondarily it can be dependent on more things. Could you explain? > 5. Section 3 and 4. In general I think the basic definition of the > a=crypto attribute can be more cleanly separated from the specific > application for SRTP. You mean, for example, to allow -sdescriptions- to define the keys used by some non-SRTP application (whiteboarding, perhaps)? We're trying to only define usage with SRTP (RTP/SAVP). > 6. Section 4.1, Is usage of multiple a=crypto lines allowed. IF yes this > section contradict this. I agree some different wording would clarify this section. Will work on it. > 7. Section 4.1.4, last sentence: How can one add a new name that is > identical and still carry any difference. Please reword. Okay. > 8. Section 4.2, I think there is a large shortcoming regarding the uri: > parameter. I think one must clearly define the format one retrieves the > keys when using the URI. Of course this format can be crypto suit > dependent. We're strongly considering dropping the URI parameter. If anyone feels strongly about keeping it, speak up. > 9. Section 4.3.1, second and third paragraph. I think the definition of > the SSRC, ROC, SEQ, could be better done. As I understand it any of the > three is sufficient, why not express it that way. Then one MAY have the > parameter anyway. We'll tighten up that wording, thanks. > 10. Section 5.4, second paragraph: I think the limitation you would like > to declare here needs some discussion. First you forbid the usage of > multiple m= lines on the same port, after last weeks discussion I don't > know if this is acceptable, at least not without further motivation. I > would also write some recommendations/considerations regarding grouping > of media lines here. In this I-D, we will be removing all references to multiple media lines with the same port. A completely separate, unrelated, Internet Draft needs to be written -- with consensus from the WG -- describing how multiple media lines with the same UDP port are supposed to be interpreted. (As an aside, the behavior for multiple media lines with the same port hasn't been specified elsewhere, so it is ambiguous. I personally feel we need to create an unambigiuos method to express the desired behavior when an Offer contains multiple media lines with the same port.) > 11. Section 5.7, I am not certain that session parameters can't be > restrained from being changed. For example the SRC (ROC) parameter seems > one that might need to be included and changed in an offer for rekeying. Good point. We haven't put enough thought into rekeying yet as it's unnecessary with voice applications and the maximum key lifetimes of the crypto suites defined in SRTP. > Are there any synchronization problem that can arise when doing > rekeying? There seems to be need to define from what seq the new key are > valid. That seems to be more a problem with SRTP than -sdescriiptions-. To resolve the synchronization problem you have to use a per-packet MKI (which adds a few bytes to each SRTP packet) or the "from,to" mechanism (which doesn't add bytes to each SRTP packet); both MKI and "from,to" are described in SRTP itself. Do you feel putting like the above paragraph might be useful in -sdescriptions-? > 12. When it comes to SRTPs protection mechanism it seems necessary to be > able to define the window size using the a=crypto parameter. There are a > lot of difference between a uncompressed video stream running at a > couple of hundreds of Mbyte/s using 100 000 packets each second. This > will require a much larger window then a 64 kbit stream that sends 15 > packets every second. SRTP (draft-ietf-avt-09.txt) says that the SRTP-WINDOW-SIZE is a receiver-side, implementation-dependent parameter. If it is signaled in a unicast SDP, SRTP-WINDOW-SIZE would become a sender-side parameter. Is that your intent of having the SRTP-WINDOW-SIZE indicated in the a=crypto line? > 13. Section 6.1 First paragraph, last sentence. The attack is only > avoided if there is one master key per SSRC, not media stream. I think > that there is some ambiguity in the use of media stream, which needs to > be clarified to avoid misunderstanding. Okay, we'll examine that. Thanks. > 14. Section 6.2, second paragraph, first sentence: The attribute is > crypto not SRTP as it says in the text. Okay. > 15. Section 7.: The ABNF does not define the extension space. For > example the crypto-suite definition should have an extra alternative > crypto-suit-extension which is VCHAR. I think the whole ABNF needs to be > thought through to be more complete in the extension sense. Yes, it does. In Vienna it was also pointed out that we need IANA registration of all of the stuff in -sdescriptions-, as well. We'll be adding that to the next I-D. > 16. Section 7. Why have the 2^ optional value if it does not matter. > Please simplify this. At an earlier review, Mark was asked to have a method to specify power-of-two key lifetimes. This seemed the easiest way to allow specifying power-of-two key lifetimes. But rereading the draft, I see we never added text explaining the purpose of "2^"! We'll add that at the next revision. Thanks. > 17. Section 7, The absolute URI should not rely only on RFC 2396, there > is an extension to that document, please see RFC 2732. Thanks. > 18. Last page, has not the normal number of lines. Again, thanks for your review. -d > Best Regards > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic